Microservices vs API: Understanding Both and How They Differ

The Amazon API Mandate

Back in 2002, Jeff Bezos sent an email to the whole company to talk about APIs and microservices. That email is known now as the Amazon API mandate, and some folks refer to Bezos’s email as the point when Amazon Web Services was born. In the email, Bezos included a few key points that I’d like to highlight next:

• Teams would expose data and functionality through service interfaces.

• Communication between services had to be done through these interfaces.

• Resources like databases couldn’t have a direct reference call from external consumers.

• Service interfaces had to be designed with the idea of exposing them externally.

Bezos was talking about service communication and architectural patterns. He intended to enable teams at Amazon to build services with as much independence as possible. Traditionally, the way companies build software is a reflection of the company’s organizational chart. For instance, an organization might have different teams in charge of specific technological segments, such as databases (DBAs) or system administrators (sysadmins). Instead, Bezos wanted to work with interdisciplinary teams, in which every team would be autonomous and wouldn’t have to ask permission of other groups.

But how is all of this related to APIs and microservices? Well, let me explain first what an API is.

API Definition: A Communication Pattern

As you probably already know, API stands for “application programming interface.” It’s basically a communication pattern between multiple systems, with a clear contract definition of how this should happen. An example of an API usually is an HTTP application that exposes communication paths that other clients can consume. For instance, there might be a path “/login” to authenticate users. But APIs don’t only use an HTTP protocol. They could use other protocols, such as a remote procedure call (RPC) or—a legacy one—a simple object access protocol (SOAP).

When Bezos was talking about “service interfaces,” he was referring to APIs. One of the benefits of this mindset is that it requires that there should be a contract in a service. This contract includes the name of the path, parameter names, payload format, output format, and so on. And the developers of the API need to respect this contract once the API is in use–even if the system doesn’t have plans to expose a service externally. Moreover, another benefit is that services don’t need to reveal the implementation details of the technology they’re using—for instance, things like a database engine, a programming language, or even a framework.

APIs allow developers to change the service as long as they don’t break the contract.

You might ask, how is the API concept related to a microservice? Well, let’s get into it.

Microservice Definition: An Architectural Pattern

Microservices came from the need to decouple systems and be able to change software more quickly. Traditionally, applications have all the business logic in one piece of software–also known as a monolith. The problem is that when you need to change one small portion of the application, you end up deploying the whole application. The bigger the app is, the riskier it becomes to make a change.

What’s the modern solution to the above problem? Well, it’s to break the monolith into microservices. A microservice then becomes an independent service from a bigger application. A microservice has a contract, like an API. Every time you need to change a small portion of the code, you don’t have to deploy the whole application. Instead, you deploy only what you need. That’s why you can’t change the contract. Also, every code change should be backward compatible–in case you need to roll back.

Bezos referred to the microservices architectural pattern in his email too. He emphasized how services should communicate with each other. But he was also implying that consumers of these services shouldn’t be sharing resources (such as databases or queue systems) directly. This is one of the key tenets of microservices: decentralized data management.

Microservices allow teams to use different technology stacks because they communicate through service interfaces. Also, microservices don’t share resources because they don’t expose implementation details. Similarly to an API, as long as microservices respect the contract, there shouldn’t be any problem when changing the application.

At this point, it looks as if there’s no significant difference between APIs and microservices. But the devil is in the details.

Let’s get into the specifics of why I said previously that these are two different concepts.

How Does a Microservice Differ From an API?

So at this point, APIs and microservices look very similar. However, an API is a communication protocol; let’s not forget about the keyword “interface” and what that means. In contrast, microservices are an architectural pattern. A microservice could expose an API to allow entities (internal or external) to interact with it. But this is only a partial definition of what a microservice is.

To help me illustrate what I’m trying to say, let me use the microservices post from Martin Fowler’s blog. That post says that some of the characteristics of microservices are: modularization, organization around business capabilities and products, effective communication, decentralized governance and data management, infrastructure automation, design for failure, and evolutionary design.

Notice from the above characteristics that communication is one of the many attributes in a microservice. An API could have the rest of the features as well. But the critical difference is modularization, which means dividing a big problem into smaller ones. With a modular approach, you’re designing services around business capabilities, not projects.

You could have something that looks like a single API. But under the hood, it’s composed of several microservices because an API could be a monolith too.

Conclusion

Comparing APIs with microservices can be tricky, especially because sometimes folks use these two terms interchangeably. But the reality is that when you pay close attention to the details, it becomes clear that these two terms complement each other. An API is a communication pattern, and a microservice is an architectural pattern. The way you define communication contracts and how you organize services are extremely important. If you plan wisely, you’ll be able to change software with more confidence more rapidly without compromising quality.

We now live in a world governed by APIs. Almost every software company has an API that its users can consume. An API was the starting point of what we know now as Amazon Web Services. APIs are what have enabled us to have practices like infrastructure as code, which is something else that’s governing our world today too.Do you want to continue learning about the concepts discussed in this post and other topics around DevOps? Plutora is offering a free book called Engineering DevOps. In that book, you’ll learn how microservices and APIs are helping teams to become more agile.