With microservices and APIs, you get what you ordered

The other day I was ordering a new jacket from a popular website. The process was efficient and friendly; I was able to find, configure and pay for exactly the jacket I wanted in less than 10 minutes.

That’s when things went wrong. Apparently, this was an in-demand jacket and, even though it appeared to be available, the warehouse was out of them before my order was processed. Three days later I got a “Dear Ann Marie” letter.

You’re probably wondering how this relates to APIs. An API is a contract that enables a consumer to use the underlying service. Much like a waiter, the API takes the consumer’s order, hands it off to the provider, and then returns the provider’s response to the consumer when it’s ready. This is a fair representation of a simple API interaction.

But like all waiters, the API relies on the provider (the kitchen) to deliver the service in a timely fashion. And when demand goes up, the underlying provider service can be a bottleneck. So how can the underlying services handle demand spikes in API requests without slowing delivery? How about spinning up another kitchen – or 10?

Microservices to the rescue

A microservice is a service with a single purpose and is fully self-contained. A classic microservice has a single development team and manages its own data. It uses events to interact with other services to avoid tight dependencies – and supports fully automated deployment and monitoring. Because of its independence, it can be replicated easily for scalability (think of 10 kitchens appearing instantly). It can also be modified on its own schedule; there’s no need to coordinate with a release timeline for other services on the same platform. It can be developed in any language.

Microservices are ideal for a distributed cloud environment, since they can take advantage of cloud services which can spin up new machines in seconds. With automated deployment, a service that’s in demand can be replicated dozens of times in a matter of minutes. The independent nature of microservices also encourages faster revision cycles. This freedom enables business units to innovate quickly – fail fast – to uncover new opportunities. It also enables complex systems to be decoupled so individual capabilities can evolve at the appropriate pace.

In our kitchen example, a microservice could represent the kitchen supplying the food. But it could also represent a narrower segment – the sandwich supply service. So, if customers order more sandwiches than expected, a new sandwich kitchen (or three) can start up to handle the traffic. This enables the kitchen to allocate resources—both people and food–in a precise way to meet the needs of the customers.

Managing the sandwich supply as a separate service also has other benefits. The sandwich supply service can try out new sandwiches and adjust old ones without needing to coordinate with anyone. It can hire sandwich experts to create the sandwiches that are higher quality. This enables the restaurant to create unique and desirable sandwiches faster, just as an independent microservice can evolve faster to drive competitive differentiation.

Not all APIs require microservices. But when an API request is delivered with microservices, it provides advantages to new projects that need to scale rapidly or evolve quickly. It enables business units to fund and deploy products independently. And it increases the potential for disruptive innovation. The next time you’re sitting in a restaurant waiting for a meal – or ordering a jacket online – consider the possibilities.

 Watch the webinar below.