[fredsted]

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.

[airhead969]

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.)

There is no other way I can see.

[macando]

> but much cleaner, workable, easier, simpler, fewer choices, more usable, more reliable, less stupid, and more standardized.

You can say this about 80% of tech yet here we are.

[papito]

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.

[cyberge99]

No sane business is saving money with Heroku. It offers zero mid or back tier flexibility. PaaS and serverless are here to stay.

[blacktriangle]

Heroku savings come in your payroll, not your monthly hardware budget.

[cyberge99]

For a startup perhaps. Regardless, it’s Opex. Heroku’s low barrier to entry does not provide value in the mid/long term.

[p_l]

Only so long as you're based in Silicon Valley, NYC, or similar US hub. Maybe in UK, but not so much.

The decision to go with GKE saved me enough money to cover payroll and then some compared to Heroku.

[airhead969]

Heroku is so damn expensive. It's basically worthless because it's competing with free.

[atmosx]

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.

[jimbob45]

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.

[dbish]

What makes you think it’s PMs making architecture decisions? That’s usually the engineers and engineering leaders (as it should be).

[atmosx]

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.

[techdragon]

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.

[cjblomqvist]

How does serverless make more sense for a simple web api than a traditional web framework?

[manquer]

Adding on to the other points.

- 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 .

[skyde]

-cheaper (dont have a vm running 24/7 just for you)

-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)

[airhead969]

Serverless? There are always servers. APIs don't exist in a vacuum or scale magically.

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.

[derefr]

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.

[airhead969]

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.

[o-__-o]

This has been the story repeated over the past 30 years

[airhead969]

Not thirty years. 10-15. IT was a big industry that everyone did up until about 2010.

[o-__-o]

I’ve been involved in IT for over 25 years, I’ve seen a lot :)

[manquer]

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.

[dilyevsky]

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?

[jackcviers3]

Yes. You should know one layer of abstraction below the one you are using. Always. Because everything leaks, and eventually you have to fix it.

[borplk]

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.

[kenm47]

The Herokus of the future will run on top of kubernetes.

[joshmanders]

Can confirm, building a Heroku of the future on top of Kubernetes.

[rcarmo]

Portainer comes to mind.