Demystifying Microservices: It's Complicated
Over the last few years, microservices architectures have been increasingly celebrated as a way for enterprises to become more agile, move faster, and deliver applications that keep pace with changing customer needs.
Because of their autonomous and atomic nature, microservices can help a business achieve unprecedented levels of agility, empowering development teams to innovate faster by building new features and services in parallel. But these benefits come with some costs.
In this series of blog posts, we’ll discuss the growing complexity that organizations face as they establish and expand their microservices strategies, how a service mesh helps simplify that complexity, and why APIs and API management are a critical part of a comprehensive microservices strategy.
The rise of microservicesSmall, fine-grained functions that can be independently scaled and deployed, microservices provide software development teams with a new, agile way of building applications.
As microservices architectures have become more closely associated with enterprise agility, microservices investments have accelerated across the business spectrum—not just among big companies, a majority of which are either experimenting with microservices or using them in production, but also among mid-market firms and SMBs.
South American retailer and Google Cloud customer Magazine Luiza has similarly leveraged microservices to accelerate the launch of new services, from in-store apps for employees to an Uber-like service to speed up deliveries, and help it earn praise as the “Amazon of Brazil.” Other major microservices adopters, including Airbnb, Disney, Dropbox, Goldman Sachs, and Twitter, have cut development time significantly.
More microservices = more complexityIt’s clear that when microservices are implemented and managed well, they can deliver new levels of scale, speed, and responsiveness—the major IT ingredients a company needs to compete and delight customers.
Implementing microservices successfully is notoriously complicated, however.
Instead of deploying all the code each time the application is updated, as is common in monolithic application architectures, enterprises can leverage microservices to deploy different pieces of an application on different schedules.
For this to work, individual teams or developers need the freedom to refactor and recombine services based on how the larger application is consumed by users. Because a microservice in an application depends on all the other microservices that compose the application, this complexity needs to be abstracted and managed so that one team’s work doesn’t break another’s.
If a business fails to recognize that complexity increases with the number of microservices it uses, the organization’s efforts are unlikely to succeed. Martin Fowler, one of the intellectual authors of the microservices movement, highlights “operational complexity” as one of the key drawbacks of the approach, and Gartner research vice president Gary Olliffe has warned that a majority of enterprises may find “microservices too complex, expensive, and disruptive to deliver a return on the investment required.”
As the use cases for microservices have expanded, so has the complexity. The original vision of microservices held that a microservice wouldn’t be shared outside the team its creator worked with. Among the things that made them “microservices,” as opposed to APIs or service oriented architecture (SOA), was the fact that developers no longer had to worry about the same level of documentation or change management that they did with a widely shared service.
But microservices are heralded as a valuable way to reuse functions and scale them to more developers, both inside and outside an organization. The granularity and agility they provide is too valuable to confine within a single team. As enterprises have attempted to extend the value of microservices to more teams and partners, many have struggled to make microservices secure, understand how microservices are used and are performing, and successfully deploy microservices beyond bespoke use cases.
So what needs to happen to surmount management problems as microservices networks grow within an organization? We'll discuss that in the next part of this series.