Do you find yourself confusing the terms "microservice" and "API" in professional conversations? It's more common than you'd think. Though it's reasonable to confuse the concepts, understanding the distinction between the two allows you to address existing company problems, find practical solutions, and have more productive meetings overall.
In this guide, we'll equip you with the knowledge of what an API is and what microservices are. Then we'll talk about how the two terms work together and differ.
What is an API?
API, or A pplication P rogramming I nterface, comes in many forms. When someone says "API," they can be talking about anything from a private API to a public API, or a SOAP API to a RESTful API. Are you beginning to understand why so many people get these confused?
Fundamentally, an API allows two pieces of software to send messages and data back and forth in a structured way, without the need for human intervention or manual data entry. Often times, when we talk about integration of software, we use API’s to allow these pieces of software to communicate.
To make this guide easier to follow, we'll talk about the API most used in the context of REST API’s and how they are used in microservice architecture.
When people talk about a REST API (Representational State Transfer) or a RESTful API, they are referring to a specific style of API. A REST API provides a stateless messaging pathway between applications. This architecture requires that each message passed between applications is entirely self contained.
Google Maps' API and Twitter's API are examples of publicly available REST API’s.
Another way to think about it is that an API is a way for your application to communicate with an external service, like Google Maps or Twitter, through a set of commands and clearly defined methods. This allows you to seamlessly add specific functions that others created for your application or software.
Let's use an analogy to describe an API:
Think about lamp manufacturers. They don't have to figure out how to build a power outlet nor learn the science of how to generate and transmit electricity. They simply create the lamp with the correct power cord (according to a industry standard specification) and know that the power outlets will provide the electricity needed for their lamp to work correctly.
What allows the power socket to interact with the lamp is the power cord. An API is an applications's power cord. It's the connecting part that allows the application to receive the data and messages it needs to work correctly.
Now for a more concrete example:
Say you wanted to create the next ride-sharing app, which requires you to utilize a map. You have a couple of options:
You and some of your best friends could build something similar to Google Maps from the ground up at the expense of your time and resources (Hi there OpenStreetMap!), and whenever there's an update on the road, like significant traffic or construction, you'd have to make the necessary changes yourself every time.
Or you could leverage a Google Maps' API. Google abstracts away all the details necessary to implement its' service behind an API and provides you with the functionality you need for your application.
The latter option allows your software developers to focus their efforts on creating unique value for your application, rather than re-creating the wheel (or in this case map) from scratch.
Now that we've gotten more precise on what an API is, let's move on to microservices?
What are microservices?
Microservices are an architectural style that breaks up an application into smaller, independent services or components (usually focused around business capabilities). These services generally communicate with each other via APIs. In other words, APIs connect each service within a microservice architecture to provide a fully functioning service or app. In this context, APIs have a slightly different functionality.
Say that your new ride sharing application needs to both provide a mapping functionality and a billing functionality. You could implement each function as a separate microservice, embedding all the business rules, logic and data needed for each service in a relatively self contained way.
By doing this, you both make it easier to maintain your services, but also increase the fault tolerance of your application. If a single service breaks, it doesn’t necessarily bring down the entire application as a whole.
Monolith Architecture vs. Microservice Architecture
A monolith architecture style is a predecessor to microservices. Formerly, developers built software programs in one piece, and components within the program were interconnected and completely dependent on one another, often times sharing the same underlying database and infrastructure. While these applications provided the same functionality as their microservice based predecessors, they had a few major drawbacks:
- All or Nothing - Customizing an application or changing a specific feature required changes across the entire software package (shift the entire monolith).
- Hard to Maintain - Upgrading monolithic software is risky and difficult, because any change in a specific function impacts the entire application suite. This presents a significant challenge in the cybersecurity era, where software teams need to move quickly to respond to new security threats.
- Vendor Lock In - Monolithic software puts software sellers in complete control, meaning that they can build a closed ecosystem where you are not able to use or integrate other software (or they may charge you a lot of money for the priviledge!)
On the other hand, a microservice architecture breaks an application suite into composable task level services. If you build an eCommerce platform using a microservice architecture instead of one big shopping cart application with many functions, there would be multiple smaller independent functions instead (e.g., a billing service, shipping options service, and a tax calculation service).
Essentially, developers can break down a monolith's functionality into smaller services that run independently from each other. This architecture allows massive opportunities for an application to scale and adapt to new business needs which is perhaps the most significant advantage microservice applications have over monolithic applications.
However, there are many more advantages to it as follows.
Comparing architecture styles: Monoliths vs. Microservices
- Language dependency: With monolithic applications, you're typically locked into decisions made in the past. For example, if the application was written in a specific programming language (for example COBOL, RPL or even Python), future components would also need to be written in that same language.
Microservices provide agility, as you can pivot individual services more quickly using standard REST API’s for communication, meaning you can change underlying technology for a specific service without impacting the entire application suite or ecosystem.
- New-hire friendliness: With monolithic applications, developers must have the context of all services if they want to make changes to monoliths safely.
With microservices, new developers only have to learn the context of the specific, independent service, not the entire application. This allows new members to train for shorter periods before getting their hands dirty.
Better software testing: The separation of concerns provided by a microservice architecture allows software teams to more rigorously test their software, while providing strong guarantees about how it will interact with other applications in an overall software ecosystem, communicating via API’s.
Change friendliness: When a company builds software with a large single codebase, even small changes in the system require an entire build and release process for the whole codebase. Introducing changes to monolithic applications like this is a tedious process, which can introduce drag on your business cycle and hamper innovation inside an organization.
With microservices, new services can be modified and tested quickly with less chance of disruption. This makes it easier and faster to push out changes and make forward progress.
- Traffic spike responsiveness: Let's look at Netflix. If they had a monolithic architecture, they'd have to adjust to holiday traffic spikes by scaling up the entire application, including functions of the app that aren't in high demand (like the DVD returns function).
With microservices, they can scale up the specific functions in high demand (like the browse function or video streaming service). Organizations wouldn't be using their budget efficiently by scaling functions that don't need to be scaled. Microservices allow them to scale up and down in response to their customer’s usage cost effectively.
Although microservices have many benefits, it's important to stress that they're not inherently better than monoliths. Microservices just provide an agile alternative to legacy monolithic software models. Both offer advantages and disadvantages, depending on your specific situation.
If you're wondering whether your organization is ready to transition to a microservice architecture approach, let us help you explore your options.
Relationship between microservices and REST API
Now that we know more about microservices and how it differs from a monolith, let's address the initial query: How do microservices differ from APIs?
If a REST API is the way in which applicaitons communicate with each other, then a microservice architecture is the venue and social ettiquite around those conversations.
Each component within the microservice architecture will have its own API to communicate with other components. Each component of the architecture builds upon the functionality offered by others, providing a cohesive application experience to your end users and driving value for your business.
Microservices and APIs will continue to play a massive role in software development and integration leading into 2022 and are transforming enterprise software solutions. Any organization looking to harness digital capabilities within their whole business process should know the distinction between the two concepts.
However, microservice architecture is not a “cure all” for your enterprise software woes. A shift to microservices requires a significant cultural change and intentional design for your software to realize its full potential.
If you're looking to transform your business processes and harness more digital capability or have already begun that transition and need additional assistance, contact us here.