I feel like microservices have gotten a lot easier over the last 7 years from when Twilio experienced this, not just from my experience but from refinements in architectures

There are infinite permutations in architecture and we've collectively narrowed them down to things that are cheap to deploy, automatically scale for low costs, and easily replicable with a simple script

We should be talking about how AI knows those scripts too and can synthetize adjustments, dedicated Site Reliability Engineers and DevOps is great for maintaining convoluted legacy setups, but irrelevant for doing the same thing from scratch nowadays

▲

eYrKEC2 9 hours ago | parent | next [-]

You know what I think is better than a push of the CPU stack pointer and a jump to a library?

A network call. Because nothing could be better for your code than putting the INTERNET into the middle of your application.

The "micro" of microservices has always been ridiculous.

If it can run on one machine then do it. Otherwise you have to deal with networking. Only do networking when you have to. Not as a hobby, unless your program really is a hobby.

▲

NeutralCrane 7 hours ago | parent | next [-]

Microservices have nothing to do with the underlying hosting architecture. Microservices can all run and communicate on a single machine. There will be a local network involved, but it absolutely does require the internet or multiple machines.

▲

yieldcrv 9 hours ago | parent | prev | next [-]

it's not really "micro" but more so "discreet" as in special purpose, one off. to ensure consistent performance, as opposed to shared performance.

yes, networking is the bottleneck between the processes, while one machine is the bottleneck to end users

▲

Nextgrid 9 hours ago | parent [-]

> one machine is the bottleneck to end users

You can run your monolith on multiple machines and round-robin end-user requests between them. Your state is in the DB anyway.

	▲	yieldcrv 8 hours ago \| parent [-]
		I do bare metal sometimes and I like the advances in virtualization for many processes there too

▲

ikiris 9 hours ago | parent | prev [-]

Not everything you think you know is right.

https://github.com/sirupsen/napkin-math

	▲	josephg 9 hours ago \| parent [-]
		Well implemented network hardware can have high bandwidth and low latency. But that doesn't get around the complexity and headaches it brings. Even with the best fiber optics, wires can be cut or tripped over. Controllers can fail. Drivers can be buggy. Networks can be misconfigured. And so on. Any request - even sent over a local network - can and will fail on you eventually. And you can't really make a microservice system keep working properly when links start failing. Local function calls are infinitely more reliable. The main operational downside with a binary monolith is that a bug in one part of the program will crash the whole thing. Honestly, I still think Erlang got it right here with supervisor trees. Use "microservices". But let them all live on the same computer, in the same process. And add tooling to the runtime environment to allow individual "services" to fail or get replaced without taking down the rest of the system.

▲

moltar 9 hours ago | parent | prev [-]

Do you have any recommended reading on the topic of refinements in architectures? Thank you.