Microservices & APIs: common misconceptions

Microservices vs. APIs, is it a valid question? There are many misconceptions around microservices and APIs, and the idea that they oppose each other might be the main one. While doing my research, I have seen many definitions, but before we go into each of the terms specifically, I want to review some other common misconceptions.

 

First of all, APIs are not microservices. Each term refers to a different thing in software, and while they usually work together, these are not interchangeable terms.

 

Another misconception is thinking of microservices as the implementation of an API: this is also not true. As we will see afterward, microservices are often related to APIs differently.

 

Lastly, microservices are often understood as “web services but more fine-grained.” That is also not the case. Web services commonly provide an object-oriented interface to a database server and work with another web server or a mobile app that provides a user interface to the end-user.

 

You might then be wondering, what are microservices and APIs?

What are APIs?

An API is fundamentally an Application Programming Interface. So, naturally, it is an interface, meaning a way of achieving interactions or communications. It is a way of making requests to a component.

 

In current use, that typically refers to a REST API. These work as interfaces that use HTTP protocols with JSON and occasionally XML payloads.

 

When using an API, the interface decouples the caller from the implementation. Someone calling an API can have no idea how its execution works underneath. The most common analogy is comparing it with a restaurant waiter. When you sit at the table, you just read the menu, ask for information, and choose. In turn, the waiter functions as the interface between you and the kitchen implemented underneath without your knowledge.

 

APIs are a common way of reusing the same underlying information for various viewports and usages. For example, when you open the weather app on your phone, you are looking at a dedicated UI that uses an API to get the information from another provider. However, that provider can be offering their service for many simultaneous usages. That is the case with Google maps: apps like Uber or PokémonGo do not necessarily create their own maps to define GPS location but rely on third-party integrated services.

 

That gives me the perfect segway. What are microservices, after all?

What are microservices?

There is no single definition for microservices, but a consensus view has evolved in the industry. Some confusion stems from talking about microservices architecture and microservice components.

 

Microservices architecture breaks down large silo applications (often called monolithic) into more manageable and fully decoupled pieces. The objective behind this is to gain agility, dynamic scalability, and a great deal of resilience.

 

A microservice is then a component in this architecture. Several bundled together will produce a defined microservices architecture making it a microservices application.

 

This modular architecture is in service of agility, scalability, and resilience. This micro-component architecture refers to the granularity of the components, not of the exposed interfaces.

 

So each component is often a process that communicates over a network to fulfill a goal using technology-agnostic protocols such as HTTP. What does this mean in human language? These microservices work separately, meaning that their code, and even their language, can be different. Microservices can scale up or down independently and be added to or removed from the network as needed.

 

While before there was a monolithic architecture, now there are separate accounts, payment, shipping, and search components, among others. That level of independence comes especially handy when scaling one element in particular. For example, during a hot sales day, the system will require scaling up the payment gateways only for the traffic peak.

 

Microservices have many benefits:

 

• Higher team performance
• Scalability
• Versatility
• Reusable code
• Resilience
• Lower maintenance

 

After talking about microservices architecture, Docker and Kubernetes containers might have come to your mind, and yeah, they are related. But let’s leave that topic for another day and review how microservices relate to APIs.

 

So what’s the relationship between microservices and APIs?

The relationship between microservices and APIs

An API is an interface between the user and the component, while the microservice is the component itself. The two are separate concepts. For example, a monolithic application with a single siloed element could still have multiple exposed APIs. Conversely, the app could also be divided into multiple microservices components related to one or more APIs (the relationship need not be one-to-one).

 

So microservices and APIs are related, but they are not the same. An API is an interface, a way for the components to interact and present functionalities, but it is not the component itself.

 

Microservices are components that can expose one or more APIs, but not necessarily. Not all components expose APIs. So microservices work as a way to produce more agile software architectures, and they benefit by being integrated with APIs but don’t depend on them to exist or operate on the application.

 

At Awkbit, we value modular architectures as the microservices one. Also, we know that a successful API can be a blessing across the whole software industry. Thanks to these technologies, innovation can be shared and break the typical zero-sum game of understanding development and prosperity.

 

Are you ready to invest in the latest technological architecture?