The ONLY TWO good reasons for MICROSERVICES

Stop making microservices the goal of your architecture! There are enormous challenges and costs associated with a microservices architecture. The probability of failure is way higher than success.
In most scenarios, you would be better off by decomposing your monolith into a modulith or an ensemble of microliths.
There are only TWO GOOD REASONS FOR MICROSERVICES. Let's discover them in this video.
🤝 Do you want to connect with me? / Do you need my services? 🤝
Visit my website: marcolenzo.eu
Add me on LinkedIn: / marcolenzo
Add me on Twitter: / marco_lenzo
📝 Subscribe to my newsletter! 📝
news.marcolenzo.eu
00:00 Intro
01:05 Mirroring Organizational Structure
02:33 Information Hiding
04:15 Independent Deployability
05:12 Data Isolation
06:14 Conclusion
#microservices #softwarearchitecture #softwaredevelopment

[@MarcoLenzo]

Are you going to use microservices for your next architecture?

[@LanceBryantGrigg]

Yes and proudly.

[@priyankkeshri1619]

Very well said. The goal shouldn't be any specific type rather on should focus on one's actual requirement and the look where it fits.

[@MarcoLenzo]

100% agree!

[@portellimatthias]

100% agreed sir. A lot of developers see microservices as a solution to problems that are not inherent to monolith vs micro-services architectures. Such an approach often leads to the same monolith problems being repeated in a microservices (and more complex) environment. It is easy (if you know what your goals are) to achieve similar decoupling in a monolith and put in checks for that "rogue developer". And I'd rather deal with rogue developers in a monolith, than a more complex microservices architecture. Having said that, given the two reasons you mentioned (data separation/independent deployments) and some other more niche reasons (unreliable components etc), cover a lot of the larger enterprise solutions which end up benefiting from microservices; if done right, and towards proper goals.

[@MarcoLenzo]

Totally agree 👍!

[@Tony-dp1rl]

This video is exactly right. If you don't need independent deployments and development teams, there is very little to gain from Microservices. I would add a third reason to your two though ... Chaos, i.e. unreliable modules that crash or run out of memory and need to be restarted often.

[@MarcoLenzo]

Good point. I didn't think about that!

[@LanceBryantGrigg]

Do microservices right and you will find they are faster and have none of these disadvantages. I dunno what this author is smoking but I can promise microservices are ruddy easy when you know what you are doing. Some caviats though: 1) You have to make sure you understand when and where to use the eventbus. 2) Your replication model must be really good. If its not easy to replicate data and control the eventual consistency you will struggle. 3) You must be sure to properly build out the core systems that support the micro services. If you do not have the proper support structures (pipelines and segregated databases and monitoring and framework choice).

[@MarcoLenzo]

Lance, I feel we are saying the same thing. If you do microservices right, you will be able to enjoy the "advertised" benefits. However, they come at a cost; they need some pre-requisites; and involve a lot of risk. The caveats you mention are non-trivial for most architects and development teams. Embarking on microservices to discover you do not know how to deal with events and eventual consistency, or you don't have a proper platform is a recipe for disaster.