[monksy]

You got to love the balant disregard for alternative architectures where this article has to advocate for monoliths again.

You can isolate pieces of your architecture and simplify them. A lot of issues with microservices inside the system (not user facing) comes from the expectations of what the microservice deals with, the enforced boundry of the microservice, intention of it, and the fact that anyone can connect to it.

Think about streaming data systems. These allow for multiple components connecting to durable queues (with maintence polices) that will process data and pass it along. This is more for data that may take longer, and shouldn't be done in the same request.

Slight personal rant: The crap that I've seen people expect of microservices to do in a request is excessive. (If you're doing more than taking a request, reading+writting into a database.. you're doing too much and your performance is terrible) Additionally there is very little consideration about what happens when a microservice performs badly.

[seibelj]

> If you're doing more than taking a request, reading+writting into a database.. you're doing too much

And this is why micro-services are poor architecture. If you need an entire service for every DB activity you are in for a terrible time.

[throwaway894345]

It's not a service for every DB activity; this is a fundamental misunderstanding about what microservices are, how to use them, etc so of course you're going to have a bad time with them. :)

[seibelj]

Yes let's make every function call its own service with monitoring, a database, the network stack, management, and so on and then enjoy wonderful performance and easy management

[heax]

Hmmm, great idea that way cloud providers can extract insane amounts of money from unsuspecting organizations. Let's call it function as a service :)

[throwaway894345]

That doesn't seem advisable. Maybe you should try microservices instead?