Hacker News Reader

Comment by hsn915 | Hacker News Reader

> The biggest learning curve is for the person setting up the initial deployments, services, ingress etc Most other team members may just need to maybe change the image name and kubectl apply to roll things out.

This is a huge redflag.

It's basically admitting that you expect most later employees to not understand k8s or how its being used. You may think they don't need because it works, but you have to think about what happens when it doesn't work.

The shops I've been to all had the same mindset: the docker/k8s infra was setup by one guy (or two) and no one else on the team understands what's going on, let alone have the ability to debug the configuration or fix problems with it.

Another thing that might happen is some team members understand just barely enough to be able to "add" things to the config files. Over time the config files accumulate so much cruft, no one knows what configuration is used for what anymore.

View on HN

You have this with literally every deployment mechanism, except with Kubernetes the boundary is standardized and you can easily find/hire/teach new team members to work on the complicated parts.

Custom VM/cloud/$randomSaaS deployments are much worse when it comes to "the one guy who understands the intricate details is on vacation".

At some point, this becomes the dividing line between a "nu-ops" team and the dev team.

Of course, if your deployment mechanism needs to be complicated, standarizing on something everyone knows is useful.

The underlying assumption behind my comment is that you really really want to simplify your deployment as much as you can.

Unfortunately this is nearly impossible with the currently accept set of standard best practices for developing web applications, where you use a scripting language and like six different database systems (one for source of truth on data, one for caching, one for full text search, and who knows what else everyone is using these days; I honestly can't keep track).

There are many ways to make the deployment process simple. My rule of thumb is to use a compiled language (Go) and an embedded database engine.

The levels.io guy famously did it even with php https://twitter.com/levelsio/status/1102487697220820994

>It's basically admitting that you expect most later employees to not understand k8s or how its being used.

That's also exactly what would happen if you homebrewed your own system. You need to centralize some part of expertize around infra at some point, but hopefully around more than two people.

It's healthy to depend on your coworkers for their specific knowledge. The landscape is too large for everyone to know everything, and honestly if I heard someone say this in an interview I would chalk it down to social deficits because this is not how life, businesses, etc. work

I think the key with this though is that it's good when everyone on a team has a working knowledge of something, and one person has expert knowledge. If one person knows everything there is to know, and everyone else knows nothing, you've created a massive dependency on the single person (which in the case of infrastructure code, could easily be a near existential problem for the company).

It’s unrealistic to expect the entire team to know how to build and safely operate IPv6 BGP anycast with an HTTP/2 tls load balancer, authentication and authorization, integrated with a modern observability platform and a zero downtime deployment CI process.

It is realistic to expect a small team to build the same in an industry standard way and hand of a clear, well documented API to the rest of the team.

Bespoke solutions need to deal with this complexity somehow, k8s provides a standard way to do so.

I'd consider knowing how to use the API to configure services and deploy new services to be a good definition of "working knowledge". You're right that everyone doesn't need to know the ins and outs of everything for sure, but if you observe at your company that everyone is relying on "the Kubernetes guy" to do everything related to Kubernetes, you've just re-invented an old-school ops team in an especially brittle way.

Just like how you don't really expect later devs to learn the intricacies of your hand rolled deployment setup.

The difference is, kubernetes is pretty standardized and therefore learnable in a repeatable way, unlike the Frankenstein of tooling you might otherwise cobble together.

> kubernetes is pretty standardized

Sure. Though the standard changes weekly.

My favorite Kubernetes joke can be told in one word:

v1alpha1

I used to make this joke a lot but all of the stuff I use has made it to v1 :)

And the good thing is the graduation process means that this can actually be relied upon not to break compatibility.

That would only be true if you actually need 90% of what k8s provides and will end up reproducing it poorly.

Then write documentation or train your team.

YAML supports comments.

Reply on news.ycombinator.com