The term “microservices” appeared for the first time in 2011 at a workshop for software architects. In 2012 we started to see more and more people talking about microservices architecture, as this architectural style was proposed to improve an application’s modularity – improving the distributed development as a consequence – and scalability, and helping the Integration of heterogeneous and legacy systems.

Almost 10 years later, in 2020, we started to see some “not so happy” stories about microservices. It’s true that microservices architecture might bring several benefits, but it can also create more significant and (maybe) more complex challenges, such as testing, monitoring, and management.

We have prepared this eMag for you with content created by professional software developers who have been working with microservices for quite some time. If you are considering migrating to a microservices approach, be ready to take some notes about the lessons learned, mistakes made, and recommendations from those experts.

The InfoQ eMag: Re-examining Microservices After the First Decade include:

  • Principles for Microservice Design: Think IDEALS, Rather than SOLID – For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility.
  • Migrating Monoliths to Microservices With Decomposition and Incremental Changes– Microservices migrations are not a trivial change. You have to think carefully about whether or they’re right for you. Maybe a monolith would be enough for your context and business needs. In this article, Sam Newman shares some decomposition and incremental changes patterns that can help you to evaluate and migrate to a microservices architecture.
  • Microservices From the Trenches: Lessons, Benefits, Challenges, and Mistakes – Nicky Wrightson, from Skyscanner, hosted a panel at QCon London with participants who have moved from the monolith to microservices and in some cases back again. They share their experience with microservices on production, and also strong opinions on monorepos, on operating distributed systems, and on the best way to structure an organization to make a success of this architecture.
  • Modular Monolithic Architecture, Microservices and Architectural Drivers – Kamil Grzybek thinks that too often we implement a microservices architecture because we believe it will solve all problems in a monolithic application. Instead, we should focus on architectural drivers to find the best architecture for a system. In a series of articles, he has started to describe the basic concepts of a modular monolith and the drivers leading to a specific architecture.
  • To Microservices and Back Again – Why Segment Went Back to a Monolith – When Segment moved to a microservices architecture, they gained environmental isolation, but at a cost of higher operational overhead. Three years later, the costs were too high, and the team migrated back to a monolith. At QCon London, Alexandra Noonan told the cautionary tale, and emphasized the importance of evaluating trade-offs in architectural decisions.

InfoQ eMags are professionally designed, downloadable collections of popular InfoQ content – articles, interviews, presentations, and research – covering the latest software development technologies, trends, and topics.