[Part 2] Six modern software architecture styles: Microservices

This blog post series reviews six common architectural styles used in distributed systems and talks about how to choose the best one for your use case.

This blog post focuses on the Microservices architectural style, however we also recommend checking the other posts in the series:

(1) Monolithic
(2) Microservices
(3) Event-Driven
(4) Serverless
(5) Edge Computing
(6) Peer-to-Peer

Microservices architectural style

One-liner Recap:

Partition your problem into multiple, independent chunks that are scaled independently.

Background:

The Microservices Architectural Style is a direct evolution of the Service-Oriented Architecture (SOA), just more prescriptive and emerging from real-world use cases. Microservices are the culmination of modular architecture, where small, autonomous app components (modules) run on different processes that communicate via networks, to form an application.

After gaining traction due to the juxtaposition with big-ball-of-mud monoliths, SOA implementations struggled because of their lack of guidance-defining service boundaries. Microservices architectures address this by breaking a business domain into bounded contexts, collaborating in a decoupled manner and with more sophisticated network communication approaches.

Aside from solving technical issues, it’s important to note the connection between the rise in microservices popularity and the need for organizational clarity, autonomy, and independence in engineering teams.

Companies were struggling to optimize developer velocity due to the cross-team dependencies because most organizations were organized in “skill-centric” departments. This meant common development woes such as: waiting on the infrastructure team to procure a server, waiting on the DBA team to make a schema change, waiting on the QA team to build a test to find a bug, etc.

Empowering individual teams by giving them the full ownership of the entire lifecycle of a service was the solution that companies like Amazon proposed. In fact, when they first openly discussed the Microservices Architectural Style, it was to try to push the idea of an independent development team with few and far between blockers. Not necessarily to promote a specific software architecture.

Weaknesses:

In 2023 Amazon Prime Video’s engineers made waves when they announced that they had migrated the service quality monitoring application from a Microservices Architecture to a Monolithic Architecture, with considerable benefits. Turns out that they had just migrated from AWS Step Functions to a fully-fledged microservice… or better yet, a “macroservice”.

In fact “microservice” can be a misnomer: they can be quite large and a better description would be a “component service” or “correctly sized service.”

However, the discussions that this article sparked were (and are) indicative of the frustration with some common pitfalls when working with microservices:

• The premature adoption of microservices by following a "design-by-buzzword" approach, rather than focusing on the business outcomes you’re trying to achieve.
• Creating unneeded complexity, especially when decomposing something too far. Microservices Architectures are notorious for becoming gigantic behemoths that require engineers to have an accurate mental map of the entire system and to know which services to bring up for any particular task - i.e. the “you have to know everything before doing anything” principle. It’s not a surprise that multi-billion dollar companies like Spotify found it necessary to invest significant internal resources to build tools that catalog their endless systems and services.
• Underestimating the substantial investment in infrastructure. Implementing this architecture successfully requires a substantial investment of time, resources, money and infrastructure. Not being able to develop and sustain a sophisticated DevOps setup to maintain the delicate balance that a Microservices architecture demands is one of the most common causes of failure.

It's also worth noting that the distributed nature of microservices also makes debugging significantly more challenging than with monoliths. A single user request might traverse five, ten, or twenty different services, making it difficult to understand what went wrong when an error occurs.

Traditional logging and APM tools can show you what happened in individual services, but reconstructing the full user journey requires correlating timestamps, trace IDs, and logs across multiple systems. This is where full stack session recordings become invaluable: they capture the complete context of user interactions across the entire distributed system, linking frontend behavior with backend service calls and responses. Instead of manually piecing together what happened across your service mesh, you can replay the exact sequence of events, seeing how data flowed through your microservices architecture and where things broke down.

Strengths:

When implemented correctly, the Microservices Architecture can give you and your team magic powers to work more effectively and build applications at extraordinary scale.

When you have multiple teams, with hundreds of engineers, coordinating any release in a monolith application becomes incredibly painful: each new change requires the deploy or release of your entire code at once (and version updates can have many changes!), which is very risky and time consuming.

Microservices liberate your development process, fostering flexibility that, in turn, accelerates your teams' velocity. Teams gain autonomy, deploying their code independently and at their own pace. This agility results in not only a quicker time to market but also the freedom to experiment with innovative solutions. Teams can select the most suitable technologies for their specific services, unhindered by standardized, one-size-fits-all approaches.

Another huge benefit lies in the enhanced system reliability. When a component experiences a failure, it does not propagate to other parts of the system. A single service can go down, be rolled back, or undergo maintenance without disrupting the entire system, ensuring isolated issues don't cascade into system-wide outages. The result is a more robust and fault-tolerant system architecture.

Real-world use cases:

DoorDash, Airbnb, Uber. The list of companies that have adopted the Microservices architecture is extensive and continues to grow. These companies leverage microservices to enhance scalability, streamline development, and offer seamless, responsive services to their global user base.