Build on Kubernetes from Day One(stackoverflow.blog)
stackoverflow.blog
Build on Kubernetes from Day One
https://stackoverflow.blog/2021/07/21/why-you-should-build-on-kubernetes-from-day-one/
13 comments
I'd argue that rather than building on Kubernetes, you should instead build a 12-factor app (https://12factor.net/). Those principles should allow you to take your app anywhere fairly easily, from Heroku to Kubernetes.
I think the article supposes you have multiple components to run together.
Wholly agree with this.
“ When we started building Stack Overflow in 2008, we didn’t have that choice. There was no Docker (2013), no Kubernetes (2014). Cloud computing was in its infancy: Azure had just launched (2008), and Amazon Web Services was about two years old. What we built was designed for specific hardware and made a lot of assumptions about it.”
Frankly, I miss those days.
Frankly, I miss those days.
Sigh. More “Kubernetes == Containers” words to throw on the pile. It’s easy to find issues/point at problems with the post, but I’m happy the author is suggesting long-term view of your system and is making a suggestion that k8s could help, that may be true along some slices, but you are biting off learning a complexity you may not be ready for.
> but you are biting off learning a complexity you may not be ready for.
I really think people forget how complex it is to manage VMs in any sort of reliable, reproducible fashion. In my opinion, there's a lot more complexity in configuring your process management, SSH, key management, host metrics, log exfiltration, reverse proxy, etc than there is in using a managed Kubernetes offering like EKS or GKE. You end up reinventing a lot of things with VMs to get to a state that these managed Kubernetes services give you out of the box.
This doesn't diminish the complexity of using Kubernetes, but the "simpler alternative" is something like Heroku, not EC2 (to be clear, you didn't advocate for EC2, I'm rebutting the predictable, popular argument).
I really think people forget how complex it is to manage VMs in any sort of reliable, reproducible fashion. In my opinion, there's a lot more complexity in configuring your process management, SSH, key management, host metrics, log exfiltration, reverse proxy, etc than there is in using a managed Kubernetes offering like EKS or GKE. You end up reinventing a lot of things with VMs to get to a state that these managed Kubernetes services give you out of the box.
This doesn't diminish the complexity of using Kubernetes, but the "simpler alternative" is something like Heroku, not EC2 (to be clear, you didn't advocate for EC2, I'm rebutting the predictable, popular argument).
I hope one day people realise there is a place other than kubernetes and VMs to run containers, such as GCP's Cloud Run or AWS's ECS Fargate, these are essentially plug container and play services which avoid the baggage of kubernetes and VMs
Yeah, although I get the feeling that at least ECS/Fargate will fall behind EKS as the EKS ecosystem matures (not so sure about the GCP world).
Assuming you’re relatively senior and familiar with containers and kube - learn Skaffold. Skaffold and kube are wonderful and the rough edges are being sanded down daily. I wouldn’t dream of starting a new project without it and it’s increased my velocity considerably
It is a nice starter blog. However, I disagree with few things as follows -
1. I think you should be able to run any service that you are building locally because faster the inner loop or feedback cycle is, faster you can iterate. So starting out right away on kubernetes prevents you from doing that because you can get stuck with unnecessary chores.
2. The blog makes sense in the context of a large organisation. But if you are a small startup or scale up, have simple RoR, Django, LAMP stack. It is really a lot of unnecessary accidental complexity you have to deal with before solving the real problem. You are better off with docker compose.
1. I think you should be able to run any service that you are building locally because faster the inner loop or feedback cycle is, faster you can iterate. So starting out right away on kubernetes prevents you from doing that because you can get stuck with unnecessary chores.
2. The blog makes sense in the context of a large organisation. But if you are a small startup or scale up, have simple RoR, Django, LAMP stack. It is really a lot of unnecessary accidental complexity you have to deal with before solving the real problem. You are better off with docker compose.