6 ms·

> 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 t

by hsn915 4y ago

> 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.

lima 4y ago
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".
- jrimbault 4y ago
  At some point, this becomes the dividing line between a "nu-ops" team and the dev team.
- hsn915 4y ago
  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 https://twitter.com/levelsio/status/1102487697220820994
KptMarchewa 4y ago
>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.
pfraze 4y ago
Then write documentation or train your team.
nemetroid 4y ago
YAML supports comments.
engineeringwoke 4y ago
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
- ryanbrunner 4y ago
  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).
  - 0xEFF 4y ago
    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.
    - ryanbrunner 4y ago
      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.
huffmsa 4y ago
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.
- musingsole 4y ago
  > kubernetes is pretty standardized Sure. Though the standard changes weekly.
  - rfoo 4y ago
    My favorite Kubernetes joke can be told in one word: v1alpha1
    - lima 4y ago
      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.
- hsn915 4y ago
  That would only be true if you actually need 90% of what k8s provides and will end up reproducing it poorly.

by hsn915 4y ago

lima 4y ago

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".

jrimbault 4y ago
At some point, this becomes the dividing line between a "nu-ops" team and the dev team.
hsn915 4y ago
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 https://twitter.com/levelsio/status/1102487697220820994

KptMarchewa 4y ago

>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.

pfraze 4y ago

Then write documentation or train your team.

nemetroid 4y ago

YAML supports comments.

engineeringwoke 4y ago

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

ryanbrunner 4y ago
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).
- 0xEFF 4y ago
  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.
  - ryanbrunner 4y ago
    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.

huffmsa 4y ago

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.

musingsole 4y ago
> kubernetes is pretty standardized Sure. Though the standard changes weekly.
- rfoo 4y ago
  My favorite Kubernetes joke can be told in one word: v1alpha1
  - lima 4y ago
    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.
hsn915 4y ago
That would only be true if you actually need 90% of what k8s provides and will end up reproducing it poorly.