4 ms·

If you haven't broken down your software into 50+ different separate applications written in 15 different languages using 5 different database technologies - yo

by wg0 2y ago

If you haven't broken down your software into 50+ different separate applications written in 15 different languages using 5 different database technologies - you'll find very little use for k8s. All you need is a way to roll out your artifact to production in a roll over or blue green fashion after the preparations such as required database alterations be it data or schema wise.

javaunsafe2019 2y ago
But you do know which problems the k8s abstraction solves, right? Cause it has nothing to do with many languages nor many services but things like discovery, scaling, failover and automation …
- wg0 2y ago
  If all you have one single application listening on port 8080 with SSL terminated elsewhere, why would you need so many abstractions in first place.
imiric 2y ago
> All you need is a way to roll out your artifact to production in a roll over or blue green fashion after the preparations such as required database alterations be it data or schema wise. Easier said than done. You can start by implementing this yourself and thinking how simple it is. But then you find that you also need to decide how to handle different environments, configuration and secret management, rollbacks, failover, load balancing, HA, scaling, and a million other details. And suddenly you find yourself maintaining a hodgepodge of bespoke infrastructure tooling instead of your core product. K8s isn't for everyone. But it sure helps when someone else has thought about common infrastructure problems and solved them for you.
- mattmanser 2y ago
  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.
mplewis 2y ago
Yeah, all you need is a rollout system that supports blue-green! Very easy to homeroll ;)
- wg0 2y ago
  Not easy, but already a solved problem.

by wg0 2y ago

javaunsafe2019 2y ago

But you do know which problems the k8s abstraction solves, right? Cause it has nothing to do with many languages nor many services but things like discovery, scaling, failover and automation …

wg0 2y ago
If all you have one single application listening on port 8080 with SSL terminated elsewhere, why would you need so many abstractions in first place.

imiric 2y ago

> All you need is a way to roll out your artifact to production in a roll over or blue green fashion after the preparations such as required database alterations be it data or schema wise. Easier said than done. You can start by implementing this yourself and thinking how simple it is. But then you find that you also need to decide how to handle different environments, configuration and secret management, rollbacks, failover, load balancing, HA, scaling, and a million other details. And suddenly you find yourself maintaining a hodgepodge of bespoke infrastructure tooling instead of your core product. K8s isn't for everyone. But it sure helps when someone else has thought about common infrastructure problems and solved them for you.

mattmanser 2y ago
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.

mplewis 2y ago

Yeah, all you need is a rollout system that supports blue-green! Very easy to homeroll ;)

wg0 2y ago
Not easy, but already a solved problem.