3 ms·
That stuck out to me as well as being suspect. > Assuming you have more than one service and more than one instance, you either need or will need stuff like se
by RajT88 4y ago
That stuck out to me as well as being suspect.
> Assuming you have more than one service and more than one instance, you either need or will need stuff like service discovery, autoscaling, and deployment versioning, and you do not want to manage all that by yourself.
To paraphrase, "If you have anything but a tiny amount of complexity to your architecture, you must add in a high degree of complexity". It sounds insane, right? Like, we're skipping some middle steps.
Yes, Kubernetes solves those problems, BUT ALSO the care and feeding of Kubernetes clusters themselves is a significant time investment. Manual scaling sucks, but if you have a good automation game, it's not that bad. Often what people think is a need to scale extremely rapidly is really an organizational problem they are trying to automate around (example: An ECommerce site sends out coupons to 10 million customers without telling the devops teams).
- klooney 4y ago> BUT ALSO the care and feeding of Kubernetes clusters themselves is a significant time investment AWS and GCP will do this for you for a small markup
- RajT88 4y agoWhile this is true (btw, Azure as well has a managed offering) the complexity is not the only issue. Cost! The article is basically advocating, "if you have more than one service, you need K8S", and sticking your app on Kubernetes in the cloud (managed or not) is a huge cost upgrade from a single or handful of servers.
- klooney 4y agoYou're right, but the higher your service count gets, the more you should probably be on k8s. Large scale ECS or Lambda stuff is much worse to maintain
- RajT88 4y agoI would disagree in a couple of important ways: 1. The higher your service count gets, the more you should probably be on some container orchestrator. There is more than one. 2. The number of services you have to manage to justify moving to a container orchestrator is most certainly not just > 1. That is crazy. I don't know the right number, as it probably varies according to how mature your organization is and how well the parts work together. But it is definitely higher than > 1! My last point is: If all teams worked together smoothly, or one team had infinite capacity, or if automation was perfect, etc. etc. etc. we wouldn't need containers, let alone container orchestration. These are solutions to people problems, not technology problems.
- politelemon 4y agoYou can't just yadda-yadda over the most important parts!