On their leaner-faster-better to-do lists, many companies have already checked off practices like agile and DevOps, which foster collaboration and responsiveness in meeting customers’ needs. But they shouldn’t put down their pens just yet. Microservices also help businesses create capabilities and value—at digital speed. They’re proven and potent. They also tend to be poorly understood.
Yet the idea behind microservices is actually simple. Instead of writing an application as one large “monolithic” block of code, developers link small, independent, easily reusable pieces. Each piece—a microservice—contains all of the code, interfaces, and data (or links to the data) necessary to perform a particular service or small set of services, such as updating a customer’s address or deleting customer information. Self-contained and ready to go, microservices can be plugged into a wide array of applications. They can be shared—and leveraged—throughout an organization.
Microservices aren’t a secret. Companies like Netflix and Uber have been using them for years, creating extensive catalogs that facilitate fast-paced software development. But the paradigm isn’t just for digital natives. By understanding how microservices work, their requirements, and a caveat or two, companies of all backgrounds can benefit from the flexibility and efficiency these bite-sized programs promise.
Microservices give you a lot of reasons to like them. For one thing, they play well with others. Teams looking to use a microservice don’t need to know how it works—what programming language it is built on, where its data is stored, or what the internal software logic looks like. They only need to “talk” to that microservice, sending a request—typically through an application programming interface (API)—and receiving an answer. This means that developers can easily and quickly tap into whatever microservices fit their needs.
While microservices can be used to write or rewrite an application, their real value becomes apparent when they work as reusable components in multiple applications. A life insurance company, for example, might build a “suggest next best action” microservice (prompting an agent or advisor to make a suggestion to a customer) for its fixed-annuities business, and then reuse it in its term-life business.
Meanwhile, the decoupled nature of microservices allows teams to create and improve them without worrying about complex integrations. Microservices may work with applications, and with each other, yet they are built and updated as independent units. This lets developers create and improve a microservice quickly. A team can focus on one small standalone piece of code—sometimes less than a dozen lines long, sometimes more than a thousand—and avoid complex testing (necessary under the monolithic approach) to ensure that the changes don’t “break” an application.
Indeed, even if a microservice does go down, it won’t take everything else down with it. In a well-designed architecture, if a microservice fails, another version of that microservice (or perhaps an earlier one that worked well) will come up in its place, avoiding the domino effect that can crash a monolithic application. In effect, the microservices architecture—which includes an ecosystem of automation tools—functions like the watertight compartments on a ship, where flooding is contained and disaster averted while repairs are made.
Moreover, the team responsible for a microservice has great flexibility in how it does its work. Since microservices are self-contained, developers are free to use whatever programming language, tools, and databases best suit their purpose. And they can change those languages, tools, and databases over time. As long as the APIs keep working, people outside the team never need concern themselves with the microservice’s pedigree.
It gets better still. The automation tools integral to the microservices architecture enable what’s known as a continuous deployment pipeline. In effect, all of the tedious, labor-intensive activities associated with a monolithic application world—such as testing, code integration and compiling, and infrastructure provisioning—are automated.
The upshot is that software teams can focus more on creating and rapidly delivering business value. With monolithic applications, developers often get so bogged down in their checklists that the crux of their mission—identifying how best to serve and satisfy customers—often winds up a secondary consideration. Microservices flip that dynamic, pushing the “side” issues to the sidelines where they belong. (See the exhibit.)
Given all the benefits of microservices, why not use them for everything? To be sure, the companies at the forefront of the architecture tend to be prolific microservice coders. Uber, for instance, uses thousands of microservices to support its mobile apps, internal and infrastructure services, and products.
Yet in some cases, a company might want to stick with its existing architecture. That’s because of the loosely coupled nature of microservices. Because they are self-contained, microservices rely on links—generally APIs—to communicate with applications or other microservices. This arrangement introduces a certain amount of latency, or delay, while the communications are in process (in effect, you’re hopping from one microservice to another, instead of having everything hardwired together). In most cases, the latency is inconsequential. But in certain scenarios—for example, high-volume, mission-critical transactions where speed is imperative—latency could cause real problems. Consider a high-frequency trading desk, where prices change quickly. A delay of even a fraction of a second could cause disarray (traders think they are buying or selling at a certain price, but in reality, another price applies).
Keep in mind, too, that moving to microservices means laying a fair amount of groundwork and contending with certain complexities. For example, companies need to create—and manage—the teams that will build and continually update the microservices. And there may be dozens of teams, each with a handful of engineers. Companies will also have to decide on the appropriate data architecture: will each microservice have its own repository for the data it uses or will it pull in data from a shared repository? Microservices might perform faster and more autonomously when data is “local” but be easier to design and deploy when data is shared. There are the APIs and pipeline automation tools to manage, as well.
But perhaps the biggest task—and challenge—is determining which existing applications are best suited for a microservices makeover. In effect, companies need to triage their portfolio, prioritizing applications where a transition to microservices will bring the greatest ROI. To this end, we recommend a multi-pronged approach:
Savvy companies will add a couple of footnotes to these steps. First, it’s good practice to re-evaluate applications on a regular basis. Business conditions—and strategic goals—change, so applications may need to be reclassified over time. The “retire” bucket is particularly likely to see rolling admissions. Second, it’s important to look holistically at applications. A key characteristic of microservices is that they lend themselves to reuse. So instead of looking at each application in a vacuum and deciding how it can be migrated to microservices architecture, companies should be looking across their portfolio, identifying opportunities to reuse microservices and avoid duplication of efforts.
The fast-moving, distributed nature of microservices requires companies to make organizational, technical, and cultural shifts. The good news is that many companies are already well down that road, thanks to their embrace of agile methodologies and DevOps. Indeed, agile, DevOps, and microservices form a sort of next-gen trifecta in how companies develop, deploy, and update applications.
We’ve found that organizations that succeed in creating—and prospering from—microservices embrace certain core principles and practices:
Microservices help companies get right to the point. By focusing on self-contained bits of code and data—instead of intricate integrations—developers can deliver digital capabilities at the pace customers demand and growth requires. Readily reusable, microservices can be plugged in wherever they’re needed. Like sausages, you don’t need to know how they’re made. But instead of heartburn, you get efficiency and speed.