Looking beyond the hype and explaining why microservices should nearly become extinct.

Lobsters is a community-driven platform for sharing and discussing links to articles, tutorials, and projects related to technology and programming. Readers can learn about a wide range of topics, from software development and system administration to cybersecurity and artificial intelligence. With user submissions, comments, and voting, Lobsters provides a platform for collaborative learning and knowledge sharing among technology enthusiasts.

Lobsters

This post argues for the use of modules instead of microservices, highlighting the benefits of modules and the challenges of microservices. It also provides scenarios in which microservices may be appropriate. Overall, a well-structured modular monolith is recommended over microservices unless specific use cases demand them.

Don't Microservice, Do Module

When Should You Consider Using Microservices? #

Really interesting article! Using microservices comes with great complexity and initial overhead. Software systems tend to grow and become more complex over time. Therefore, using modular monoliths will result in slower development cycles. Microservices on the other hand are released and maintained individually. Meaning increasing code bases wont contribute to slower development cycles. The article is correct to research what solution is best. For smaller and less complex projects a modular monolith will be sufficient. Later a migration can be scheduled to migrate is easily to a microservice architecture.

MicroTransactions: If I was a cloud services provider, I’d prefer everyone uses microservices because that’s how I can make as much profit as possible.
Api Gateways/Api bottlenecks:
Imagine my shock when I saw the api gateway pattern for microservices. I mean why am I separating everything as individual services then I introduce a single point of failure for these services in the form of an ApiGateway
Redundancy: One of thr most common things I heard as a young developer ages ago is avoid redundancy at all cost but all of a sudden, redundancy is good ?
Development/Debugging: This is extremely stressful, the fact that you have to set up services to monitor services which in turn also need to be monitored is in my opinion counterintuitive
Monoliths can be distributed, there are frameworks for this. In the .net world, that would be Microsoft orleans. You get the ease of developing like its a monolith but then all the benefits of distributed.
This isn’t to say microservices don’t have their place but I think the push to build everything from a note taking app to some complex banking system as microservices is more financially motivated than practicality

We do this extensively at Exein and it has paid dividends. We still don’t ship monolith, but rather a very few number of meaningful services that share common libraries for all auxiliary functionality. Rust lends itself very well to this with its workspaces.

I believe the article is correct. We used microservices extensively, and it ended up being very difficult to make changes and improvements. The complexity became unmanageable. Using modules and microservices only for outsourced services was the right move for us.

Thought provoking article.
I feel there are other reasons that make it worth extracting a logical business function as a micro-service, even if it is owned by the same team. One such reason is shuffling responsibilities amongst teams as the business re-orgs itself over the years. Many times the teams end up owning a different subset of independent business units, and were they deployed as separate micro-services from start, it eases the change in ownership quite a lot.
Which brings me to:
<blockquote>
Team Autonomy: Is it really that challenging to instruct a team to work within a specific directory?
</blockquote>
Yeah! It is. Eg: it is hard to control teams from making changes in the code-path that ideally should be left alone, because individual devs/team finds it reasonable to do so. Its not always worth spending the time on alignments about changes across a share code-base among teams.