[elasticventures]

k8s is the best solution for _universally_ bringing legacy pre-container "legacy" application patterns into a cloud. K8s won the battle (vs mesos, openshift) for a number of a reasons - but one of those reasons was absolutely not simplicity, rather k8s was better at handling the edge cases. This is a popular opinion held by Victor Farsick @ DevOps Paradox podcast and I happen to agree with him.

You are absolutely correct that k8s is not necessary for cloud-native environments. Existing comapnies usually have legacy applications, so they can't go "cloud native".

Once a company has started down the k8s path the org (by necessity) will start to specialize a k8s control layer and that will become embedded and you risk career-icide & being labelled a heretic if you try to challenge the rationality of using k8s. K8s creates a nice way sysops to keep devs in little boxes and limit the size of the craters they can make. All everybody wants at the end of the day is not to be hassled and not need to keep learning something new each day.

Dev's are usually horrible system operators since they fundamentally want to use code to solve problems rather than look for solutions others have built. K8s in this respect creates a very non-creative line of demarcation for system responsibilities. Devs should not be writing backup & logging applications.

If you're building a startup and you don't want the k8s complexity what you are suggesting is fine - but if you're going to work in big b0rg org, it's better to get in the k8s bandwagon - what you are saying will get you labelled a heretic, because the k8s admins have enough struggle keeping up with k8s complexity & beating devs into submission, the idea of learning anything else is unpopular.

It's straightforward to hire people with k8s expertise, but now this is a domain of knowledge that humanity has cultivated.

I remain of the unpopular opinion that k8s is really only suitable for companies which are the size of google (imho), the idea of having a massively complex & specialized administration layer for most companies is absolutely stupid. However the idea of refactoring legacy applications to be cloud native will never fly, too many risks & unknowns, disruption, big b0rg orgs dont want none of that.

So k8s is also a safe choice, it's not especially creative, it's burdensome but big b0rg orgs don't really care about any of that - these folks are unfortuantely the decision makers, and they don't understand the topics they are making decisions on, so popularity of tech, groupthink etc. are going to win there.

[linkdd]

> I remain of the unpopular opinion that k8s is really only suitable for companies which are the size of google (imho)

This is simply not true if you use managed K8s (DigitalOcean, Google GKE, Amazon EKS, Microsoft AKS, ...).

Kubernetes provide a unified API to handle almost every aspect of your containerized application (networking, load balancing, rollout deployments, storage management, service discovery, ...).

You might not need many of those, but you won't have to learn another tool to set it up once you do need it.

Buy a cheap managed k8s with a single node, helm install nginx ingress controller and cert manager (with letsencrypt). Make your app read config from an environment variable, put it in a Docker image, push it to either ghcr.io or a gitlab container registry. Write a Deployment, a Service and a ConfigMap, eventually an Ingress resource and voila. Your app is up and running in no time.

Repeat the last 3 steps for all your apps. It's that simple.

You can then work from there if needed:

  - setup a terraform to automatically setup your managed k8s and managed databases (if you need it)
  - setup a CI/CD pipeline to build/push your docker images (github actions, gitlab CI, jenkins, whatever)
  - add Prometheus monitoring and a /metrics endpoint in your app to scrap it
  - add HorizontalPodAutoscaling
  - store secrets in a Vault and inject them in your pods with k8s based auth to the vault using the pod's service account
  - add more nodes to your cluster
  - ...

None of those steps are required to start doing things, and all can be added without changes to your apps.

Yes, for small needs systemd+docker on an EC2 instance can get you far enough. But you'll need to rewrite everything when you need to scale. With Kubernetes, you won't need to rewrite anything.

If you want to self host and operate a k8s yourself, that's a complete other story, and I agree with you that you should not do that if you don't specifically need it.

[websap]

That's a lot of stuff. Have you tried building using Lambda + ALB/API GW? You write your code and ship it. Everything from auth to metrics to certificate provisioning is shipped out of the box.

There's an actual overhead of maintaining that infrastructure and if you're a small company with limited devs it's worth really evaluating if this cost is worth it.

[linkdd]

The initial setup (managed k8s + nginx + cert manager) takes 1h top.

Writing a Deployment/Service/ConfigMap/Ingress is about copy-pasting, `helm create your-chart` will even generate those for you, and you only have the values.yaml to fill out.

From experience, there is really no overhead to that simple setup. Our Github repositories each have a CI/CD workflow (github actions) to build and push the Docker images to our Dockerhub account. Creating a new repository requires copy/pasting (in fact, we automated this with a template repository).

We have a repository where all of our Kubernetes resources/helm charts/... live and are deployed automatically when merged to master/main (github actions again). This was setup once and requires no maintainance. We have no need for ArgoCD/FluxCD (aka: divergence reconciliation) at the moment, so this is enough.

Everything else I listed are extra that are not needed for small companies, but can be added later as you scale/grow.

My point is that when you scale/grow and start needing this extra complexity, the existing setup do not need to be changed.