Maybe You Don't Need Kubernetes - <AUTHOR> https://matthias-endler.de/2019/maybe-you-dont-need-kubernetes/ <comment><USER2> The argument that Kubernetes adds complexity is, in my opinion, bogus. Kubernetes is a "define once, forget about it" type of infrastructure. You define the state you want your infrastructure to and Kubernetes takes care of maintaining that state. Tools like Ansible and Puppet, as great as they are, do not guarantee your infrastructure will end up in the state you defined and you easily end up with broken services. The only complexity in kubernetes is the fact that it _forces_ you to _think_ and carefully _design_ your infra in a way people aren't used to, yet. More upfront, careful thinking isn't complexity. It can only benefit you in the long run.

There is, however, a learning curve to Kubernetes, but it isn't this sharp. It does require you to sit down and read the doc for 8 hours, but that a small price to pay.

A few month back I wrote a blog post[1] that, through walking through the few different infrastructures my company experimented with over the years, surfaces many reasons one would want to use [a managed] Kubernetes. (For a shorter read, you can probably start at reading at [2])

[1]: [https://boxunix.com/post/bare_metal_to_kube](https://boxunix.com/post/bare_metal_to_kube)

[2]: [https://boxunix.com/post/bare_metal_to_kube/#_hardware_infra...](https://boxunix.com/post/bare_metal_to_kube/#_hardware_infrastructure)

<comment><USER3> It's pretty common for new technologies to advertise themselves as "adopt, and forget about it", but in my experience it's unheard of that any actually deliver on this promise.

Any technology you adopt today is a technology you're going to have to troubleshoot tomorrow. (I don't think the 15,000 Kubernetes questions on StackOverflow are all from initial setup.) I can't remember the last [application / service / file format / website / language / anything related to computer software] that was so simple and reliable that I _wasn 't_ searching the internet for answers (and banging my head against the wall because of) the very next month. It was probably something on my C=64.

As Kernighan said back in the 1970's, "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" I've never used Kubernetes, but I've read some articles about it and watched some videos, and despite the nonstop bragging about its simplicity (red flag #1), I'm not sure I can figure out how to deploy with it. I'm fairly certain I wouldn't have any hope of fixing it when it breaks next month.

Hearing testimonials only from people who say "it doesn't break!" is red flag #2. No technology works perfectly for everyone, so I want to hear from the people who had to troubleshoot it, not the people who think it's all sunshine and rainbows. And those people are not kind, and make it sound like the cost is way more than just "8 hours reading the docs" \-- in fact, the docs are often called out as part of the problem.

<comment><USER4> > _As Kernighan said back in the 1970 's, "Everyone knows that debugging is > twice as hard as writing a program in the first place. So if you're as > clever as you can be when you write it, how will you ever debug it?"_

What a great quote. Thanks

<comment><USER5> Some more quotes taken from [http://typicalprogrammer.com/what-does-code- readability-mean](http://typicalprogrammer.com/what-does-code-readability- mean) that you might find interesting.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. – Martin Fowler

Just because people tell you it can't be done, that doesn't necessarily mean that it can't be done. It just means that they can't do it. – Anders Hejlsberg

The true test of intelligence is not how much we know how to do, but how to behave when we don't know what to do. – John Holt

Controlling complexity is the essence of computer programming. – Brian W. Kernighan

The most important property of a program is whether it accomplishes the intention of its user. – C.A.R. Hoare

No one in the brief history of computing has ever written a piece of perfect software. It's unlikely that you'll be the first. – Andy Hunt

</comment></comment></comment></comment><comment><USER6> I currently use Ansible to provision and configure about 50 instances with various home grown services deployed on them, and I'm quite happy with that.

I don't use Docker, or Kubernetes. What am I missing here? This is an honest question.

I don't particularly see the point of docker in production. I guess it can help resolve clashes between dependencies, but I'm doing ok with Ansible.

One guy in another team just tells his application developers to throw everything into a docker container and then deploys whatever they give him. I guess that prevents dependency clashes, sure, but to me that seems like it's just inviting different problems though. (Containers with a lot of disorganized junk in them).

And we don't need to grow the cluster for now, so I don't see the point of k8. We already have log aggregation, and service restarting, service monitring/metrics.

To me, Kubernetes feels like a brand new alternative OS with crappy documentation.

On the other hand I've been managing UNIX machines for 20+ years, and that I do know how to fix (mostly, since they keep changing linux so much these days, it's almost as hard to keep up with as javascript).

If somebody could tell me what I'm missing by using this approach, I'd be grateful.

<comment><USER7> What do you use for log aggregation and monitoring/metrics? And how do you deploy new versions with zero downtime? And how do you manage kernel/OS upgrades?

<comment><USER6> > log aggregation

Graylog, with applications using various GELF libraries to send logs to it.

> metrics

graphite/grafana

> And how do you deploy new versions with zero downtime?

I don't deploy with _zero_ downtime, but within say ~5min. This is acceptable to us. We use jenkins with a lot of tests to ensure components are in good shape, then we mostly manually deploy them, but with a script. Sometimes we deploy directly from jenkins.

> Kernel os upgrades

All our stuff is internally hosted, so we handle those infrequently. This stuff isn't exposed the the open internet, so we upgrade when we get around to it, or when we encounter a bug.

<comment><USER7> Thanks for following up! I'm not surprised because I noticed on HN and in other online discussions that almost all the people that advocate against Kubernetes and PaaS (Heroku, App Engine, Clever Cloud, Scalingo, etc.) are willing to tolerate downtime during deploys and during OS upgrades.

<comment><USER6> > are willing to tolerate downtime during deploys and during OS upgrades.

Yeah, that's not a big deal for us. We don't have customers, and this environment is for internal use at the company.

You could say it's a 'semi production' environment.

<comment><USER7> I like the "semi-production" concept :-)

</comment></comment></comment></comment></comment></comment><comment><USER8> Over the years, I've deployed applications using various combinations of custom RPMs, Chef, Heroku, Docker, ECS and Kubernetes.

If you can, you should probably deploy to Heroku. (Or a similar service.) It's far cheaper than spending time on devops. Just run "git push" and you're running.

When I've deployed on ECS (or other "simple" orchestrators), I've found that I ultimately wound up re-inventing lots of Kubernetes features.

So if you can't use Heroku, but you _do_ know basic Docker, then it's worth considering somebody's fully-managed Kubernetes. Google's is nice. Amazon's is a considerably more work. I hear Microsoft's is still a bit sketchy. And I'd love to take a look at Digital Ocean's. But do _not_ attempt to host your own Kubernetes if you can possibly avoid it.

If you do try Kubernetes, then read a book like _Kubernetes: Up & Running_ first. Kubernetes is not self-explanatory, but it's pretty straightforward if you're willing to spend a few days reading.

Finally, don't overcomplicate it. Just use the basic stuff for as long as you can before trying to layer all sorts of other tools over it.

<comment><USER9> Isn't Heroku really expensive though? I looked at it a few weeks ago and the cheapest plan was $25/month (there's also a $7 "Hobby" plan though, but that seems just for, well, hobby stuff?)

I instead got a Linode VPS at $5/month, which gives me more than the $25 Heroku plan? Setting up a VPS is not very hard either – although this may depend a bit on your environment, my app compiles to a static binary – and a lot more flexible.

My devops stack thus far consists of scp and tmux.

<comment><USER10> Suggesting that $25/month is expensive illustrates how insanely cost-sensitive this community is.

Don't come to HN for a representative take of how people in US businesses evaluate vendors and their pricing.

Do you know how much it cost my employer for me to spend an hour reading about Kubernetes?

<comment><USER11> Not everyone is thinking in terms of an employer, or looking to build a profitable business. One of the main sticking point for my side projects is related to deployment environments.

Heroku is painless enough for unprofitable hobby projects, but far too expensive. Using AWS, GCP or Azure directly is relatively affordable, but requires a lot of extra work.

I'm aware of various tools that are supposed to make working with the various cloud platforms much easier, but every time I see one of these used in practice (eg at work), people seem to spend an enormous amount of time getting things working properly. It still feels like we're missing a sweet spot for hobbyists who don't want to invest their spare time learning about and wrangling with devops, just to get a simple project up and running.

<comment><USER12> Has anyone ever recommended Kubernetes to anybody as a production environment for an "unprofitable hobby project"? In the context of the article we're discussing, the suggestion that $30 is an unreasonable operations overhead for a team of four engineers is thoroughly preposterous.

</comment></comment></comment></comment></comment><comment><USER13> This starts with a lot of "you don't need Kubernetes" and then concludes with a pretty compelling argument in favor of using Kubernetes.

From the "The Nomad ecosystem of loosely coupled components" section:

> It integrates very well with other - completely optional - products like > Consul (a key-value store) or Vault (for secrets handling).

> At trivago, we tag all services, which expose metrics, with trv-metrics. > This way, Prometheus finds the services via Consul and periodically scrapes > the /metrics endpoint for new data.

> The same can be done for logs by integrating Loki for example.

> Trigger a Jenkins job using a webhook and Consul watches to redeploy your > Nomad job on service config changes.

 _shudder_

> Use Ceph to add a distributed file system to Nomad.

> Use fabio for load balancing.

And the icing on the cake:

> All of this allowed us to grow our infrastructure organically without too > much up-front commitment.

So if I understand correctly, the author (and his team) preferred to do all the work of integrating/testing/debugging those components, rather than using a tool that provides every single on of those features, and more, out of the box.

Kubernetes isn't a trivial lift but it's a damn sight easier than trying to roll a cheap imitation yourself.

<comment><USER14> The point is that Nomad allows to add more components as they are needed while Kubernetes is an all-or-nothing solution. Also, we used tools like Jenkins and Ceph before. They have been tested and we trust them so there's no point in replacing them. Quite the contrary: a lot of internal processes depend on them so it would have been painful to migrate away from them.

Nomad is not a cheap imitation of Kubernetes, it is a simple orchestrator which favors composability over an all-in-one approach.

<comment><USER13> > Nomad is not a cheap imitation of Kubernetes

 _Nomad_ isn't a cheap imitation of Kubernetes but all these components taped together _are_. Kubernetes is no less composable than a system built on Nomad, it just includes more functionality from day one.

If you're running containers with a orchestrator like Nomad, at some point, you'll need DNS. So you do it yourself and then you're managing Nomad and DNS. Then (we'll assume, because you're using a container orchestrator to manage multiple services) you'll need service discovery, so you write some jobs and event handlers to glue together Nomad and your DNS solution. And then, because you're a team of responsible people, you'll want to store secrets securely, so you graft in Vault. And _then_ , you realize zero-downtime config changes would be great, so you slap Consul in there and write some sidecars or library code to handle config updates. Then metrics. Then logs. Then rolling deployments. And it continues, indefinitely, as you add features.

If you started doing this five years ago, fine. If you start doing this _today_ , you're out of your mind. You're just doing work for the sake of "but it's composable". There's a reason why teams still build applications on frameworks like Rails and Django even though they don't need half the features --it's more important to them to get something functional up and running than it is to satisfy delicate sensibilities about only using what's needed. Kubernetes is the analogue in the world of systems and operations.

<comment><USER15> your description of "grafting in" consul and vault _is_ exactly what it feels like to do that with kubernetes, and it happens rather often.

Using industry standard components like consul and vault is not really a second thought for k8s in production, leaving you with duplicated hunks of infrastructure to step around, where the idea of tacking on kube-dns and kubernetes ~secrets~ onto something else is rather laughable. This, again, is the point which was being made -- you're forced to bear the brunt of kubernetes' NIH.

I'll assume by the contrived situations of inventing some wacky custom mousetrap to bind nomad to dns rather than using the "slapped in" ([https://www.nomadproject.io/docs/configuration/consul.html](https://www.nomadproject.io/docs/configuration/consul.html)) consul integration for dns, or writing config update/logs/rolling deployment code rather than using the core nomad scheduler features to do that, that you don't actually know, and this is FUD?

</comment></comment></comment></comment><comment><USER16> I've started heavily using Nomad recently and it's a real joy. Adding things in is just so easy because it doesn't do much and (mostly) everything is very well defined. I cannot suggest it highly enough.

An example is I setup a log pipeline recently spanning multiple data centers with full mTLS. It wasn't that hard and thanks to Vault all the certs are refreshed at regular intervals all over the place. Pretty great!

<comment><USER17> +1 for Nomad, I'm extremely impressed with all of the Hashicorp suite.

Single binary deployments and upgrades are helpful.

<comment><USER18> even Terraform?

<comment><USER16> I manage everything soup to nuts with Terraform. If you know something vastly better please let me know, especially considering the changes to 0.12. It's a very well integrated system.

<comment><USER18> what kind of infrastructure are you managing? if you're in the aws cloud, CloudFormation is the gold standard for "infrastructure as code".

<comment><USER19> says you

<comment><USER18> Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed.

do you know who can rollback and leaves your infra in a consistent state? can you guess?

<comment><USER19> yea that is surprising that you can't roll back when you first start with terraform but as you gain more experience with it, you realize that not rolling back means you can resume instead. And if you need to roll back, you can do so by just running destroy. It's actually a feature, not a bug.

<comment><USER18> no it's not. i want to leave my infrastructure in a consistent state. i am in state A and want to move to state B. I want it to work. I don't want a half- assed attempt to make it work.

what does terraform bring to the table? I have to use HCL to describe my infrastructure in terms that are NOT cloud agnostic (therefore introducing another layer) and in the face of adversity it throws its hands in the air and now you've got to figure out what went wrong, manually, by yourself. This is what I call True Devops (TM).

I have seen Terraform crap out and it cannot recover. It cannot move forward, it cannot rollback, it cannot destroy. It's stuck. At that point you start praying that someone really understands the underlying cloud + knows the shenanigans terraform plays to fix it now and also make terraform happy moving forward.

we're talking basic stuff here.

i don't want to go into more advanced issues like: losing network connectivity, terraform process crashing (think oom conditions) or being killed or non-responsive cloud apis.

not to mention that destroying infrastructure you've created almost never works (unless it's trivial infrastructure).

based on what I've seen up until now I would not use terraform in a production environment.

<comment><USER19> If I had experienced what you just described, I would probably have the same opinion - but after the initial learning curve, I haven't really had any of the problems you've listed. The only times I've had to go manually modify cloud resources to fix something was always because I was doing it wrong in the first place.

On the other hand, CloudFormation is not perfect either. The rollback does not work 100% of the time and I've had it roll back a set of templates that took 45 minutes to deploy because there was some inconsequential timeout that could have been ignored. I've also had pre-built templates developed by AWS outright fail, which is strange considering AWS themselves built it.

Use what works best for you and your team.

<comment><USER18> so I ran into the issues I'm mentioning while test driving it.

i have never experienced unpredictable behavior from CloudFormation, but it's possible YMMV.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> So many comments here are touting the benefits of this, that or the other, but aren't mentioning Nomad at all. Nomad is definitely worth a try even for large deployments. Yea, it doesn't autoscale without 3rd party tools, but you don't always need that.

If you just need to keep your jobs running, load balance to those apps, use externalized config and need a simple UI view system status, then Nomad/Consul/Fabio really works great.

</comment><comment><USER20> I've been running SmartOS containers for 6+ years and it's the best of all worlds. Easy service management, works with regular binaries or Dockerized deploys, SDN always built-in, service discovery built-in (CNS), even Windows VMs available. Best kept secret in the cloud even though the entire stack is open-source.

On the orchestration side I use Puppet Pipelines (formally Distelli) which works with standard VMs, SmartOS containers, Docker, Linux images, from packaging through testing and deployment. And they just lowered pricing (!??!)

There's no reason to be locked into Kubernetes unless you're sure you need it. SmartOS scales in seconds. As CTO I'm always checking out the next platform, but all the newer solutions look much more complicated.

EDIT: Heroku has weird errors when you push CPU or RAM, also the CPUs aren't so fast, Linode can't be trusted, Digital Ocean is OK but is still very manual roll-your-own, AWS is a behemoth and medium fast, Google is fine but specialized and hard to migrate away from, OpenStack isn't for small orgs... I've run production services on them all. It's easy to try a new service with a Pipelines-style orchestration because it doesn't care which service its talking to. And makes it obvious when platform-specific instructions or concessions are required.

<comment><USER21> Thanks for your insight.

Why can't Linode be trusted?

<comment><USER22> They've proven many times that they're not. Read through slashdot and google for "linode bitcoin stolen"

</comment></comment></comment><comment><USER23> For most small deployments you are far better off using Ansible playbooks or similar solutions. Declarative orchestration management seems, for most relatively small and medium-sized deployments, a black box with an obscenely high learning curve which isn't justified if your deployment and scaling needs fall within the vast majority of use cases.

<comment><USER24> If someone on a small team brings K8S expertise to the table, it is worth considering. Otherwise, yeah, if you're at the stage where your team is focusing on building the product, then K8S is going to be a distraction.

<comment><USER25> > If someone on a small team brings K8S expertise to the table, it is worth > considering.

Perhaps you have some unstated assumptions here like a small team managing a relatively large infrastructure for their team size? Or, a small team in a much larger infrastructure department.

If it was me, I'd put lots of disclaimers around a single person bringing any kind of specialist expertise to the average small team. I think you need to lean on that person to level the whole team up. If there is any chance of that individual leaving you risk leaving the team high and dry.

<comment><USER26> You can use managed Kubernetes. And that person with expertise would mostly influence design decisions in order to write software that is easily deployed to kubernetes and orchestrated in containers. They wouldn't be a dev ops person taking care of k8s cluster obviously that makes no sense for a small team.

</comment></comment></comment></comment><comment><USER27> Some fair points are made here, and I think running kubernetes the hard way, without a managed service, does introduce a lot of complexity. However, its not that bad when using a managed service such as EKS or GKE

<comment><USER28> Is there any significant difference between e.g. `kubeadm` and `gcloud container clusters`?

I believe when the cluster malfunctions, you're still on your own figuring that out. I had a stuck node on GKE just recently, which broke our CI. The GCE machine was there, but the node wasn't visible with kubeadm and quick SSH onto the VM hadn't discovered any immediately visible obvious issues. Auto-repair was enabled but hadn't worked - and TBH I have no idea how should I've diagnosed why it didn't (if there's even a way).

Thankfully, this was issue with the node, not master, and the CI nodes are all epheremal, so I've quickly dismissed the idea of debugging what went wrong and had just reinitialized the pool. Could've done the same with bare metal.

<comment><USER27> I don't know. I haven't had any random failures using EKS. Anything crashing was of my own doing.

</comment></comment></comment><comment><USER29> I did an eval about 4 years ago of schedulers and service discovery software.

Lot's of cool stuff around (dc/os, triton, hashi, k8s, flynn etc)!

After 2 days with k8s and not so much as a bootstrapped cluster the turn went to hashicorp.

Within 10 min I had a container running, registered in service disc (consul) on my laptop.

We ended up using the hashicorp stack in production with great success. Sure, some custom services was needed (service managment, scaling and such).

Running primarily on prem the complete simpleness and un-opiniated approach is an edge.

It allowed us to implement MACVLAN at first, and the ubuntu FAN-network and integrate totally with existing infrastructure.

Now having spent the last 8 months implementing k8s I'm torn.

I've built from scratch, used kubeadm, kops and now EKS. From 1.13 kubeadm honestly works really well and is my prefered way of deploying k8s.

Still it's a beast... running large deployments with many teams... there's just so much... stuff.

One GH issue leading down a rabbit hole of other GH and gists with conflicting or not working configurations. I've had co-workers bail on the project after mere hours of digging through code and GH discussions and SIG docs.

Nomad/consul and it's concise docs is a breeze in comparision.

Torn. Cause I see the point of k8s, just not sure about the project. :)

</comment><comment><USER22> I'm very much in the camp of "Kubernetes is a problem factory".

Personally, I've found very few problems that it solves and more problems that it creates. That said, its probably a great time to be a Kube consultant!

<comment><USER18> if your team is only a handful of devs who work on the thing that pays the bills + do k8s, yes. bad time. the only way i could justify running this is if you're using a managed solution like gke or eks.

otoh, if you're in the cloud, you already have the primitives to build your stuff w/o the k8s headache (vms, autoscalling, managed svcs). but that's just my opinion. the koolaid is strong.

<comment><USER22> Honestly, if you have a $GENERIC_SYSTEM that you deploy your code to, you don't need the wasteful overhead.

If you need to (vs want to) rebuild your OS/Environment regularly, you're doing it wrong. IE: PaaS is for you. That said, I've found replicating OS & Environment extremely challenging on certain operating systems so I understand the appeal. I also don't build products on those operating systems and I've found myself much happier :)

<comment><USER18> yeah. it depends a lot and k8s has its place in some scenarios, but in most cases you don't need it and its use is purely driven by koolaid

</comment></comment></comment></comment><comment><USER30> The thing that all the "you don't need kubernetes" articles seem to ignore or skim over, is the huge network effect of a popular setup like k8s.

Not only is it much easier to find services (like helm) and articles for k8s, but there are so many ready to go configurations. For most major services, there is already a ready to go helm chart or at least some well vetted yml config on GitHub to start from.

And most any issue I have come across, I have been able to search and find solutions.

<comment><USER15> The thing the 'there's a ready to go helm chart' folks always seem to skim over is that outside of an absolute startup position where you can curlbash to hello world heaven, you will have integration to do, often huge amounts of customization (read: complete rebuild) to do to take a toy helm app configuration to a production configuration, and I've never seen even so much as a nascent k8s (or nomad, mesos, etc.) buildout leveraged in a preexisting environment without quite a bit of pipeline, acl/naming convention and ux glue.

The proliferation of operators, CRDs, things like k3s and the growing ecosystem of vendor distributions makes 'stock k8s' an increasingly nebulous target.

<comment><USER31> I think CRDs are mostly going to be a quagmire. It's Wordpress plugins all over again, if Wordpress plugins could also affect the OS kernel.

</comment></comment></comment><comment><USER32> One argument that I think has been propelling kubernetes is that projects using orchestrated containers benefit from a consistent application environment, and such orchestrated deploys can be much more easily distributed when the entire stack configuration can be packaged, and it enables greater out-of-the-box functionality like autoscaling for the teams deploying these projects--the zero to jupyterhub project is a great example: [https://zero-to- jupyterhub.readthedocs.io/en/latest/](https://zero-to- jupyterhub.readthedocs.io/en/latest/)

</comment><comment><USER33> The author mentions coupling with kubernetes due to config maps and such. That is certainly a risk, but if you use environment variables for config (which IMHO you should) then k8s makes it trivial to just map your ConfigMap to Environment Variables.

I've got a few apps running in k8s and none of them know anything about k8s. If avoiding coupling with k8s is what you want (and I agree it's the way to go) then it really isn't that bad. The hard part is not knowing what you don't know.

<comment><USER34> I think the real question then is why are people running apps that need to be k8s-aware at all? K8s already provides a number of primitives to solve many problems without reinventing the wheel and going "cloud-native" within the application. There should be a very strong reason for any need to access the api directly.

</comment></comment><comment><USER35> > Kubernetes is an Ancient Greek word meaning "More containers than > customers." [1]

[1] [https://twitter.com/srbaker/status/1002286820078571532?lang=...](https://twitter.com/srbaker/status/1002286820078571532?lang=en)

</comment><comment><USER36> Rancher [1] looks really nice for a guided use of Kubernetes. I saw a demo on how to use this with Digital Ocean's Kubernetes clusters; the presenter went from having a blog in a container to having the blog on a K8s cluster behind a domain name in 30-ish minutes. Anybody using Rancher?

[1]: [https://rancher.com](https://rancher.com)

<comment><USER37> Do you have any info regarding Rancher pricing? There is no info on their website other than reaching out to them...

<comment><USER38> (Rancher employee) All the software is free to use and open source (Apache 2). Customers run the same software that's on GitHub/DockerHub.

We sell "enterprise support", which means something like "starting at mid-5 figures", and occasionally professional services engagements around/outside the product.

</comment></comment></comment><comment><USER39> +1 Nomad is great. You can run services that aren't dockerized easily.

</comment><comment><USER40> Its usually when these kinds of articles come out that their subjects are finally worth paying attention to.

Immutable infrastructure is the right thing to do. Maybe K8's isn't the best or most convenient way to achieve that, but it gets you almost all the way there to fully declarative ops. I really think there is a lot of room to improve the ergonimics. That said, there is a business/project opportunity. I want to be able to build a values.yml file in a gui, on my phone, with bounded sliders and smart recommendations for values, along with contextual help and community templates. We have chart repos, but the default values suck for production, and learning what the values are and should be set to for your use case leads to a painful traversal of abstractions. Maybe there is already a project or vendor out there I'm missing?

</comment><comment><USER41> All any of us really need to do is put files on a server and start a process. The question is how much scaffolding you want to build and manage to achieve it. The answer should be "as little as possible".

</comment><comment><USER42> At work we have about 50 containers, which total RAM usage less than 32GB and about 10 CPU cores.

Docker swarm works great for us

<comment><USER43> I was scrolling down the comments for Swarm. Do you run multimachine? How does storage work? (I'm looking for an container thingy for bare metal)

<comment><USER42> Yup multimachine. It works fantastic. We have a netapp san [https://hub.docker.com/plugins/trident](https://hub.docker.com/plugins/trident) But we don't really use it except for databases

</comment></comment></comment><comment><USER44> 1\. Always think about Heroku first, seriously. Because your need is deploy application.

2\. If you thought about 1 but Heroku is really not for you, go Kubernetes directly. It's not that hard at all.

3\. Choose any other stuff only when you know what you're doing.

Kubernetes is not simple or good. The api is mostly cumbersome. But it's the first thing that makes sense in this field. Before Kubernetes there are just toys or rocket science.

</comment><comment><USER45> I'm attempting to 'transition' \-- as a DevOps / infra guy professionally rather than pure dev -- does anyone have any recommended resources for reading non-dry, fairly example-filled docs to get started? The Kubernetes O'Reilly book seems to be very broad and overly high-level from the reviews (and I remember best if I read "why" and "how").

Thanks in advance

<comment><USER46> This is particularly well-liked for a more in-depth review of Kubernetes: [https://github.com/kelseyhightower/kubernetes-the-hard- way](https://github.com/kelseyhightower/kubernetes-the-hard-way)

</comment></comment><comment><USER47> I've come to much the same conclusions as the author in this blog post and have put together a small Nomad demo in case someone is interested: [https://github.com/rbjorklin/nomad-demo](https://github.com/rbjorklin/nomad- demo)

</comment><comment><USER48> > It takes a fair amount of time and energy to stay up-to-date with the best > practices and latest tooling. Kubectl, minikube, kubeadm, helm, tiller, > kops, oc - the list goes on and on.

When you start with a technology, you need to have a solid basis. You need to fully grasp the given technology in it's most basic forms, stuck with the problems for days so you can fully grasp what any of these can solve what problem. If you know "naked" Kubernetes inside and out, then you can add other things to your toolset. Until then, you don't need no helm, tiller, kops, Knative or any of those distractions.

<comment><USER49> Isn't knative exactly supposed to solve this problem by giving a portable Heroku-like dev experience?

<comment><USER48> Doesn't matter. I talked about the initial learning about Kubernetes. It's just too much to learn everything at once.

<comment><USER31> Restating: the point is to not have to "learn everything". If your platform makes you do hours of homework, then it's not a platform, it's a pallet of bricks.

Heroku got this right with `git push heroku master`. IMO Cloud Foundry got it even more right with `cf push`.

Knative is likely to get to that point, probably with the same means as Heroku and Cloud Foundry: Buildpacks.

I'm wildly biased of course, having worked on Cloud Foundry, Buildpacks and Knative.

</comment></comment></comment></comment><comment><USER50> I've been using Kubernetes for a while (1,5y). And I can't say I'm very impressed. For anything simple it works fairly well. But as soon you get outside the "normal" workflow it gets downright hard. Certain areas are opaque AF and if things doesn't work it almost impossible to find out why. And if it's impossible to fix something fast if there's something burning. I think that, there's an irony to k8s, it's supposed to fix the "hard problems" of clusters. But it really only fixes the easy part of them, and obscures the rest.

</comment><comment><USER51> The overall trend of IT infrastructure goes from tradition DC -> IaaS -> PaaS -> FaaS. k8 sits at PaaS and the logically next step is FaaS/serverless.

In fact, today you can surely do purely FaaS without the need k8 at all by leveraging cloud provider managed services for any long-live type of workload. Of course, the tradeoffs will the usual suspects: flexibility, control, cost etc. There are still cases where you would want a cluster manager like k8 (at least for now).

</comment><comment><USER52> Any reason you didn't consider Docker swarm?

<comment><USER14> I like swarm. Seems like Docker is moving away from it however. At least, that's what the commit numbers say [1]. The fact that Docker integrated Kubernetes into their desktop solutions is also telling.

At this point, I would rather have a closer look at either Nomad or k3s for smaller clusters.

[1]: [https://github.com/docker/swarm/graphs/contributors](https://github.com/docker/swarm/graphs/contributors)

<comment><USER53> Wrong repo. [https://stackoverflow.com/questions/38474424/the-relation- be...](https://stackoverflow.com/questions/38474424/the-relation-between- docker-swarm-and-docker-swarmkit)

Swarmkit is what is being used in production and is fairly popular.

[https://www.digitalocean.com/currents/june-2018/](https://www.digitalocean.com/currents/june-2018/)

 _" While @kubernetesio was most popular overall, the smallest companies (1-5 employees) use @Docker Swarm more often (41 percent use Swarm vs. 31 percent that use Kubernetes)."_

</comment></comment></comment><comment><USER43> I'm curious how this compares to pacemaker and corosync for core infra devices like a active/passive failover for SAN or a virtual IP. It doesn't seem like they're in the same category in terms of typical usage, but both can handle the notion of a cluster.

</comment><comment><USER54> Triggered by Matthias' blog post, I wrote down my thoughts on the topic here: [https://srcco.de/posts/why-kubernetes.html](https://srcco.de/posts/why- kubernetes.html)

</comment><comment><USER48> I'm pretty sure you don't need Kubernetes.

</comment><comment><USER55> Docker Compose is great, Docker Swarm isn't.

</comment><comment><USER56> Yes i do, [https://homeidea3d.com](https://homeidea3d.com) runs on kubernetes

</comment><comment><USER57> anyone got recommendation on how to properly set CPU limits?

I've set limits about 2x higher than the max cpu usage, but still seeing some throttling, what cause performance degradation. I've ended up setting deployments without limits to avoid throttling but that's definitely not nice if one pod goes crazy for a reason ...

<comment><USER58> Not sure what you mean by throttling. I tell my customers to do 4 things

       1) Set a Request at about 50% of max CPU usage
       2) Set a Limit at about 90% of max CPU usage
       3) Configure a HorizontalPodAutoscaler that kicks in at 70%
       4) Scale out, in advance, to 2 or 3 pod replicas

</comment></comment><comment><USER59> Have you looked at [https://habitat.sh](https://habitat.sh) ?

<comment><USER14> I actually did and I love the idea!

In my opinion, that's gonna be the next wave of container management solutions. If you think about it, you shouldn't care about container orchestration at all; you should care about services.

Habitat ships the orchestrator together with every service. That sounds strange and redundant at first, but if you think about it, it has some nice advantages:

* Services are fully self-contained and can run anywhere (in dev, stage, prod) without any changes. * By tagging services, one can create a service-mesh quite easily without having to think about network-topologies. Services find each other automatically (I think via a Raft/Gossip protocol).

I haven't looked at it too closely yet, but it's on my list. Fair disclaimer: I know the folks behind it from the Rust community.

</comment></comment><comment><USER60> I guess I am a little behind the times, but no one uses the orchestration stuff that comes with Docker?

<comment><USER61> I use it a fair bit for development, provides a seemingly simple way to keep things organized and do 'infra-as-code' and have your ducks in a row with reproducible stack deployments, without the overwhelming overhead of k8s.

It's an absolute dumpster fire though. A serious convoluted mess. They try to indelicately cram something with incredible intrinsic complexity into a happy little (incredibly leaky) abstraction.

docker compose is really what I want, simple service management on one machine. Except, it can't do really basic shit like restart services (this isn't all that obvious at first). So soon you'll find that you need to use docker swarm on the one node, which is similarly chock full of inexplicable and unforeseeable shortcomings.

docker swarm/compose is an interim step on your journey to a better solution. in my judgement it's fine while you're developing your core apps. but once you need to do get serious and go into production, it's time to find a big boy tool

<comment><USER7> I did the same thing. Docker Compose was what I wanted for a single-machine deployment, but I soon discovered it was unable to manage a rolling deploy (start new containers before stopping the old ones). So I switched to Docker Swarm on a single node, but I have to agree there is a lot of unexpected shortcomings. I'd like it to be more polished. And I'd like Docker Compose and Docker swarm mode to converge/merge at some point.

I guess the "big boy tool" you adopted after that is k8s?

<comment><USER61> No I never got the point of needing the big boy tool. But it would have been k8s.

</comment></comment></comment></comment><comment><USER62> I only use Docker, because I'm too lazy to learn Kuberneres or Ansible. :)

</comment><comment><USER63> If people would spend 1/10th the time they spent complaining about kubernetes actually learning kubernetes, maybe more people would know kubernetes and realize its not even that difficult to administrate.

</comment><comment><USER64> Should we use containers at all is the _first_ question. Why people skip over this one ? :)

</comment><comment><USER65> Maybe all you need is NodeChef. Saves you time and money. [https://www.nodechef.com/](https://www.nodechef.com/)

</comment><comment><USER66> Pretty much just an advertisement for Nomad.

<comment><USER67> I'm not sure why you are getting downvoted but I'm a bit suspicious. Either he really likes Nomad that he went ahead and put their logo on a scooter or a disclaimer is lacking.

<comment><USER14> I put the logo on a scooter. Not affiliated in any way with HashiCorp.

</comment></comment></comment><comment><USER68> I spent a few days developing a Kubernetes Cluster with some Docker knowledge. Other than creating the config file, I didn't see too much of a problem. It definitely has a learning curve and takes a lot of time to setup (even with GKE).

From reading this article, I'm liking Nomad.

</comment><comment><USER69> It's a bit strange to say the best part of Nomad is its ecosystem, then to go on to say it has 10x less contributors than Kubernetes.

Additionally, one of the benefits is... a lack of features?

> The entire point of Nomad is that it does less: it doesn't include fine- > grained rights management or advanced network policies, and that's by > design.

PodSecurityPolicies and advanced Network Policies are not a default or required part of Kubernetes, either...

<comment><USER14> 10x less contributors than Kubernetes is still over 200 contributors (actually more like 300 at this point). That's one of the bigger Open Source projects in my book. This number pales in comparison to Kubernetes, but show me a project which doesn't.

That doesn't mean that the ecosystem is not vibrant, however. The HashiCorp stack is just more modular than Kubernetes. Consul and Vault are standalone products for example.

With less functionality, it's harder to build a system which depends on features that only exist in a particular orchestrator. This makes it easier to replace Nomad with something better in the future. I'm not sure if I'd want to work on migrating Kubernetes clusters in five years. :)

<comment><USER70> There's almost nothing proprietary about kubernetes. As the next post said, it uses dns. Which part are you referring to that it locks you into?</comment></comment></comment>


NoJS - The Smallest JS Framework - <AUTHOR> http://strd6.github.com/NoJS/

<comment><USER2> This has been done before: <https://github.com/madrobby/vapor.js>

<comment><AUTHOR> But do they have a Todo List demo? <http://strd6.github.com/NoJS/demo.html></comment></comment>


Timeless Decision Theory [pdf] - <AUTHOR> http://intelligence.org/files/TDT.pdf <comment><USER2> This is a relatively old manuscript, and I would recommend instead reading, or at least first reading:

* [http://intelligence.org/files/ProblemClassDominance.pdf](http://intelligence.org/files/ProblemClassDominance.pdf)

* [http://arxiv.org/abs/1401.5577](http://arxiv.org/abs/1401.5577)

(The original TDT manuscript occurred via pleas for 'something, anything to be published' that were satisfied by cleaning up an unfinished book draft and publishing it as-was.)

<comment><USER3> Is there a canonical list of "remaining open problems" that need solving in order to construct a useful AI (or rather, a more-powerful-than-human optimization process), other than the construction and validation of a sufficiently robust decision theory?

<comment><USER2> Producing this is my major current writing project. Meanwhile, [http://intelligence.org/files/TechnicalAgenda.pdf](http://intelligence.org/files/TechnicalAgenda.pdf)

</comment></comment></comment><comment><USER4> I believe the folks at MIRI spend most their time on Wei Dai's Updateless Decision Theory now.

MIRI is strange. Five years ago, I was convinced they were very misguided or cranks, but I've been reading some of their logic stuff and much of it is pretty neat. I also attended a talk by Yudkowsky at MIT and it was also very good. I'm not sure what to think now.

<comment><USER2> I affirm that UDT has replaced TDT. Updateless Decision Theory is by Wei Dai and Vladimir Nesov with major contributions from several others.

<comment><USER5> Why?

</comment></comment></comment><comment><USER6> Let's say a person is faced with Newcomb's Problem every day, and its decision is made public every time.

If the person has always taken B, then the Predictor will probably guess that the person will take B again, and therefore place $1,000,000 in B. By always choosing B, the person "wins".

If the person doesn't always take B, then the Predictor probably can't guess what the person will take, and B will be empty. By taking A and B, the person can only get $1,000.

The mechanism of Trust is exactly this. Whenever you're faced with a question, lying (to your advantage) will always increase the odds of a better outcome (like taking both A and B). However, that trick doesn't scale, and you can't use it anymore once a lie is discovered, once trust is lost.

</comment><comment><USER7> Most of the argument I've seen for this involves some very theoretical and unlikely circumstances. Can anybody boil down (a) the decision process that leads to cooperating in the one-shot prisoners' dilemma, and (b) the reason an agent would prefer to use that decision process? That would be a remarkable result.

I confess I haven't read the whole 100-page paper, but I've scanned it and I'm having trouble finding an algorithm concrete enough to be expressed in code.

<comment><USER2> [http://arxiv.org/abs/1401.5577](http://arxiv.org/abs/1401.5577)

</comment></comment><comment><USER8> There is something wery odd about Newcomb's Problem. If the Predictor can predict my choice with 100% accuracy, it's not really a choice, is it? Free will does not exist in this scenario, and therefore I cannot meaningfully choose between one or both boxes. The question is nonsensical.

<comment><USER9> Instead of choosing a box, submit the source code of a program that decides whether or not to open a box. Then, the predictor reads the source code, puts money in boxes, and only then does your source code run and open boxes.

Now, imagine that there was a computer program that makes the same choices you do in the same situations, and the Predictor can read that source code before filling the boxes.

That's the intuition pump I use for thinking about Newcomb-like problems.

<comment><USER10> I might be mistaken, but it seems to me that the predictor should also be able to solve the halting problem. Additionally, if the entity to which the source- code is a descriptor for is so simple that they can be predicted without full simulation, can we really say they had free will?

<comment><USER11> The program isn't given infinite time to run so its not a halting problem case.

</comment></comment></comment></comment><comment><USER12> [2010]

</comment><comment><USER13> Never mention [http://rationalwiki.org/wiki/Roko's_basilisk](http://rationalwiki.org/wiki/Roko's_basilisk)</comment>


Can blockchain technology send notaries on vacation… for good? - <AUTHOR> https://medium.com/@Stampery/can-blockchain-technology-send-notaries-on-vacation-for-good-4b99df14de7d

<comment><USER2> Not all problems have a solution that involves writing code.

<comment><AUTHOR> This one absolutely does.</comment></comment>


Supreme Court, in Big Leap, Plans to Put Filings Online - <AUTHOR> http://www.nytimes.com/2015/01/01/us/politics/supreme-court-plans-to-provide-briefs-and-filings-electronically.html

<comment><USER2> The article begs the question: Will it be completely free or behind yet another artificial but officially-sanctioned paywall and login like PACER.gov? The article clearly didn't any meaningful research because PACER and similar state/federal outsourced/homegrown paywalls are bullshit, and likely why SCOTUS advocated a separate system. The key is whether it will truly provide free and open access to decisions and documents. If not, it would be another Not Invented Here duplication of PACER. (Let's assume it won't be as crappy as PACER, because SCOTUS is presumed to contain a measure of common-sense.)

The bigger meta question is: why are courts still allowed to monetize the automated services that are provided at neglible unit cost? Just because lawyers are often chisels doesn't mean the government is allowed to profit from the restriction of access to the people's information, and that automated processes (downloading PDFs) are no longer equivocable to manually making copies of thousands of pages of documents. This puts an undue burden on most people that don't have millions of dollars to throw around and it puts up a barrier to actual transparency of legal artifacts. These sorts of things should be free, but the article does neither explicitly state nor implicitly hint to the cost of this yet-to-be-named SCOTUS system.

Even more meta: Shouldn't civil rights include the freedom to access all public information produced by a government with minimal (at cost of delivery) or no cost?

(IANALBIPOOTI)

</comment><comment><USER3> This is a positive development overall--likely in response to pressure from Senator Leahy, who chairs (or is about to have chaired?) the Senate Judiciary Committee--but a lot of things make no sense.

\- Supreme Court documents will be free. That's great. But district and appellate documents will still be $0.10 per page? Why? Both are public information. Arguably if Supreme Court documents are _more_ important, then they should be more valuable, and therefore more expensive. This is totally inconsistent and no explanation is given.

\- Taxpayers now have to foot the bill (many tens of millions and counting) for "NextGen" CM/ECF _and_ this supposed separate system for the Supreme Court that will not be available until 2016. So far the only next-generation feature released as part of NextGen CM/ECF is the ability to have one username and a password you set yourself. For this we have paid many, many millions of dollars over about five years.

\- Roberts cites procurement considerations to justify the totally unacceptable delay in adopting technology. Yet where are the RFPs for NextGen CM/ECF and the Supreme Court's docketing system? Why, they're nowhere to be found, either because they don't exist or they're not publicly available.

\- Roberts argues that the courts have an obligation to avoid jumping on technological bandwagons too quickly. Perhaps that's prudent. He fails, however, to address courts using technology as a weapon against the poor. See [http://www.aarongreenspan.com/writing/20130217/petitioning-r...](http://www.aarongreenspan.com/writing/20130217/petitioning- rube-goldbergs-supreme-court/).

\- Paper filing will still be required. Why?

Fundamentally Roberts' views on technology are a reflection of the views of the profession that created him. Lawyers generally do not believe that they are subject to the same forces as the rest of the world, technological forces included. Roberts posits in his report that technologies "come and go." Well, so do useless (and often harmful), self-important overpriced middlemen who complicate processes that would frequently otherwise be just fine without them.

Meanwhile, my lawsuit against the Administrative Office of the United States Courts over these issues continues. See [http://www.plainsite.org/dockets/29himg3wm/california- northe...](http://www.plainsite.org/dockets/29himg3wm/california-northern- district-court/think-computer-foundation-et-al-v-administrative-office-of-the- united-states-courts-et-al/).</comment>


Face Recognition with 25 Lines of Python Code - <AUTHOR> https://realpython.com/blog/python/face-recognition-with-python/

<comment><USER2> s/Recognition/Detection/</comment>


Flog lets you measure the complexity of your ruby code - <AUTHOR> http://ruby.sadi.st/Flog.html

<comment><USER2> If you're interested in flog but disagree with Ryan's scoring of various constructs, check out the self-flagellation gem: <http://github.com/bscofield/self-flagellation/tree/master>

With it, you can specify score profiles in a YAML file. We've also got a website in the works that will allow people to share score profiles for various types of code (for a Rails app, for a test suite, etc.)

</comment><comment><AUTHOR> This uses the ABC Metric: <http://c2.com/cgi/wiki?AbcMetric>

Does anyone know of other metrics to measure code complexity?</comment>


Jimmy Wales Says Irrelevance, Not Piracy, Will Doom Hollywood - <AUTHOR> http://www.techdirt.com/blog/innovation/articles/20120423/10432918611/jimmy-wales-says-irrelevance-not-piracy-will-doom-hollywood.shtml

<comment><USER2> I'd like to think the same about Jimmy Wales.</comment>


Stripe moves to JSONP; adds CORS support - <AUTHOR> https://stripe.com/blog/stripejs-and-jsonp <comment><USER2> TL;DR; JSONP is the only hack that is IE proof

 _IE6, as usual, doesn't support postMessage._

 _IE6 and IE7 both lack CORS support, while IE8 and IE9 have broken implementations_

Oh what mankind could have achieved by now if we weren't so occupied making our websites work in IEx.

<comment><USER3> Well people need to stop writing code specifically for IE and just stick to web standards. If Google/Facebook/PayPal/All Banks stopped coding hacks to get their sites to work in IE, the users that use IE would have no other choice but to switch to a standards compliant web browser.

<comment><USER4> IE users should get the standard-compliant pure-HTML version which is sure to work on every browser. Only developers who neglected to start there have a problem.

<comment><USER5> I dont buy it. Some features just aren't reasonable to do without js and the number of people without js is tending towards vanishingly small, and you can have a nondegraded experience for a very significant percentage of traffic by not just dismissing all versions of IE. Not that you should support all versions, but if you are sending a separate no-js version to IE10 then you are doing it wrong.

In my experience it is totally absurd to think that you can just write "standards compliant HTML" and expect it to be rendered correctly on IE6 or 7 in any meaningful way anyway, you will always need to change your HTML and CSS to specifically support those browsers and realistically any browser that you want to support, the standards just are not uniformly implemented.

</comment></comment></comment></comment><comment><USER6> I'm curious about how this change handles cross-domain security. Is there never any sensitive data in Stripe.js' JSONP responses? Or do y'all have a mechanism for preventing a malicious 3rd party site from loading a script pointing at one of your JSONP urls?

<comment><USER7> It shouldn't be any different than the existing functionality. stripe.js is solely responsible for turning credit card information into one-use tokens, so that CC information never hits your servers. That token is then used to communicate with Stripe using a private shared key (kept serverside, never exposed on the client) to create a Customer record, which is then used to conduct the actual money parts of the transaction.

So, a malicious party could create tokens with CC information, but without the private key they'd have no way to use them.

<comment><USER8> Yeah, that's right. It's also worth emphasizing that the Stripe API doesn't support sessions, and so isn't vulnerable to standard CSRF attacks.

</comment></comment></comment><comment><USER9> Interesting they choose JSONP (which is GET only, and can't return proper error codes) for such a POST-heavy library. It doesn't _really_ matter, since they abstract it away. However, it's interesting they're completely ignoring so many basic REST principles.

Edit: I don't disagree with their decision, I just imagine it wasn't an easy one.

<comment><USER10> It's not interesting, if you read the post you would know that they did it because of IE lacking support for CORS.

> Unfortunately, that's not quite enough for Stripe.js. IE6 and IE7 both lack > CORS support, while IE8 and IE9 have broken implementations. IE10 is the > only version with a non-buggy CORS implementation. Obviously, compatibility > is paramount for Stripe.js — we want to support all major browsers, right > down to IE6—and so we needed to look elsewhere.

<comment><USER11> FYI, it is true that the implementation is broken in IE8 and IE9, but there is a fairly straightforward fix. [http://mcox.tumblr.com/post/22791023337/ie- cors-support-in-j...](http://mcox.tumblr.com/post/22791023337/ie-cors-support- in-jquery)

</comment></comment></comment><comment><USER12> This seems like a step backward. The iframe-based communication, as hackish as it seems, allows cross-domain communication without resorting to completely unsandboxed script tags referencing a remote server. Meanwhile, JSONP uses a script tag, and nothing forces the response to actually conform to JSONP (JSON wrapped in a specific function call) rather than running arbitrary Javascript code.

<comment><USER13> The only new exploit I can think of is domain hijacking, so that an attacker replaces the real Stripe response with their own. If they can do domain hijacking, though, whether or not they choose to insert the replaced content into a third party page via JSON is a less damaging hack than just swiping your credit card info sent to Stripe.

<comment><USER12> Domain hijacking doesn't seem like an issue here, given HTTPS; if someone can MITM that they can do the same to my own site.

However, just because I trust a service to process payments or do any other specific business-critical task doesn't mean I trust that service to run arbitrary Javascript code in the context of my site. Customers may have significantly more sensitive data than just payment information, and third- party Javascript represents a major issue. I need the ability to confidently say to customers that no third-party service has access to their private data.

Given this new approach, I'd have to sandbox payment code off on a separate domain that has no access to other user data.

<comment><USER7> > However, just because I trust a service to process payments or do any other > specific business-critical task doesn't mean I trust that service to run > arbitrary Javascript code in the context of my site.

You...include their Javascript on your site to even be able to make the JSONP calls in the first place. Their "arbitrary Javascript" is on your domain already.

You certainly could audit it, locally mirror it, and then do that every time they publish an update, but are you actually going to do that?

<comment><USER12> > You certainly could audit it, locally mirror it, and then do that every time > they publish an update, but are you actually going to do that?

Yes, absolutely. For any third-party Javascript, I'd either mirror it locally and review it for safety, or sandbox it on a separate untrusted domain that has no access to customer data.

<comment><USER7> I think the separate domain is a great solution in that case, but my point is that if you're worried about the use of JSONP as the transport being the insecure link, you're too late.

</comment></comment></comment></comment></comment></comment><comment><USER14> Hopefully they add a "pay" Web Intent next.

(The Web Intent polyfill is implemented with the same postMessage hack they were originally using, so technically they could just use the web intent and nothing else. Though in practice, it probably doesn't handle cross-domain iFrame messaging for the old browsers that don't support postMessage.)

</comment><comment><USER15> What's broken about CORS in IE8 and IE9?

<comment><USER16> _Supported somewhat in IE8 and IE9 using the XDomainRequest object_

<http://caniuse.com/#search=cors>

</comment></comment><comment><USER17> Are there any security concerns with this? Is the URL of a GET request over SSL encrypted as well as the payload? I assume it must be if they are sending credit card information that way?

<comment><USER18> SSL/TLS is at a lower level than HTTP. The whole connection is secure as all the encryption is set up before the HTTP request is even sent. This is why SSL used to always require a dedicated IP address - The server didn't even know what domain you were going to while the connection was being set up (as the host name is in the HTTP headers) so you could only have one SSL certificate per IP address.

Server Name Indication (<http://en.wikipedia.org/wiki/Server_Name_Indication>) works around this by sending the host name during the TLS handshake, so that multiple domains can use SSL on the same IP address. In this case, only the host name is sent in the clear. The whole HTTP request and response are still encrypted.

<comment><USER19> If only all browsers supported SNI. The Android 1.x/2.x browser annoyingly doesn't (it's actually the fault of the Java Apache HttpClient). And ~75% of Android users are stuck on it.

</comment></comment></comment><comment><USER20> This is big, it's another functionality that used to be server only moving to the clientside.

</comment><comment><USER21> Sorry for the off-topic comment, but I couldn't help but notice (and comment on) the noticeably slow-loading picture of Alex at the top, only to realize it's a 378KB 500x500 image[1] resized at render-time to 68x68.

I'm just surprised that a tech company like Stripe w/ such a polished site and attention to UX would not find a way to optimize this.

[1] <https://stripe.com/img/about/team/alex.png>

<comment><USER22> MB?! I saw about 300KB.

</comment></comment><comment><USER23> Ewwww JSONP. Keep it RESTful with useful response codes. People accepting credit card payments online should have the ability to do things server-side instead of use JS.

<comment><USER7> You might want to read up on how Stripe works before commenting.</comment></comment>


How GNU Make is tested - <AUTHOR> http://lowlevelbits.org/system-under-test-gnu-make/ <comment><USER2> This looks very similar to how I test my configuration management tool Holo: I just run the compiled binary in a chroot and compare its output and the resulting filesystem tree to the recorded expectation. [1]

So no unit tests at all. I think that unit tests work very well for pure functions, but their utility decreases the more side effects your code has. Also, unit tests usually just add confusion when the unit tested is really an internal implementation detail, rather than refering to some object in the application's or library's external domain model.

[1] [https://github.com/holocm/holo/tree/master/test](https://github.com/holocm/holo/tree/master/test) for the core parts

<comment><USER3> I personally see that as a unit test; Plenty of unit tests use real files on the filesystem in their mocks, you're hermetically sealed from the rest of the system, how is it not a unit test?

I'm just arguing vocabulary, though. There seems to be a spectrum, pure unit tests on one side, then integration tests, with Canaries way off to the other side.

<comment><USER4> Because it is testing the functionality of the entire program (the single executable), not individual component units (functions).

</comment></comment></comment><comment><USER4> > I assume that the reason why most of these failing tests are failing is not > a regression in core functionality of Make but rather because of new > features were added to GNU Make since 2006.

There were a number of bugs in the 3.81 release that I assume they now have tests for, since 4.x has been rock solid. (Off the top of my head, if you made a certain shape in the dependency graph with .PHONY targets, then .DELETE_ON_ERROR stopped working)

<comment><USER5> Yeah, I ran into a very weird problem with the .INTERMEDIATE declaration recently that turned out to be due to 3.81 being buggy.

</comment></comment><comment><USER6> > GNU Make's source code is available from Github repository

It's not GitHub, it's Savannah, as just linked literally 2 lines below :

> > [http://savannah.gnu.org/git/?group=make](http://savannah.gnu.org/git/?group=make)

<comment><USER7> The author already changed the link (as mentioned below). On that note that--- with some GNU projects use GitHub as a mirror---GitHub fails GNU's ethical repository criteria for hosts:

[https://www.gnu.org/software/repo- criteria.html](https://www.gnu.org/software/repo-criteria.html)

<comment><USER8> Do you know which features of github that require javascript? Would be interesting to know from a noscript perspective.

<comment><USER9> Off the top of my head:

\- changing repo's description

\- changing repo's homepage URL

\- changing default branch

\- (un)protecting a branch

\- editing an issue comment

\- adding files to a release

\- removing files from a release

\- removing a release

\- renaming repo

\- removing repo

\- logging out

Most of these could be probably scripted via API, but I'm lazy...

Still better than Bitbucket, which won't you even log in with JS disabled.

<comment><USER7> Thanks for that list; I haven't checked to update in a while. :)

</comment></comment></comment></comment></comment><comment><USER10> But all git repositories are hosted by github. It's in the name.

<comment><USER11> You got to be kidding. Please read VERY CAREFULLY what is Git [1] and what is GitHub [2]. The fact that GitHub only hosts Git repositories is only a matter of choice, Git repositories can be hosted in any server without any (big) restriction. Please restrain yourself from making useless comments if you don't have enough information about it.

[1] [https://en.wikipedia.org/wiki/Git_(software)](https://en.wikipedia.org/wiki/Git_\(software\))

[2] [https://en.wikipedia.org/wiki/GitHub](https://en.wikipedia.org/wiki/GitHub)

<comment><USER12> Given that J_Darnley's HN profile includes a link to his GitLab profile, I think it's fair to guess that he was being sarcastic.

<comment><USER10> Congratulations.

<comment><USER13> I feel badly for the person who didn't realize you were sarcastic, passionately defended the idea that git != github, and got down-voted as their congratulations.</comment></comment></comment></comment></comment>


Full Scale Simulation of SpaceX's Mars Rocket Engine [video] - <AUTHOR> http://on-demand.gputechconf.com/gtc/2015/video/S5398.html

<comment><USER2> Does anyone know why they don't use more modern directional representation systems, like curvelets, or shearlets?

My understanding is that they provide optimally sparse representation of this type of data - data that's smooth except on these wavefront sets, and that wavelets perform comparatively poorly.

[http://en.wikipedia.org/wiki/Shearlet](http://en.wikipedia.org/wiki/Shearlet) [http://en.wikipedia.org/wiki/Curvelet](http://en.wikipedia.org/wiki/Curvelet)

<comment><USER3> Maybe a huge amount of legacy code using wavelets that's been debugged and experimentally validated. CFD code checking is laborious and errors often very subtle, and so tends to be pretty conservative.

</comment></comment><comment><USER4> here's the video file: [http://s3-2u.digitallyspeaking.com/assets/nvidia/events/gtc1...](http://s3-2u.digitallyspeaking.com/assets/nvidia/events/gtc15/S5398_JUAD- ve386a-1300.mp4)

(in case you want to watch at 2x speed in VLC or something)

<comment><USER5> You can also watch it at 2x on YouTube: [https://www.youtube.com/watch?v=vYA0f6R5KAI](https://www.youtube.com/watch?v=vYA0f6R5KAI)

</comment></comment><comment><USER6> In case anyone's interest was piqued by the complicated reaction mechanisms involved in even relatively simple combustion problems, you can automatically generate these mechanisms using software called "Reaction Mechanism Generator" [http://rmg.mit.edu/](http://rmg.mit.edu/) produced by a group in MIT's department of Chemical Engineering.

You wouldn't want to have to determine parameters and pathways for a 53 species 300+ reaction mechanism except in a highly automated fashion.

</comment><comment><AUTHOR> I don't know why the title was changed. The talk is by Adam Lichtl and Stephen Jones.

It features computer fluid dynamic (CFD) simulations of combustion in an accessible manner, though naturally the details are quite complex under the cover.

Keywords, for people wanting to dip their toes: discrete wavelet transform, space partition schemes (BSP, quadrees, octrees), space-filling curves.

The point lookup technique was a little fuzzy and I'd like some more details if possible.

<comment><USER7> > I don't know why the title was changed.

The HN guidelines ask submitters not to change titles except when they are misleading or linkbait. Accordingly, we often change an edited title back to language used by the article itself—usually the original title, sometimes a subtitle or other heading. One reason for this is that we can't judge the accuracy of most edits.

HN titles also tend not to include the names of authors or speakers. We learned years ago that the site works better when emphasis is on content, not personalities.

(Submitted title was "SpaceX's GPU-Powered Combustion Simulation – Adam Lichtl and Stephen Jones")

</comment></comment><comment><USER8> I start at SpaceX on July 27th... I'm pretty stoked about that.

<comment><USER9> Congrats!

<comment><USER8> Thanks! Hopefully I'll have a nice post about what it's like to work there.

</comment></comment></comment><comment><USER10> Over my head but still fascinating to watch (because I like space). Anyone have good intros to this kind of simulation stuff?

<comment><USER11> I am not sure there is a good "intro" for a lot of this per se since many of these ideas tie to research topics in applied math. I will give a few books that seem to touch on areas related:

* You first need a basic (or not so basic) numerical analysis course.

* For wavelets: Mallet's "A Wavelet Tour of Signal Processing"

* For spectral methods in general, a primer many people prefer is Trefethen's "Spectral Methods in MATLAB". It is introductory and you really should start here, but for its reliance on MATLAB and a matrix point of view it's not entirely practical.

* For GPU computing, a slightly advanced book is "The CUDA Handbook: A Comprehensive Guide to GPU Programming"

* For general-purpose parallel CPU computation: "Using MPI" by Gropp

</comment></comment><comment><USER12> Just heard him say they based this on wavelet CFD work by Johnathan Regele (basically GPU-optimizing: it)

[http://www.aere.iastate.edu/jregele/](http://www.aere.iastate.edu/jregele/) [http://www.tandfonline.com/doi/abs/10.1080/10618560903117105](http://www.tandfonline.com/doi/abs/10.1080/10618560903117105)

[edit: see Acknowledgements at the end]

</comment><comment><USER13> I understood 99% of that. I have chosen the wrong career.

</comment><comment><USER14> So where was the engine? All we saw was simulation of flow from a triangular area that wasn't shaped anything like an engine nozzle.

So yeah... was expecting an engine. Saw a 2-dimensional triangle. Dissappoint.

</comment><comment><USER12> Would I be right in assuming there's no open source CFD apps capable of the kind of demos he was doing? Any proprietary apps?

<comment><USER15> Openfoam and su2.

</comment></comment><comment><USER16> Transcript?

</comment><comment><USER17> Laser Melting in space! Love it!

[https://www.additively.com/en/learn-about/laser- melting](https://www.additively.com/en/learn-about/laser-melting)</comment>


Remove any URL from Google via Webmaster Tools - <AUTHOR> http://www.davidnaylor.co.uk/google-webmasters-flaw-allows-you-to-remove-any-url-from-their-index.html

<comment><USER2> Doesn't the URL need to blocked in robots.txt too? It'd be interesting to see if it does cause the site to drop out (even temporarily). Hopefully Google can patch this.</comment>


Airline to charge overweight passengers more - <AUTHOR> http://www.smh.com.au/travel/travel-news/airline-to-charge-overweight-passengers-more-20130402-2h495.html

<comment><USER3> This is a great marketing move as it tries something that many people who are charged $/£/€/?50+ for an overweight kilogram will have muttered at checkin desks.

The truth is that it doesn't work because the bag restrictions are there for reasons unrelated to the weight of passengers.

Firstly there's the baggage handlers. Some airports charge the airlines extra for heavier bags so it's a way to discourage a charge to the airline. But far more than that, even in the olden days before most airlines charged for checked baggage, it's a great way to extract additional revenue from the customers in a context of it being the customers' fault.

<comment><USER4> > The truth is that it doesn't work because the bag restrictions are there for > reasons unrelated to the weight of passengers.

The truth is that a big proportion of the cost of a flight is fuel, and therefore weight.

<comment><USER5> Lets not forget the whole fuselage thingy.

</comment></comment></comment><comment><USER6> Such a pity that it's so close to April 1. Unfortunately I think it's just too sensible to be serious.

I wish the poll had been made with a question of body mass adjacent; I expect the average weight of nay-sayers would be greater than that of aye-sayers.

</comment><comment><USER7> "Samoa Air passengers must type in their weight and the weight of their baggage into the online booking section of the airline's website."

Uh, Ok, good luck with that :-)

<comment><USER8> _"Passengers are then weighed again on scales at the airport, to check that they weren't fibbing online."_

<comment><USER9> Why bother asking when reserving at all then? How do people even know how much their bag is going to weigh before they pack?

I don't even own a scale. I can estimate my own weight, but not the weight of a bag whose contents have yet to be determined.

</comment></comment></comment><comment><USER10> Please HN, I hear so many self righteous skinny people clammering over each other about what a great idea it is. Great, please invest in this airline then. That one that provides an unpleasant experience for obese people and is operating in one of the most obese countries in the world. I'm sure it will be super profitable and you can all use your dividends to not enjoy a sandwich together.

</comment><comment><USER11> This seems unnecessarily discriminatory. It also means that taller people get a worse deal - already having to deal with cramped seating, now there is a premium on the extra body weight due to height.

<comment><USER12> You're cargo on an airplane. I think it's fair for airlines to charge by weight. My reasoning blurs a bit though when it comes to height. I'm tall and skinny. I'd pay for extra leg room, but I don't cost the airline extra carbon burning and neighbouring passenger discomfort to get me somewhere.

Ideally, we could computer model our desired seating arrangement and pay accordingly. If you don't want to pay for your waist-line, you don't travel.

<comment><USER13> Pay for the "Economy Plus" seats. They're like $20 more on Delta, and you get 2-3" more legroom. Totally worth it.

But in general, airlines like tighter seat pitch as it lets them (perhaps) get another row into the cabin, and that's another 4-9 passengers per flight.

Seatguru has a sortable grid of seat layout. I won't be on airberlin anytime soon (29" seat pitch, no way!)

<http://www.seatguru.com/charts/longhaul_economy.php>

<comment><USER8> _"Pay for the "Economy Plus" seats. They're like $20 more on Delta, and you get 2-3" more legroom."_

I wanted to try that last December, traveling with Delta from AMS to TPA. Turns out, it was $120 more for each leg of the trip. So no, I chose not to, even though I'm 6'1". Instead, I got a seat at one of the emergency exits.

<comment><USER13> Ah, Amsterdam to Tampa -- that's why it was that much more. I'm surprised you could get an exit-row seat. They're usually snapped-up by their diamond-level frequent fliers.

<comment><USER8> Right, no doubt the prices you mentioned are valid, but for domestic flights. I mostly fly transatlantic with Delta, that's why the upgrade (and its associated costs) is not a no-brainer for me.

Also, I only snagged the exit row seat for the return flight. I don't qualify for Diamond level with Delta, as I fly with several different airlines (non- Skyteam). With Delta, I do qualify for 50% discount on upgrades, I listed the fees that basic members would pay.

</comment></comment></comment></comment></comment></comment><comment><USER14> For some reason Pulp Fiction popped into my head.

I'm a little ambivalent about this. On one hand, obese people have enough of a hard time just getting by without the extra burden of social commentary and (let's face it) the "look at that guy" sentiment. On the other hand the airlines are having to spend more in fuel when prices are already high.

<comment><USER8> _"obese people have enough of a hard time just getting by"_

Do they really? Especially in the US and UK, where obesity has really gotten out of hand, people don't even recognize it anymore. Only the super obese (BMI >45) get the "look at that guy" comments. In reality, obese is BMI >30\. For instance, if you're 5'10" and you weigh 210 lbs, you're obese.

<http://en.wikipedia.org/wiki/Classification_of_obesity>

<comment><USER15> BMI is a pretty silly measure - a professional rugby player could have a BMI over 30 and be pure muscle - probably the same for American football players.

<comment><USER16> This is mentioned everytime BMI is mentioned.

Most people with BMI over 30 are not olympic athletes or professional rugby players.

<comment><USER15> I didn't imply that they were - just meant that a simple rule that says "BMI over 30 -> obese" needs to allow for the fact that there are a small number of cases where this isn't true.

[NB A couple of hours ago I was watching professional rugby players train - <USER2> that's my excuse for mentioning this] :-)

</comment></comment></comment></comment></comment><comment><USER17> And if you're fat , do you get bigger seats ? lol ;) and when you make a reservation do you need to enter your weight ?

<comment><USER8> Believe it or not, Airbus is working on it. Regular people will get smaller seats than they do now, while fat people get wider seats.

 _"Airbus recently said in a press release it will offer extra-wide seats on its A320 planes, "providing adequate space for those who need it, while giving airline operators a new method to generate additional revenue." Instead of having three 18-inch seats in a row, the new arrangement will have one 20-inch and two 17-inch seats."_</comment></comment>


Ask HN: What and how would you pay for our service? - <AUTHOR>

Hello HN,
Over at Runbook.io we are looking at changing our pricing model and could use the communities advice.
We are an open source project built via https://assembly.com; which means that after costs of doing business, any profit made is paid to the community that contributes code/design/everything.
Financials: https://assembly.com/runbook/financials
While we have a few paying users the $1 per monitor price tag doesn't seem to be enough to cover our costs long term, let alone enable royalties to be paid out to the contributing community.
So the question for the HN community is this, if we raised our price per monitor how much should we increase it too? The highest we have discussed is $9.99 per monitor per month. Would you pay that for our service? If not what would you pay?
We are also considering moving from a per monitor pricing structure to a tier based structure. Where you get x amount of monitors for y price.
So the second question regarding how to pay is this, should we keep it per monitor or move to a standard tiered based model?
Related links: https://runbook.io https://runbook.io/pages/pricing/ <comment><USER2> My off-the-cuff assessment is that tiered pricing will probably give you the most bang. This usually works better if you do it based on actual data of what your users do, rather than random comments from HN, but my guess is that you'll probably be able to segment into Hobbyists vs Small Businesses vs Big Fish without too much problem.

Following up with a number out thin air, I would say that $9.99 is sounds like a good ballpark for the lowest tier. Businesses should be willing to pay a large multiple of that (Think 10x and up) for any solution that solves a real problem for them, as long as you make the segmentation clear and market accordingly.

OTOH, If you are really married to "unit" pricing you can kind of keep it by giving each tier a fixed number of monitors/reactions plus the option of purchasing extra monitors/reactions at a fixed unit price (different per plan), but you should really look at actual usage data to figure out whether it's worth it. In my experience, simple tiered pricing works better.

Also. Completely unrelated to pricing but it made me cringe when I saw it: If I hit the call to action on the landing page I get to a form with a lot of empty space around it and no indication of what follows. You should take advantage of that empty space to make clear what will happen to me if I fill out the form and hit the button. For bonus points you can point out some more benefits, or a testimonial that takes down a common objection to signing up, or whatever, but a simple bit of text saying "The next step will be like this" should make a measurable difference in conversions.

My email is in my profile if you want me to spout some more random unsolicited advice at you.

</comment><comment><USER3> Here are a few things which come to mind when looking at your pricing:

* Your pro package is too cheap. If you're in the DevOps market space, I'm willing to bet that 99.99% of your potential customers would be as willing to spend $10 per month as $1 per month. If you can demonstrate a savings of one man-hour of labor per month, you could probably charge $100/month without too much difficulty. * Your pro package is too expensive. As a recent guest to your site, the free and the pro plans look very similar in terms of benefits. Why should I go to the trouble of whipping out a credit card when I can be lazy and just use the free plan that looks almost as good? My guess is that you have a bunch of freeloaders who will never convert to paid either because they are cheap or they don't need any additional service. * It's not clear what the benefit of your system is to your users. On the front page of your site, you should have a clear explanation of how a customer's life would be better if they gave money to you. You're assuming that your entire audience not only knows what IFTTT is, but you're also creating a dependency on IFTTT to explain the benefits of your own product.

As a first shot, I'd try to think of the types of users who would benefit from using your product.

You could tier by many different characteristics - response time, monitors, types of reactions, monitoring intervals - even access to https. If you can break down your potential customer groups by willingness and ability to pay, you'll have a better idea as to which characteristic(s) should change from tier to tier.

I have a free chapter up on customer value that you might help - [http://taprun.com/pricing](http://taprun.com/pricing)

<comment><AUTHOR> Thats good advice though one part confused me. Are you saying our pro package is too cheap or too expensive?

Right now the main difference between our pro and free accounts is the number of monitors available. With free you can only have 2 whereas with pro there is no limit except that each monitor costs.

</comment></comment><comment><USER4> Firstly, I disagree with the _Assembly model_ , but that is another discussion for another day.

Salesman rule for product pricing (something I need to adopt myself): price your product at a cost that is similar or cheaper to your competitors.

Go cheaper if you have less features, but keep adding more and you can possibly steal away customers from your more expensive competitors.

If you have no competitors, your client-base and their usage should've given you an indication of where to start pricing.

Companies pay ridiculous amounts for things as trivial as chatrooms, so if you're automating away DevOps/System-Administration, you can charge a decent chunk of change that will come cheaper than say $4,000 per month for a senior system administrator.

I've also heard of a theory where if a product is _too cheap_ , some companies feel that it is a weaker/inferior product.

For any startup/side-project type person, create a special tier where you reel them in and hook them onto your services. Paying $25 per month to monitor servers 24/7 and avoid downtime[1] is an asset for 2/3-man teams.

I also agree with taprun about the free tier. Would you run RunBook on that free shared-webhosting site?

There's tons of people who would like things that aren't free to be given for free. This is called "free-riding" in economics and you are basically swallowing their costs. IMO, giving the source-code away for free is good enough.

Create a trial period and have a pay-only service.

You'll end up on-boarding shitty customers (which are probably at +10 to 1 of your paying ones).

[1]: Like everyone else, I don't actually know what your service provides (clearly). To me it seems like an automatic server-monitoring service that detects and tries to fix errors.

<comment><AUTHOR> Thanks for the thoughts, I'll have to think pretty heavily on the pay-only service. There are many companies out there that have done well with a try before you buy model.

You make a valid point with the fact that we have already open sourced our product so a free tier is giving away even more.

> Companies pay ridiculous amounts for things as trivial as chatrooms, so if > you're automating away DevOps/System-Administration, you can charge a decent > chunk of change that will come cheaper than say $4,000 per month for a > senior system administrator.

So very true. I guess when you put it that way $1 per monitor is a pretty low price and I think you're right we may just be going too cheap and labeling ourselves wrong.

> To me it seems like an automatic server-monitoring service that detects and > tries to fix errors.

Yup, that is exactly what it is.

</comment></comment><comment><USER5> Somewhere in the range of $99-199 per month per server/host, with unlimited monitors on each server. This kind of tool is in a similar place market/value- wise as NewRelic, IMO, which has that kind of pricing.

<comment><AUTHOR> Thanks, that helps a ton with a future direction where our monitors are server based. What we have right now is all external monitors. Think along the lines of Pingdom but a lot more types of monitors.

</comment></comment><comment><USER6> This reminds me of the discussions between Tarsnap and Patio11 - basically, charge more and create tiered pricing. Even if the only difference between one of the tiers is having your phone number.

I will need 4 monitors when my project is complete and I would happily pay $49 per month for that peace of mind.

<comment><AUTHOR> Ok so you would be fine with 9.99 a monitor but more likely to buy if it was in a tiered package. Thanks!

<comment><USER6> Honestly, if it was 9.99 a monitor, i'd try and make do with one / fine a way around paying for more. Just the hacker in me I guess ;)

</comment></comment></comment><comment><USER7> Okay, wow. Where can I see some screenshots/demo? I'd like to pay for this right now.

<comment><AUTHOR> Right now we don't have any demo, but you can sign up and if you like it you can choose to upgrade. Upgrade gives you more monitors and more intervals but everything else is the same between free and non-free accounts.

<comment><USER8> I'd like to see it as well (screenshots would be fine, a demo better, of course) but I'm not going to bother taking the time and trouble to sign up just to be able to see if I might like it.

I realize I'm only a single person but I would think many others are the same way so it would seem that you're unnecessarily putting up roadblocks to acquiring customers.

<comment><AUTHOR> Thats fair, I'll make sure we add at least screenshots in the future.</comment></comment></comment></comment>