3 ms·

You need to remove a lot of things from that list. Almost all of that functionality is available in build tools that have been available for decades. I want to

You need to remove a lot of things from that list. Almost all of that functionality is available in build tools that have been available for decades. I want to emphasize the DECADES. And then all you're left with is scaling. Which most business do not need. Almost everything you've written there is a standard feature of almost any CI toolchain, teamcity, Jenkins, Azure DevOps, etc., etc. We were doing it before k8s was even written.

imiric 2y ago
> Almost all of that functionality is available in build tools that have been available for decades. Build tools? These are runtime and operational concerns. No build tool will handle these things. > And then all you're left with is scaling. Which most business do not need. Eh, sure they do. They might not need to hyperscale, but they could sure benefit from simple scaling, autoscaling at peak hours, and scaling down to cut costs. Whether they need k8s specifically to accomplish this is another topic, but every business needs to think about scaling in some way. > Almost everything you've written there is a standard feature of almost any CI toolchain, teamcity, Jenkins, Azure DevOps, etc., etc. Huh? Please explain how a CI pipeline will handle load balancing, configuration and secret management, and other operational tasks for your services. You may use it for automating commands that do these things, but CI systems are entirely decoupled from core infrastructure. > We were doing it before k8s was even written. Sure. And k8s isn't the absolute solution to these problems. But what it does give you is a unified set of interfaces to solve common infra problems. Whatever solutions we had before, and whatever you choose to compose from disparate tools, will not be as unified and polished as what k8s offers. It's up to you to decide the right trade-off, but I find the head-in-the-sand dismissal of it equally as silly as cargo culting it.
- mattmanser 2y ago
  There's an entire part of all the build tools that handles configuration and secret management. Here's an example: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/set-secret-variables?view=azure-devops&tabs=yaml%2Cbash https://learn.microsoft.com/en-us/azure/devops/pipelines/pro... They've always had this stuff. Back in the day it used to be XML transforms. I know azure have added key vault in recent years as well so you can get the values from the key vault instead, but it seems a cynical cash grab to me. For loading balancing, there's a reason the load balancing servers all have APIs. Almost no business will save money scaling. Think about it. Most businesses are small and medium business that just don't have the volume of traffic to justify anything more than buying or renting a single/two servers vs the cost of having a scaling solution in place. There are only a small number of businesses (in the scheme of things) that benefit from scaling as you have to pay to do it. And even then the saving is often so miniscule compared to a dev salary you lose money paying people to even set it up and will NEVER recoup that cost. The cost of even having a single meeting with 4 people about it is more than the saving over a year.

imiric 2y ago

> Almost all of that functionality is available in build tools that have been available for decades. Build tools? These are runtime and operational concerns. No build tool will handle these things. > And then all you're left with is scaling. Which most business do not need. Eh, sure they do. They might not need to hyperscale, but they could sure benefit from simple scaling, autoscaling at peak hours, and scaling down to cut costs. Whether they need k8s specifically to accomplish this is another topic, but every business needs to think about scaling in some way. > Almost everything you've written there is a standard feature of almost any CI toolchain, teamcity, Jenkins, Azure DevOps, etc., etc. Huh? Please explain how a CI pipeline will handle load balancing, configuration and secret management, and other operational tasks for your services. You may use it for automating commands that do these things, but CI systems are entirely decoupled from core infrastructure. > We were doing it before k8s was even written. Sure. And k8s isn't the absolute solution to these problems. But what it does give you is a unified set of interfaces to solve common infra problems. Whatever solutions we had before, and whatever you choose to compose from disparate tools, will not be as unified and polished as what k8s offers. It's up to you to decide the right trade-off, but I find the head-in-the-sand dismissal of it equally as silly as cargo culting it.

mattmanser 2y ago
There's an entire part of all the build tools that handles configuration and secret management. Here's an example: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/set-secret-variables?view=azure-devops&tabs=yaml%2Cbash https://learn.microsoft.com/en-us/azure/devops/pipelines/pro... They've always had this stuff. Back in the day it used to be XML transforms. I know azure have added key vault in recent years as well so you can get the values from the key vault instead, but it seems a cynical cash grab to me. For loading balancing, there's a reason the load balancing servers all have APIs. Almost no business will save money scaling. Think about it. Most businesses are small and medium business that just don't have the volume of traffic to justify anything more than buying or renting a single/two servers vs the cost of having a scaling solution in place. There are only a small number of businesses (in the scheme of things) that benefit from scaling as you have to pay to do it. And even then the saving is often so miniscule compared to a dev salary you lose money paying people to even set it up and will NEVER recoup that cost. The cost of even having a single meeting with 4 people about it is more than the saving over a year.