People often come to very reasonable, but unfortunately incorrect conclusions about the relationship between APIs and microservices. In this short post, we make a clear distinction between the two, yet also show how they are closely related. If you prefer, there is also a short video in our new “Integration Design and Architecture” playlist on the IBM Support and Training YouTube channel
This is the first in a series of blog posts on integration design and architecture bringing targeted discussions on common topics we come across in the field. More on that at the end of the post.
Misconception 1: Microservices are like web services but more fine grained
A common point of confusion is where someone has a background or at least an awareness of web services. These are a type of interface that allows you to make relatively coarse grained requests to retrieve or change data in an underlying system. Someone from this background might then hear the term microservice and assume that it must mean a finer grained version of a web service. They’re unfortunately already on the wrong track. The term “service” is ambiguous, and means something very different in “web service” to it does in “microservice”.
Misconception 2: APIs are microservices
It isn’t a huge leap from the first misconception, to accidently link microservices to APIs. Modern APIs, often called REST APIs are known to be more fine grained, pulling back individual data resources and using the more lightweight JSON data format. So if these are more fine grained interfaces than web services, perhaps these are microservices? Wrong again unfortunately. We’re making the incorrect assumption that a microservice is some kind of interface. More on that in a moment.
Misconception 3: Microservices are the implementation of an API
The final common misconception is that microservices are the underlying implementation of an API. This is arguably getting a little closer to the truth, but we still in danger of drawing some incorrect conclusions. Microservices are not the only way to implement an API, and indeed not all microservices expose APIs.
What is an API?
API stands for “Application Programming Interface”. By definition, an API is an interface. A description of how to interact with a system to retrieve or change data within it.
Figure 1. APIs are used to expose the functionality of an application.
Although it’s a more generic term, in modern use it almost always refers to what might be better termed “web API”; an interface provided over the HTTP protocol, typically using JSON or sometime XML for the data format. Arguably a web service using SOAP could also be classed as a modern web API, but this type of interface doesn’t adhere so easily to the “RESTful” design principles typically target by APIs.
What is microservice architecture?
Microservices architecture is an alternative way of building a software component by breaking it down into small independent pieces.
Figure 2. The difference between siloed and microservice applications
Traditionally we have often tried to pack as much functionality into a single application as possible, creating what is sometimes referred to as a “silo” application. An example would be a JEE application server packed with perhaps 10s or even 100s of bundles of java code. Putting all this code in the same container was traditionally to benefit from simplified administration and scaling models.
However, silos have disadvantages too in terms of flexibility. It is hard to safely change code within a large monolith, and deploying those changes into a container shared by other code is always risky. Microservices architecture is a much deeper subject than we can cover in this short description but the key point for the purposes of this discussion is that microservices architecture is about a more fine-grained approach to how you break up the components of your solution. Perhaps a less ambiguous term might have been “micro-component”.
How are microservices and APIs related?
Microservice architecture is a way to break up an application into smaller components. An API is an interface that lets us expose that application to other systems. We might choose to use APIs to expose our microservice components, or put the other way around we might choose to implement our APIs using microservices components, but neither one implies the other.
What do we mean when we talk about fine-grained vs coarse-grained?
We could say that “microservices architecture” is really “micro-component architecture”. The key point here is that the “micro” in microservices architecture refers to the granularity of the components, not the granularity of the exposed interfaces. So microservices architecture means an application made of fine-grained components.
Figure 3. The micro in microservice refers to the component
Choosing a microservices architecture to implement an application doesn’t imply anything about whether it is exposed using APIs, or indeed how those APIs are structured. It may expose just the same number APIs as it would have done if you had implemented it as a single silo.
We could have a separate discussion about the granularity of the APIs themselves. For example how much data is exposed by a single request to the API. However, this is about the granularity of the interface and is a completely separate discussion from the component granularity we were talking about in relation to the microservice components.
Summarizing the fundamentals
It is now very clear that microservices and APIs though related, are most certainly not the same thing. We’ve discussed that the core different is that APIs are an interface, where as a microservice is a component.
Figure 4. APIs are interfaces, microservices are components.
A really important conclusion follows from that simple statement. A microservice component certainly can be used to implement an API. It is important to note however that there is not a one to one map between an API and a microservice. Depending on the granularity, a single microservice component might provide the implementation for more than one API, or in the opposite direction it may only provide a portion of an APIs resources, or maybe even only one action on a particular resource. If we follow that to its natural conclusion we should also recognise that a microservice component may not expose any APIs at all. It might be a component purely focused for example on asynchronous processing of messages and have no synchronous interface at all.
With that, we should now have that clear crisp definition of both microservices and APIs, how they are related, and how they are different.
More information
If you found this useful, keep an eye out for a series of future posts on integration design and architecture right here in this integration blog, often in parallel with parallel videos in the related IBM Integration Design and Architecture playlist. We plan to cover topics such as how services oriented architecture (SOA) relates to microservice architecture, where API gateways fit in the mix, what’s happened to the enterprise service bus (ESB) pattern, and more. We’ll of course also discuss how to these relate to the IBMs Hybrid Integration [link] portfolio. However, if you can’t wait for the next post, there’s a more detailed discussion in this article on microservices in relation to integration architecture and SOA