As businesses start to realize microservices aren't really worth it due to the complexity and cost it entails, they will start reverting back to hosting monoliths on VMs or services like Heroku/Netlify/Laravel Forge/Beanstalk, and they'll find out they can save a lot of money on compute and man hours by doing this.
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.
The biggest problems with microservices are the lack of injecting cross-cutting concerns like security, monitoring, circuit breakers, resource metering, alerting, service dependencies, logs, resource isolation, upgrading on-the-fly, migrations, backups/restores of data, and configuration. These all have to be handled.
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.)
You can do circuit breakers with a monolith. "Release It!" is an excellent book that covers many patterns that do not involve the last resort of distributed systems.
I had the same experience with AWS lambda. Every app with mid to big scale was 10x more expensive on Lambda compared to Kops managed k8s cluster that was already there.
Microservices are worth it, just not for every use case. It sounds like you're blaming Google for misleading PMs into using something they didn't need. However, Google made a great product for those who need it. It's not google's fault that PMs love cargo-culting.
Are μServices complex or ppl just don’t like learning new dev patters?
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.
A micro service architecture can introduce a lot of complexity that depending on the developers and their management, can bring with it a lot of downsides.
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 .
I have built what was underneath — and then threw it away, because the managed-services vendor built it better, and the OpEx of paying them to manage it was less than the OpEx of paying myself to maintain it.
It absolutely depends on scale. Smaller teams of better staff can sustain cloud infrastructure, especially if grabbing as many internal needs as possible so as to gather critical mass to make it pay for itself.
By that logic I as AP dev should know systems programming and OS. A systems programmer should know kernel development ? A kernel developer should know assembly and microprocessor architecture?
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.
Yes you should have at least some knowledge of architectural principles and design of an api layer you directly depend on. How is that not just common sense?
Every time someone mentions serverless some smartass feels obligated to mention that "there are servers". Yes we know. It's a specific technical term to refer to category of serverless products like AWS Lambda.
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.