How Microservices and APIs Make Beautiful Music Together 

(Aha-Soft/Shutterstock)

When I talk to enterprise leaders confused about managing microservices, I sometimes begin by asking them to imagine an evening at the symphony.

I love the sound of an orchestra tuning before a performance. That that riot of competing sounds; one second, it’s all an amorphous blur; the next, an individual instrument peeks out above the mix, only to melt back into the blend a few seconds later. Listening to it, it’s hard to believe that a few moments later, this swarm of instruments will produce a unified, sonorous sound that combines both precision and artistry.

Microservices, each with a distinct purpose, are like the individual instruments in an orchestra, and they can bring a lot of benefits. They are small, single-purpose units of code, easily produced by a single person or team, easily understandable. Microservices are efficient deployment architecture. When compared with the complicated, hard-to-modify monolithic systems or the large macroservices of the past, it’s easy to see why microservices — and the granularity and agility they can provide to development teams — have drawn so much interest.

Just as many people learn music by starting with only a few instruments and collaborators, many businesses start with a small group of microservices. In music, it’s easy enough to stay in sync with two or three musicians. Likewise, a few microservices developed within the same timeframe or by adjacent teams may be relatively easy to manage. It’s not difficult to remember who does what and who talks to whom. But then the organization adds more services — and then a few more.

This accumulation reminds me of a time that, playing in a student orchestra, I complained to the director that the world’s best bands didn’t have conductors. I realize now that the world’s best bands have only four or five members, but the world’s best orchestras all have a conductor. As more instruments are added, they need someone to unify the individual sounds into a coherent melody.

It’s the same with an organization; as it adds more microservices, it needs mechanisms for coherence. This is one of the biggest challenges around microservices. It’s easy for a business to get lulled by the first few it builds. Three services are like a coffeehouse jazz trio. But what works for that trio won’t work for an orchestra.

As services are added, the dependency graph can become more complicated, which is one reason some companies hit walls when using microservices. But complexity, in and of itself, doesn’t explain everything. Another factor is confusion between creating and managing microservices over against creating and managing APIs. This often occurs because the organization has a murky understanding of the how microservices are used in different contexts.

Two kinds of complexity emerge from a cluster of microservices. The first involves dependencies within the organization’s network. These dependencies rely on coordination among the microservices themselves and are best resolved by a service mesh such as Itstio — a dedicated layer that manages service-to-service communication and facilitates load balancing, failure recovery, monitoring, access control and other requirements.

The second complexity: how microservices are consumed. This is typically best resolved by APIs and an API management platform. The API approach makes the services consumable to other parties, provides visibility into API consumption, allows the organization to impose rate limits, facilitates discovery and access to APIs, and otherwise enables an organization to control and understand how its APIs are being used.

Enterprise leaders who think they have an API when they really have a bunch of microservices are like that orchestra tuning on stage. They are forgetting that the raison d'être of these services is to be consumed, and that consumption occurs via an API.

That is, an API turns raw microservices into consumable products that developers can leverage to build new experiences for end users. A well-designed API can hide the complexities of services and the back-end systems behind them. It can expose the functionality of the microservices in a highly consumable, standardized way.

What’s more, an API allows other musicians to join a jam session. Partners and third-party developers can easily participate and bring their expertise to an organization’s ecosystem by consuming its APIs. For example, many smartphone apps allow users to send their photos directly to a drug store for printing because the store has exposed its photo printing services as a managed, productized API.

A final word: Lest anyone think this is an either/or competition between APIs and microservices, bear in mind that when you play your favorite tunes on your smartphone, the music dripping from your earbuds is the result of microservices productized through an API. Both of these technologies are made for rapid prototyping, rapid iteration and rapid deployment. Both enable developers to create customized, ever-evolving user experiences. They both serve a purpose, and when a company is clear on directionality challenges and solves each correctly, we can all enjoy pretty music.

Brian Pagano is global platform strategist at Google Cloud.