Docker with k8s is awful when it comes to resource metering. Docker is terrible with security and resource isolation. K8s, in general, is awful IMO because of the way it was architected and implemented.
Xen-ified "containers" (regular VMs but managed) with an ability to inject uniform, templated, configured concerns is how to do services: micro or macro; ephemeral app, infrastructure, or backend. Also, backups and logs have to live somewhere else.
Basically, a APPaaS/PaaS/IaaS in the spirit of K8s + OpenStack but much cleaner, workable, easier, simpler, fewer choices, more usable, more reliable, less stupid, and more standardized. (Discovery is insecure and fundamentally unworkable; top-down provisioning knows exactly what exists and is alive so use that as the authoritative single-source-of-truth.)
There is no other way I can see.
You can say this about 80% of tech yet here we are.
The decision to go with GKE saved me enough money to cover payroll and then some compared to Heroku.
In my relatively short but rich career, I rarely came across a problem that was caused by the tech. Be it k8s or PHP, the problem was ppl using PHP while thinking in terms of Go/Python, or using Kubernetes for stateful monoliths, etc.
We blame the tech because we don’t spent time to understand how it works. So we use the next tool very happily until we come across a new design pattern, context, etc. The circle repeats...
Micro services have very well documented pros and cons. Monoliths too. At this point it’s all about the engineers using the tool at hand properly.
However what seems to be missed in a lot of assessments is what I’ve started calling “flying buttress architecture”… you have your central monolithic structure, but rising around it are dozens of smaller supporting elements, not the same as having a seconds task queue system, this is building these components as stand alone parts. These “flying buttresses” can be spun up and down ephemerally in a Kubernetes environment, built as a light weight services or as “run once” jobs and cronjobs scheduled by Kubernetes to use up the spare resources left over in each Kubernetes node around the main monolithic applications.
This makes Kubernetes more useful as a deployment and ops tool when dealing with traditional or existing/legacy software.
- Zero to very minimal devops / syadmin knowledge required. - Monitoring and few other important tooling is usually out of the box
- Add on / Related services in serverless stacks like vercel/netlify etc also handles email/auth type components, a framework will only provider library for these, implementation is in developer hands.
- Simplified deployment : most services can sync with Git repos, provide one click deploy and have simple CLI binaries .
-Easier to auto-scale because it does not have any state
-Can easily run at the Edge (look into lambda at edge of cloudflare worker)
If you don't understand how to build what's underneath, then you don't understand what's involved and are at the mercy of vendors or someone else.
Everybody has at best little or shaky knowledge of underlying abstraction. Yes it helps to know more, but is not really practical to expect that knowledge as the minimum required.
For more simple workflows, e.g. a single API endpoint, there's serverless and other SaaS services out there which will let you build off from that, and lets you save a huge amount of time and money compared to building it traditionally with a Web framework.
Now that we've had a few years of experience with how people are actually using the platform , I could see a simplified version of Kubernetes taking hold for businesses still running complex sets of services, something that's easy to install, actually comes with batteries included and is secure by default.