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.
Table of contents
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:
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:
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:
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.
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.
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.
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.
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.
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.
Microservices offer total optionality in choice of technology. But the overhead of managing communication across disparate services is a common performance bottleneck.
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.
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.
For more information on how to evaluate the right commerce architecture for your enterprise retail business, download our whitepaper Principles of a Modern Commerce OS.
