Hacker News Reader

Comment by root_axis | Hacker News Reader

This is another case of "I have never encountered and don't deeply understand the problems this tool was built to solve, thus the tool is totally unnecessary and the people who use it are part of a cult".

This is the same kind of flawed reasoning you see in the front-end world where a bunch of people complain that they do all their work in jQuery so React must be a cult.

Pasting what I wrote in another comment:

The goal isn't "ease of deployment", the goal is "infrastructure as code" so that application infrastructure can be managed in a way similar to application source code (e.g. PRs, blame, code reviews, CI, rollbacks etc). This helps ops people because it allows them to think about infrastructure as abstract resources rather than as a collection of individual machines with specific designations. With k8s, individual machines become a homogenized resource that do not need specialized provisioning depending on the application they will host.

View on HN

...and the crux of the problem is where people who have never encountered the problem Kubernetes solves, still start using Kubernetes.

Often it is that they think they have never encountered the problem Kubernetes solves or have "gotten lucky" and never encountered it.

Well how else do you build webscale software? What if later you want to deploy microservices. Premature optimization seems like a good idea with infrastructure because you have room to grow.

I think the crux of the problem is that everyone encounters the problem Kubernetes solves. As the GP states, Kubernetes gives you

"infrastructure as code" so that application infrastructure can be managed in a way similar to application source code (e.g. PRs, blame, code reviews, CI, rollbacks etc). This helps ops people because it allows them to think about infrastructure as abstract resources rather than as a collection of individual machines with specific designations

Who doesn't want that? Of course you want that.

But will the investment of time and effort pay off for your organization, and if so, how quickly? That's the hard question to answer. It depends on scale, personnel, the types of workloads involved, how easily your tools and practices can be updated, and presumably many other considerations. From my personal experience it seems like in practice the answer to this question is so murky that the deciding factors turn out to be social, including the personal risk aversiveness of the people making the decision, people's loyalty to the company versus their own resume, and whether leadership cultivates a hyperoptimistic growth mentality of making 10x or even 100x decisions (i.e., make decisions assuming the company will be 10x or 100x bigger in a year.)

The problem, then, is helping people compare the cost/benefit of Kubernetes compared to their current practices, for their own organization.

There are lots of tools that give you "infrastructure as code". Why is Kubernetes special?

What is the point of this question? Why are the other tools special?

My point is that if "infrastructure as code" is your sole requirement, Kubernetes doesn't seem like the first choice. Adopting Kubernetes is not a small task, but it seems to be the go-to answer for a lot of the HN crowd.

Don't get me wrong: it's a great tool for some things. But IMO, for 80% of projects it's completely overkill.

K8s is the only IaC platform with heavy buy in by all the major public clouds.

I'm not particularly interested in limiting myself to using only the tools that large companies have deemed worthy.

There are plenty of tools out there that can get the job done at the scale that the vast majority of businesses operate in with lower operational and cognitive overhead than Kubernetes.

+1. Infrastructure as code is exactly that, code. For AWS it is Cloudformation template code, Cloudformation service and some CI/CD on top, like jenkins or ansible. Or Terraform for unlucky ones. K8s is container orchestration, like AWS ECS, totally different beast.

CloudFormation is for the lucky ones and Terraform the unlucky ones? I'm thinking you've never used one of the two...

On AWS, Cloudformation is far more reliable and lean (less LOC) than TF. No corrupted state issues, all resource properties are supported, parallel (fast) resource creation just for starters. And TF sales pitch about "multi-cloud" is nonsence, resources are too different between different clouds.

It's also directly supported by multiple first-tier cloud providers.

I mean, so is Terraform (kinda).

Terraform supports first-tier cloud providers, but the other way around?

Perfect way to put it.

I'd argue the opposite. Only a relative handful of companies, startups etc. encounter the problems IAC solves. Most do fine without it.

Or maybe they use Puppet or Chef. Most won't even need that.

That’s how you get every other startup thinking Heroku is the solution and then two years later they realize they might need to invest in building out their own self-documenting, automated architecture. More than happy to upvote you as it means more work opportunities for me down the line.

> Who doesn't want that? Of course you want that.

If you only have a couple of servers you probably want to think of them as individual machines rather than abstract resources. A lot of equations simplify when you set x to 1.

Lots of people have some the problems k8s solve.

Infrastructure as Code - If you're not doing infrastructure as code, how do you know who is taking what actions on your infrastructure? How do you know your tests are running on an environment that represents production? How do you know the tester or dev hasn't fixed and not commited?

CI/CD - Do you have a quicker way to create test environments than just running kubectl create ns?

Resource Utilisation - Sharing servers to save money. Obviously you can use VMs, but do you want to do nested VMs on cloud?

I'm not sure most people should run k8s, but in a world where you can use GKE, I can't really see why not. What offers a better solution?

I'm in the situation that Kubernetes does solve the problem I have... deploying application stacks across varied configurations for purposes of testing at a PR level. Working on software that is customized and delivered to multiple downstream clients is hard to test against. Yes, there are other options, but K8s is a very good fit, and the best option we have.

YMMV... I've also been in a scenario where I just did separate pushes to dokku boxes behind a load balancer. There's plenty of room for in between.

Right now, I feel kind of like I'm treading water though.

> This helps ops people because it allows them to think about infrastructure as abstract resources rather than as a collection of individual machines with specific designations. With k8s, individual machines become a homogenized resource that do not need specialized provisioning depending on the application they will host.

This is a very true statement. I'm looking at it with a bit of a different view as well: We're currently setup very classically. Ops maintains terraform, VMs, config management. Some developers have taken over some highlevel cluster management via the configuration management. This works very well.

As long as you're pushing 3 applications around. Onboarding an application into a config management solution can easily take 2 - 4 engineering weeks on the ops side. And the work will always be on the ops-side because that's where the required expertise of the configuration management lies, which is a hefty chunk of specialized knowledge. If you're looking at a ramp-up from 3 applications to 5, 8, 20, like in our case, that's ... ugly. In our case, that's actually planned, because we've been bought due to our experience in this context. Yey.

That's a huge investment if you look at time alone, it's like 80 engineering weeks at worst. That's a year of nothing else all of a sudden. A situation like that magnifies the operations team as a bottleneck even worse.

And that's IMO where the orchestration solutions and containers come in. Ops should provide build chains, the orchestration system and the internal consulting to (responsibly) hand off 80% of that work to developers who know their applications.

Orchestration systems like K8, Nomad or Mesos make this much, much easier than classical configuration management solutions. They come with a host of other issues, especially if you have to self-host like we do, no question. Persistence is a bitch, and security the devil. Sure.

But I have an entire engineering year already available to setup the right 20% for my 20 applications, and that will easily scale to another 40 - 100 applications as well with some management and care.

That's why we as the ops-team are actually pushing container orchestrations and possibly self-hosted FaaS at my current place.

Hm, guess that got a bit longer. You hit a nerve somewhat.

So you think application delivery was less "as code" before Kubernetes?

From my standpoint, Kubernetes is a lot more manipulating state and a lot less code than what pretty much anything it replaces. In fact, almost nothing is "as code" until you introduce third party products such as Helm into the mix.

But that matters little, since the point of using it is not technology but standardization. It has the potential to commodify cloud infrastructure. A bit tongue in cheek perhaps and a far from accurate technical statement, but Kubernetes looks more and more like what Openstack should have been.

To be fair to the author a lot of folks I know are jumping on K8s and their use case mostly looks like that of the blog author. In those specific case you indeed are joining a cult.

K8s is meant to reduce devops work and complexity. Most businesses do not reach that level of complexity and will never need K8s.

If it's a cult, then it's the cult of developer fashion where participants complain about free tools they don't understand and don't have to use.

Tbf many developers have to use whatever someone up the chain considers fancy.

If technical leadership is making poor engineering decisions then that is where they should place the blame.

"My office is a cult" instead of "this tool I get paid to abuse is a cult"

It's a cult as much using source control system, build system, and editor (IDE) is.

e.g. you can always code, and zip-up files, and build directly using command-line (we still can do it, right?), but when you need to deliver that automation bit, and most importantly hand-off to the next person what you've done - e.g. codified for real, then it becomes a must to have a system like this.

"infrastructure as code" can be, and has been, solved with a combination of .git and bash scripts.

Kubernetes solves problems some groups will run into with shell scripts[†]. But not the problem of using git or GitHub, which is nonexistent.

[†] let us take as given that these problems are numerous and painful!

> the goal is "infrastructure as code"

You can have infrastructure as code without running a second containment layer on top of the containment layer your cloud provider runs (which describes many k8s deployments).

Infrastructure as code is a much older practice, not something that Kubernetes enables. Kubernetes can be criticised for being too complex for most things that benefit from IaC.

Reply on news.ycombinator.com