Because of this trend in the way people are interacting with their software, the entire DevOps process has evolved as well. Regardless of the type of software you're trying to build or who you're building it for, two of the most critical concepts to understand today involve microservices and APIs. But what is a microservice and what is an API, and what situations are they commonly used for? The answers to these questions require you to keep a few key things in mind.
What is a Microservice?
To understand what a microservice is, you must first understand what it is acting in contrast to - the monolithic applications of an era that has essentially ended.
Rather than designing one massive application, the microservices architecture structures those same apps as a collection of individual services. In other words, you're designing an application as a collection of smaller services, each one running its own processes in an essentially independent fashion from the rest. Together, they still make up that larger whole that you would get with a monolithic application - but they're far easier to build and far more efficient (not to mention faster) to deploy.
As a result of this, the benefits of microservices are as important as they are plentiful. Chief among these is the fact that each microservice is itself highly maintainable and testable, thanks to the fact that they are all also independently deployable. So not only do you not have to wait for the entire application to be "finished" before rolling out critical functionality to end users, but troubleshooting microservices is also dramatically easier because everything is so loosely coupled.
If an issue is identified within one microservice, it can be tested and fixed independently without potentially negatively impacting anything else in the architecture. This allows DevOps professionals to embrace a variety of different techniques, like unit testing. This helps to make sure that when given the correct parameters, the microservice in question provides the right information - thus guaranteeing that it is operating correctly. Contract testing is also a big part of this, which tests the communication layer between the microservice and whatever other element that the microservice is communicating with at the time.
Additionally, microservices have become so popular thanks to the fact that they're highly organized around business capabilities. This, coupled with the fact that each microservice is owned by a small team of developers who can devote the appropriate amount of time and attention to it, creates a better experience for both DevOps professionals and the audience they've dedicated themselves to serving.
What is an API?
API is an acronym that is short for application program interface. It's a term used to describe a set of routines, protocols and even tools that are commonly used when building software applications.
In a general sense, think of an API as a set of instructions regarding how the various components that make up a piece of software should interact with one another. Note that the use of a third party API can also be a viable way to get an application you're developing to better communicate with one that already exists.
That second point is particularly important as most of the time, APIs are used to allow one computer program to use some level of functionality from another. A general example of this might be a store-centric app on a smartphone that also allows you to immediately get directions from your location to that store via the "Maps" app on your device. The only way the store's branded app would be able to do that would be via an API, as it would need to "communicate" with that separate app to share relevant information to make sure the directions were accurate.
The Difference Between APIs and Microservices
While these two concepts are undoubtedly related, they are also describing totally separate ideas and should always be treated as such.
Remember that an API is essentially a way for a consumer to use some underlying service within an application. A microservice is a much broader idea, describing an actual architectural design methodology that separates portions of an application into those smaller, self-contained services.
So from that perspective, an API would be a way to allow the interaction with either a microservice or a portion of that microservice. It gives the user options regarding what they can do, while the microservice itself carries out the functionality in question.
While it is absolutely true that both an API and a microservice involve the structure of a piece of software, they're describing two totally different things. But the important thing to understand is that they're not concepts that are in conflict with one another - you wouldn't choose an API or a microservice during development. Instead, they're two sides of the same coin, ultimately supporting and empowering one another to create the most important benefit of all - more freedom and flexibility for end users regarding the capabilities that they interact with on a daily basis.