A microservice architecture is a software pattern that arranges an application as a collection of loosely coupled services communicating through lightweight protocols. Proponents of microservices argue that isolation and thin interfaces offer optionality in implementation and composability.
But microservices aren’t always the magical solution they’re claimed to be.
In this post, we’ll go over the advantages and disadvantages of microservices, and how to evaluate if a microservices architecture is right for you.
What are microservices?
Microservices are an architectural approach in which a single application is composed of many loosely coupled and independently deployable smaller components, or services. This architectural approach can be described based on the following features:
Individual technology stacks. Each service has its own technology stack, inclusive of the database and data management model.
Reliance on communication protocols. Services communicate with one another using communication protocols, such as HTTP resource APIs and lightweight asynchronous messaging.
Organized by business capability. Services are organized by business capability, with the line separating services often referred to as a bounded context. For example, in ecommerce, everything that is related to customer management would be within one bounded context.
The advantages of microservices
A microservice architecture optimizes for a separation of concerns and coordination. These properties offer engineering teams choice and autonomy. This is why many organizations opt to build with microservices.
Some of the key engineering benefits of a microservice architecture include:
Flexibility and agility. Code can be updated easily, with new features and functionalities being deployed without touching the entire application. This also allows teams to deploy updates in a granular way and experiment rapidly.
Autonomy. At the code level, developers and teams can work independently and, optionally, use a mix of different tools and frameworks. It also allows teams to deploy updates in a granular way.
Scalability. Components can be scaled independently of one another without having to scale the entire application.
Microservices use cases
Real-time data processing and analysis. Microservices can handle real-time data processing and analysis, providing insights faster.
Batch processing. By breaking down the task into smaller independent services, you can process multiple batches simultaneously.
Load balancing. Microservices enable load balancing by scaling up only the services that experience heavy traffic, which is more resource-efficient.
Machine learning. Different models or different parts of a model can be deployed as individual services, making the system more manageable and scalable.
Internet of Things (IoT). Microservices can help handle this IoT data effectively by dividing tasks among multiple services.
5 key disadvantages of microservices
Microservices come with significant costs and tradeoffs when applied liberally: you buy optionality by paying for bespoke development and ongoing upkeep.
Most, if not all, of the advantages of microservices can be achieved with an extensible platform. A well-built kernel powering the platform can provide a set of opinionated, coupled contracts and APIs that enable it to deliver the benefits of speed, cohesion, and low maintenance, while allowing for extensibility and modular configuration where it’s needed.
Below, we’ll go over the key disadvantages of a microservices architecture—and how a platform can deliver the same value while mitigating some common microservices pitfalls:
Increased maintenance costs
Organizational complexity and overhead
Coordination complexity
Risk of failure cascades
Performance and reliability issues
1. Increased maintenance costs
The agility and flexibility of microservices introduce operational complexity and drive up maintenance costs. That does not mean engineering teams need to give up on extensibility and composability.
Strong service-level separation and composition are key to a scalable and flexible enterprise architecture, which is best derived through the use of common shared infrastructure, code primitives, and service contracts. This enables teams to operate across services with reusable context and tools, and allows security teams to enforce system-wide guarantees.
Extensibility and composability are attributes of the system design, not of a specific choice to use microservices.
Microservices aren’t the only path to extensibility. Kernel extensions and drivers are patterns that offer the benefits of a platform—speed, cohesion, and low maintenance—while allowing for extensibility and modular configuration.
A kernel extension allows for the possibility of coupling between core kernel services, while allowing inline customization of its behavior or logic. Done well, the provided logic is executed in a secure, optimized, and managed runtime that eliminates the tradeoff between coordination, speed, and extensibility. Drivers, on the other hand, provide high-cohesion integration with the kernel and give the OS new capabilities.
2. Organizational complexity and overhead
Microservices allow developers to work independently using whatever tools and frameworks they desire. They can flex their skills and deploy solutions quickly. But for business leaders, there’s an overhead to having a high degree of team autonomy.
You need a clear separation of responsibilities and detailed specifications as to what the interaction between microservices will be, and how they will be managed long-term and by whom. Unchecked, you lose operational leverage and benefits of shared standards, patterns, and knowledge across teams.
This leads to ballooning technical costs, added layers of upper management, and byzantine technical stacks whose functionality is only understood by those who wrote the implementation.
3. Coordination complexity
The acknowledged cost of microservices is that you’re maintaining and coordinating more moving pieces. And even though services can be deployed in isolation, they must work together to accomplish the desired goal. Cross-service dependencies often lead to complex and brittle deployments.
Good architecture leverages component and service isolation in appropriate places. Too much of it—a common microservices pitfall—can lead to brittle deployments that are hard to audit, scale, and debug.
🚧 Cautionary tale
For example, when Airbnb moved to a service-oriented architecture to rid itself of monolithic complexities, it found its microservices-based approach led to its own tangle of complications. The company currently has 2,000 services, managed by 500 engineers. “The dependency graph was hard to reason about,” said Jessica Tai, Airbnb tech lead manager and core services infrastructure engineer, in a 2021 InfoQ Qcon talk.
Such complexity made it hard for the Airbnb team to debug services. It also took longer to develop features due to a growing number of changes that had to be made at integration points, services started to duplicate functionality, and data was getting fragmented.
4. Risk of failure cascades
Proliferation of services—each with its own implementation, architecture, and performance characteristics—significantly increases risk of unexpected failure cascades, which requires mature cross-service tracing and debugging capabilities.
The most successful platforms come with a curated set of primitives, workflows, and best practices encoded within. Well-designed opinions lead to better outcomes and success for those who adopt them.
A well-designed API and opinionated abstraction encode best practices and allow for elegant, scalable implementations. For example, an opinionated templating language can effectively eliminate cross-site scripting (XSS) and similar, rife client-side security attacks. Or, at least, make these attacks very hard to execute. A managed runtime with execution limits, caching, retry, and circuit breakers can also provide a strong contract and guarantee for predictable performance under extreme load.
Great opinions, encoded in platforms and SDKs, are an aide to the developer. They abstract common functionality and needs behind standard interfaces, constrain and eliminate bad patterns and choices, accelerate the path to value, and minimize development and maintenance costs.
5. Performance and reliability issues
Microservices offer total optionality in choice of technology. But the overhead of managing communication across disparate services is a common performance bottleneck.
🚧 Cautionary tale
Steve Cosenza, former Twitter senior staff engineer, explains what happens when independent teams design and build endpoints for their specific use cases with little coordination: “Microservices leads to fragmentation and, inevitably, a slowing of developer productivity. While the microservices approach enabled increased development speeds at first, it also resulted in a scattered and disjointed Twitter API.”
The absence of a shared code convention or SDK increases security risks and auditing costs, and subtle version and API incompatibilities can lead to erratic and hard-to-debug user issues.
Addressing these challenges requires a mature engineering culture, including experienced engineers that know how to debug a complex, distributed application and a well-staffed operations and reliability team, as well as investment into ongoing maintenance and resilience engineering.
Are microservices right for you? (Spoiler alert: Probably not)
Microservices allow you to buy an additional layer of flexibility. The operative word being “buy.”
Microservices aren’t free—they are notoriously expensive to build and maintain. If you’re Amazon or Netflix and you need that additional flexibility, this cost eventually will pay itself off. With complex businesses of this scale, microservices are certainly worth considering.
But more often than not, microservices only introduce unnecessary cost and complexity, leading organizations to over-engineer their tech stack, and pull resources away from projects that deliver value to customers.
The vast majority of businesses are better off with a robust commerce platform that can deliver the benefits of speed, cohesion, and low maintenance, while allowing for extensibility and modular configuration with pre-built components as needed.
Shopify is—and always has been—a platform as a service (PaaS). Its product is a managed runtime that offers functional extensibility, modular composition, a large and growing set of commerce services and 3P-developed capabilities that can support retailers’ unique needs.
While there’s no single recipe for success, a well-built platform can reduce work, cost, and risk, while accelerating time to market and allowing businesses to flex their technical expertise where it really matters: becoming indispensable to their customers.
Microservices FAQ
What is the biggest problem with microservices?
Microservices have an inherent complexity that makes them hard to manage. To work smoothly, they need a well-planned architecture, which makes initial setup and ongoing management hard. A distributed system also introduces issues like network latency, fault tolerance, message passing, and data consistency.
What are the disadvantages of microservices vs. monolithic applications?
Microservices have several disadvantages compared to a monolithic application. Distributed services can be harder to manage because they need coordination between different services, which can cause network latency. It can also be hard to keep data consistent, since each service can have its own database, and transactions across multiple services can be complicated.
When should you not use microservices?
When the application is simple or small, you shouldn’t use microservices. It’s best to avoid microservices if your development team doesn’t have experience with distributed systems, network communication, and complex transactions. Microservices might not be worth the setup time and complexity for projects with tight timelines.
What is better than microservices?
Traditional architectures can be more efficient and straightforward for smaller, simpler applications. A modular monolith can also provide some benefits of microservices without the complexity of distributed systems. Despite their potential for scalability and performance, serverless architecture and event-driven architecture might be considered “better” in specific scenarios.