22 ms·

Most people involved in tech, including most devs, shouldn't need to know/care about Kubernetes. The reason anyone thinks otherwise is the massive amounts of ma

Most people involved in tech, including most devs, shouldn't need to know/care about Kubernetes. The reason anyone thinks otherwise is the massive amounts of marketing money vested parties have pumped into sales (read: DevRel/Dev Evangelism, dev influencers).

tluyben2 5y ago
Absolutely. It is a timesink and really not very valuable for most devs: they will not ever use it themselves anyway and there is too much to learn while the normal dev stuff already has that as well. In bigger (only marginally bigger than a one person shop) companies you have admins/devops and they don't want you to touch any of it anyway.
danjac 5y ago
They shouldn't have to, true. But enough companies have bought the Coolaid that it's a job requirement and you'll have to learn it anyway, which means developers will try and shoehorn it into their projects whether it makes sense or not so they can have it on their resume and then companies will need to make it a job requirement when those developers leave and they need to maintain it...
- Bertram_Oglebs 5y ago
  '...um before all these tools being able to reach similar conclusions ?' (-; (OT) ^^ somehow related comic: https://ibb.co/JktgqSV https://ibb.co/JktgqSV best,
- throwaway894345 5y ago
  What’s the alternative? Devs master a VM/Ops skill set (strictly more work)? Or devs throw code over the wall to an ops team (and progress grinds to a trickle)? https://news.ycombinator.com/item?id=28652561 https://news.ycombinator.com/item?id=28652561
  - scrose 5y ago
    Prefacing this with the fact that I’ve only worked at smaller startups(<500 people) Arguably, most of these places do not need dedicated ops teams, nor do they need to host and manage their own infrastructure, yet they do. The most productive startup I worked at used Heroku to bootstrap many of their applications and we didn’t need a single ops person. People were able to switch between teams and follow the same short and standardized process to build and deploy code. They didn’t need to ‘master’ any specialized ops skills and there was typically someone on each team who could quickly debug failing deploys. The least efficient startup I worked at insisted on hosting all their own infra because managed solutions like Heroku were ‘too expensive’. Except we ended up with multi-month long infrastructure rollouts, process additions, changes and infra upgrades that likely cost many orders of magnitude more than managed solutions to implement, with less features than we’d get out of the box with a managed service like Heroku. We also had nowhere near the scale necessary, or headcount, for it to be worth it to self-manage. I’m typically the guy who works on the backend but also gets called in for ops and infrastructure work, and at least for smaller companies that aren’t dealing with hundreds of millions of requests per day, I think the managed route makes way more sense, even if you feel like you’re overspending on infrastructure.
    - throwaway894345 5y ago
      I was comparing Kubernetes to self-managed VMs, not Heroku. Heroku absolutely makes a lot of sense in many cases (small teams, simple use cases, etc).
  - catlifeonmars 5y ago
    Managed platforms. Take Shopify for instance. It’s a platform that allows individuals with very little programming knowledge to build, ship, and operate online retail services, but doesn’t suffer from the segmentation of product lifecycle into dev and ops. The platform user still owns the end to end product lifecycle.
    - throwaway894345 5y ago
      Yeah, I buy that.
strzibny 5y ago
I completely agree with you. And if you want backend engineers to know more about ops, sure. But let them learn the groundwork, not forced them into K8s. As for data scientists needing K8s knowledge, that's ridiculous to me.
- tomrod 5y ago
  Data scientist here with very recent learning on K8s space. Exposure and general conceptual understanding is extremely helpful to have to assist in design of solutions. However, agreed that expecting me to maintain or lead the ownership of a K8s standup is outside the wheelhouse.
alexchamberlain 5y ago
Not sure I agree to be honest. I don't think most developers should know how to run K8s, but I think most developers should know how to run their code on K8s. These guys aren't idiots - putting abstractions and guide rails in the way is just patronising. That's not to say everyone has to be an expert either - there's a place for experts to optimise setups etc too.
- void_mint 5y ago
  > Not sure I agree to be honest. I don't think most developers should know how to run K8s, but I think most developers should know how to run their code on K8s. This is silly. Most devs have too many other things they know they don't know, to also add on something like kubernetes.
  - marvelous 5y ago
    IMO, it's not silly at all. Most devs have to know the commands and configuration to do rolling deployments on the target infrastructure, fetch logs, how the readiness protocoll integrates with automatic restarts, ingress, etc. With k8s, all this is standard and transferable. With ad-hoc simpler solutions, this is all per-team tribal knowledge, and in my experience it's not even simpler to use for us devs.
    - void_mint 5y ago
      > Most devs have to know the commands and configuration to do rolling deployments on the target infrastructure, fetch logs, how the readiness protocoll integrates with automatic restarts, ingress, etc. Is this serious? You think _most devs_, meaning a group that includes FE devs, mobile app devs, IoT, open source, DBAs, security engineers, need to know these things? > With k8s, all this is standard and transferable. With ad-hoc simpler solutions, this is all per-team tribal knowledge, and in my experience it's not even simpler to use for us devs. Most teams do not have to manage most/all of the things you're describing. This really feels like more K8s marketing disguised as a HN post.
throwaway894345 5y ago
The objective is to minimize how much devs need to know. There are a couple of ways to do that. The first is to pull out the traditional ops skill set into a traditional ops team so the app devs throw code over the fence to the ops team to operate, and hilarity ensues because the ops team is measured on uptime but they can’t affect the first order causes of downtime (code issues), so instead they try to make it harder to ship changes frequently which slows the business. The other solution is that devs operate the apps themselves. This is infeasible with a traditional VM setup because managing VMs effectively involves tons of specialist knowledge and it’s unreasonable to expect dev teams to master it while also being expert developers. Enter Kubernetes. Now you have a core DevOps/SRE team managing the “platform” (the Kubernetes cluster and various add-ons such as operators) which gives the application developers a high-level interface for operating their applications. They need to know a bit of Kubernetes, but it’s a whole lot less than mastering the traditional VM-based ops skill set. Moreover, as the Kubernetes ecosystem continues to mature, the surface area with which developers interact becomes smaller.
- vp8989 5y ago
  "Enter Kubernetes. Now you have a core DevOps/SRE team managing the “platform” (the Kubernetes cluster and various add-ons such as operators) which gives the application developers a high-level interface for operating their applications." I've personally changed my opinion on this in the last ~2 years ... observing at work what it takes for people to stand up and manage a Kubernetes platform it really just feels like incredible waste that we have hundreds and thousands of SREs across our industry all building their own unique compute platforms when the public cloud vendors have already done that work. The Serverless paradigm just seems fundamentally superior to me, but it also seems like it inherently requires vendors to be very opinionated in order to provide a good developer experience with it which AWS is not and aren't ... at least not yet anyway.
  - throwaway894345 5y ago
    > I've personally changed my opinion on this in the last ~2 years ... observing at work what it takes for people to stand up and manage a Kubernetes platform it really just feels like incredible waste that we have hundreds and thousands of SREs across our industry all building their own unique compute platforms when the public cloud vendors have already done that work. I wasn’t suggesting standing up K8s from scratch, but rather extending GKE or EKS or similar with things like cert-manager snd external DNS. I was skeptical coming from a shop that was deeply invested in AWS and serverless, but Kubernetes has a lot less friction and the abstractions can be pretty high level. For example, we can create a service with HTTPS, fully managed certificates, reverse proxy, and DNS just by creating an ingress resource for that service. It’s a lot nicer than cobbling together ACM, Route 53, API Gateway, etc (even though I have plenty of experience with the latter). A lot of this is possible because Kubernetes is extensible and there’s a big ecosystem for it. AWS isn’t (particularly) extensible, so you end up depending on them to support your use case. When you have a competent SRE team managing your platform and providing high level abstractions, Kubernetes kind of feels like what serverless promised to be—much more so than AWS’s serverless offerings (and I still like AWS!).
commandlinefan 5y ago
> shouldn't need to know Hm - maybe shouldn’t need to, but why wouldn’t you want to? Even if its not strictly your job/responsibility, its always helpful to know how things work when things go wrong.
- void_mint 5y ago
  Because if you followed this logic there would be many lifetimes of things to pay attention to, most of which are just noise surrounding topics you find valuable.
amerkhalid 5y ago
100% agreed. Kubernetes/DevOps is huge cognitive load, way over-engineered for an average project. Kubernetes should not come into picture unless you can afford a full-time DevOps person for your team. If you can’t then you are not big enough or haven’t solved a real problem yet.

tluyben2 5y ago

Absolutely. It is a timesink and really not very valuable for most devs: they will not ever use it themselves anyway and there is too much to learn while the normal dev stuff already has that as well. In bigger (only marginally bigger than a one person shop) companies you have admins/devops and they don't want you to touch any of it anyway.

danjac 5y ago

They shouldn't have to, true. But enough companies have bought the Coolaid that it's a job requirement and you'll have to learn it anyway, which means developers will try and shoehorn it into their projects whether it makes sense or not so they can have it on their resume and then companies will need to make it a job requirement when those developers leave and they need to maintain it...

Bertram_Oglebs 5y ago
'...um before all these tools being able to reach similar conclusions ?' (-; (OT) ^^ somehow related comic: https://ibb.co/JktgqSV https://ibb.co/JktgqSV best,
throwaway894345 5y ago
What’s the alternative? Devs master a VM/Ops skill set (strictly more work)? Or devs throw code over the wall to an ops team (and progress grinds to a trickle)? https://news.ycombinator.com/item?id=28652561 https://news.ycombinator.com/item?id=28652561
- scrose 5y ago
  Prefacing this with the fact that I’ve only worked at smaller startups(<500 people) Arguably, most of these places do not need dedicated ops teams, nor do they need to host and manage their own infrastructure, yet they do. The most productive startup I worked at used Heroku to bootstrap many of their applications and we didn’t need a single ops person. People were able to switch between teams and follow the same short and standardized process to build and deploy code. They didn’t need to ‘master’ any specialized ops skills and there was typically someone on each team who could quickly debug failing deploys. The least efficient startup I worked at insisted on hosting all their own infra because managed solutions like Heroku were ‘too expensive’. Except we ended up with multi-month long infrastructure rollouts, process additions, changes and infra upgrades that likely cost many orders of magnitude more than managed solutions to implement, with less features than we’d get out of the box with a managed service like Heroku. We also had nowhere near the scale necessary, or headcount, for it to be worth it to self-manage. I’m typically the guy who works on the backend but also gets called in for ops and infrastructure work, and at least for smaller companies that aren’t dealing with hundreds of millions of requests per day, I think the managed route makes way more sense, even if you feel like you’re overspending on infrastructure.
  - throwaway894345 5y ago
    I was comparing Kubernetes to self-managed VMs, not Heroku. Heroku absolutely makes a lot of sense in many cases (small teams, simple use cases, etc).
- catlifeonmars 5y ago
  Managed platforms. Take Shopify for instance. It’s a platform that allows individuals with very little programming knowledge to build, ship, and operate online retail services, but doesn’t suffer from the segmentation of product lifecycle into dev and ops. The platform user still owns the end to end product lifecycle.
  - throwaway894345 5y ago
    Yeah, I buy that.

strzibny 5y ago

I completely agree with you. And if you want backend engineers to know more about ops, sure. But let them learn the groundwork, not forced them into K8s. As for data scientists needing K8s knowledge, that's ridiculous to me.

tomrod 5y ago
Data scientist here with very recent learning on K8s space. Exposure and general conceptual understanding is extremely helpful to have to assist in design of solutions. However, agreed that expecting me to maintain or lead the ownership of a K8s standup is outside the wheelhouse.

alexchamberlain 5y ago

Not sure I agree to be honest. I don't think most developers should know how to run K8s, but I think most developers should know how to run their code on K8s. These guys aren't idiots - putting abstractions and guide rails in the way is just patronising. That's not to say everyone has to be an expert either - there's a place for experts to optimise setups etc too.

void_mint 5y ago
> Not sure I agree to be honest. I don't think most developers should know how to run K8s, but I think most developers should know how to run their code on K8s. This is silly. Most devs have too many other things they know they don't know, to also add on something like kubernetes.
- marvelous 5y ago
  IMO, it's not silly at all. Most devs have to know the commands and configuration to do rolling deployments on the target infrastructure, fetch logs, how the readiness protocoll integrates with automatic restarts, ingress, etc. With k8s, all this is standard and transferable. With ad-hoc simpler solutions, this is all per-team tribal knowledge, and in my experience it's not even simpler to use for us devs.
  - void_mint 5y ago
    > Most devs have to know the commands and configuration to do rolling deployments on the target infrastructure, fetch logs, how the readiness protocoll integrates with automatic restarts, ingress, etc. Is this serious? You think _most devs_, meaning a group that includes FE devs, mobile app devs, IoT, open source, DBAs, security engineers, need to know these things? > With k8s, all this is standard and transferable. With ad-hoc simpler solutions, this is all per-team tribal knowledge, and in my experience it's not even simpler to use for us devs. Most teams do not have to manage most/all of the things you're describing. This really feels like more K8s marketing disguised as a HN post.

throwaway894345 5y ago

The objective is to minimize how much devs need to know. There are a couple of ways to do that. The first is to pull out the traditional ops skill set into a traditional ops team so the app devs throw code over the fence to the ops team to operate, and hilarity ensues because the ops team is measured on uptime but they can’t affect the first order causes of downtime (code issues), so instead they try to make it harder to ship changes frequently which slows the business. The other solution is that devs operate the apps themselves. This is infeasible with a traditional VM setup because managing VMs effectively involves tons of specialist knowledge and it’s unreasonable to expect dev teams to master it while also being expert developers. Enter Kubernetes. Now you have a core DevOps/SRE team managing the “platform” (the Kubernetes cluster and various add-ons such as operators) which gives the application developers a high-level interface for operating their applications. They need to know a bit of Kubernetes, but it’s a whole lot less than mastering the traditional VM-based ops skill set. Moreover, as the Kubernetes ecosystem continues to mature, the surface area with which developers interact becomes smaller.

vp8989 5y ago
"Enter Kubernetes. Now you have a core DevOps/SRE team managing the “platform” (the Kubernetes cluster and various add-ons such as operators) which gives the application developers a high-level interface for operating their applications." I've personally changed my opinion on this in the last ~2 years ... observing at work what it takes for people to stand up and manage a Kubernetes platform it really just feels like incredible waste that we have hundreds and thousands of SREs across our industry all building their own unique compute platforms when the public cloud vendors have already done that work. The Serverless paradigm just seems fundamentally superior to me, but it also seems like it inherently requires vendors to be very opinionated in order to provide a good developer experience with it which AWS is not and aren't ... at least not yet anyway.
- throwaway894345 5y ago
  > I've personally changed my opinion on this in the last ~2 years ... observing at work what it takes for people to stand up and manage a Kubernetes platform it really just feels like incredible waste that we have hundreds and thousands of SREs across our industry all building their own unique compute platforms when the public cloud vendors have already done that work. I wasn’t suggesting standing up K8s from scratch, but rather extending GKE or EKS or similar with things like cert-manager snd external DNS. I was skeptical coming from a shop that was deeply invested in AWS and serverless, but Kubernetes has a lot less friction and the abstractions can be pretty high level. For example, we can create a service with HTTPS, fully managed certificates, reverse proxy, and DNS just by creating an ingress resource for that service. It’s a lot nicer than cobbling together ACM, Route 53, API Gateway, etc (even though I have plenty of experience with the latter). A lot of this is possible because Kubernetes is extensible and there’s a big ecosystem for it. AWS isn’t (particularly) extensible, so you end up depending on them to support your use case. When you have a competent SRE team managing your platform and providing high level abstractions, Kubernetes kind of feels like what serverless promised to be—much more so than AWS’s serverless offerings (and I still like AWS!).

commandlinefan 5y ago

> shouldn't need to know Hm - maybe shouldn’t need to, but why wouldn’t you want to? Even if its not strictly your job/responsibility, its always helpful to know how things work when things go wrong.

void_mint 5y ago
Because if you followed this logic there would be many lifetimes of things to pay attention to, most of which are just noise surrounding topics you find valuable.

amerkhalid 5y ago

100% agreed. Kubernetes/DevOps is huge cognitive load, way over-engineered for an average project. Kubernetes should not come into picture unless you can afford a full-time DevOps person for your team. If you can’t then you are not big enough or haven’t solved a real problem yet.