High-traffic web applications like Netflix and Amazon have the ability to handle 80 Million users at peak use times.
Not only do they accomplish this without downtime, they can automatically increase server capacity as needed to meet service demand.
For most of these high-traffic applications, the secret behind their scale is a software architecture pattern called Microservices, which breaks the application down into smaller self-contained parts.
In a microservice architecture, the individual services are accessed using application programming interfaces, or APIs. This normally involves the use of an API gateway that acts as a central router for API requests.
In this article, I’ll break down exactly how microservice architecture works, and how APIs are critical to the functioning of a scalable microservices system design.
Key takeaways for managers and product owners
- Microservices are the most popular application architecture used for high-scale web and native apps; in the microservice approach, each part of the app (shopping cart, payment processing, etc) is built as an independent “microservice.”
- APIs are the “glue” that allows microservices to connect and share data. Generally, this is done through a central API gateway; while microservices can connect directly via internal APIs if needed, it’s considered a poor design.
- At the simplest level, you can think of microservices as “building blocks” in an application, and the API gateway as the “glue” that connects them.
What is the difference between APIs and Microservices?
Microservices are a system design approach that breaks applications into multiple independent services, which often run on their own servers. Within a microservice architecture, APIs (application programming interfaces) are the interface used to access each service.
To put it more simply:
- microservices are small, independent apps within the larger application.
- APIs are the way that microservices process and serve data as needed to complete requests from users. (Note that this is accomplished via a central API gateway, not through direct internal APIs between specific microservices.)
Common misconceptions about Microservices vs APIs
Microservices are often confused with APIs by non-technical managers or newcomers to software development, since the term “microservice” sounds like a standard or small app. In actuality, microservices are a style of app architecture; not a specific service or vendor.
In fact, microservices can be written using any programming language or framework. It’s common for high-scale apps to have multiple microservice components built on entirely different languages and databases, and run on their own dedicated servers.
MicroservicesAPIsApplication architecture approachInterface used for connecting servicesUsed case: High-scale applicationsUse case: Connecting interdependent servicesBuilding blocks of appGlue holding blocks together
Key benefits of Microservices and APIs
Microservice-based apps are most commonly compared to monolithic and serverless application architectures.
The key difference is that microservices can have servers allocated independently, which means they can scale up as needed without impacting the entire application.
Let's say that you have an app like Uber, and you have a microservice for uploading driver verification images and another one for uploading rider dispute images. If there’s a sudden influx of driver applications, you can move the driver verification microservice to more powerful hardware, implement it using a faster programming language and use your best data centers for that, without changing any other microservice.
In contrast, Monolithic applications run on one server, which is simpler but results in less flexibility for scaling usage.
Serverless applications are also highly flexible but come with drawbacks like vendor lock-in that make them less ideal for complex applications.
Here’s an overview of the key benefits of microservices compared with monolithic or serverless apps:
FeatureMonolithMicroservicesServerless Definition All app functions, data, and APIs in one large bundle. App functions, databases, and APIs are broken into smaller independent units. App functions are abstracted to a serverless vendor like Amazon Lambda. Primary benefit Simple architecture and data management in one place Ability to scale flexibly at low cost Abstracts complexity to vendor and scales as needed Primary drawback Downtime for updates and limits to scalability Complex architecture with many moving parts Functions may run slowly compared to hosted solution
Detailed Definitions: Microservices and APIs
- Microservices: The term “microservices” is used to describe autonomous services within a larger application. Microservices are beneficial because they run on their own servers separate from the rest of the application, meaning that more servers can be allocated to that specific service without impacting the rest of the app. This results in cost and performance benefits.
- APIs: The acronym “API” stands for Application-Programming Interface. As the name suggests, APIs are used for applications to communicate with either other programmatically. API “endpoints” are the point of contact where an application or microservice receives requests and returns responses. Every microservice will have one or more API endpoints where other services can post requests, which causes the microservice to run code and return a response.
Examples of Microservices
During the development process, microservices typically come up as an alternative to monolithic app architectures. In a monolithic application, all the app data, code, and resources are stored in one place and served by one server.
The benefit of a monolithic structure is that it’s simple to set up and can be cost-effective for small-scale or internal apps.
Microservices example 1: adding scale (growing e-commerce platform)
Let’s say we have a monolithic e-commerce platform that allows users to buy and sell used items. The app gets featured on TechCrunch because of an innovative video streaming feature our team built-in. Suddenly, we have thousands of new users, and they’re all keen to use the streaming feature; the server bandwidth needed to support all the video content increases ten times overnight.
This is a case where it might make sense to rebuild the video streaming component of the app as a microservice so that we can allocate essentially infinite server power to the video-streaming service without spending heavily on unneeded servers for our less popular features like text chat and the social feed.
Had we built our app using a microservice architecture in the first place, we could auto-allocate as many servers as needed for video streaming without any need for downtime, while limiting cost by only scaling server space for the streaming component.
Building this app using microservices would look something like this:
Breaking out the core functions of the app allows us to react to user demand for a given feature or function without needing to take our app offline to add more server resources.
Microservices example 2: adding functionality (machine learning algorithm)
Another example of a situation where microservices make sense is when adding new technology to a product.
For example, let’s say the e-commerce example above is going well, and we decide to add a recommendation engine for recurring customers. To make the recommendations useful, we need to implement a machine learning (ML) component that takes in data about user behavior and outputs recommendations that can be featured to the user when they log in.
Even if the rest of our app is built on a monolithic structure, this is a good candidate for building an independent microservice because the tech behind ML is so different from the platforms used to build more basic CRUD apps.
Building the ML independently as a microservice allows our engineers to choose the most performant and maintainable tech stack for that specific function, which takes in data via an internal API from the user database and outputs recommendations as requested by the application front-end via another internal API when users log in.
As an added bonus, building the ML functionality as a microservice enables us to more easily interface with some outsourced team members who have machine learning expertise. Rather than learning our whole codebase, the outside engineers only have to interact with the specific technology driving the ML microservices.
Since the app can function without the ML component and it isn’t seeing as high a load as the rest of the app services, we may also choose to scale the servers horizontally for this specific microservice. This allows us to build and test the service without worrying about data sharding and other complexities that come with the horizontal scale used for the rest of our app.
Examples of APIs
You need to understand a few pieces of jargon in order to start working with APIs:
- REST: you’ll often hear the term “REST API” when working on web apps. REST is the most common standard used by APIs to communicate. REST APIs work by encoding requests into URLs that are transmitted over HTTP.
- API Endpoint: endpoints are the location where a given service can be accessed, usually via posting a URL with embedded instructions. When a URL is posted to the API endpoint, it triggers the application to run code according to the instructions embedded in the URL, e.g. to return specific data from the database.
- HTTP Methods: HTTP methods are the most common methods used for sending requests to APIs. POST and DELETE are examples of HTTP methods.
- API Gateway: an API gateway is the single point where the front-end or other component of an app interacts with microservices. An API gateway communicates requests to individual microservices and aggregates the results in one place.
- CRUD: CRUD stands for Create, Read, Update, and Delete. This is a common approach for defining the methods used to interact with a database via API. POST, GET, PUT, and DELETE are the corresponding HTTP methods following the CRUD framework.
APIs example 1: communicating between the front-end and back-end
Going back to our social e-commerce platform example, APIs would likely be used for the front-end of the application to communicate with the back-end.
For example, if we have a JavaScript application with a front-end built using the React framework and a back-end built using Node.js, we would use REST API Endpoints to communicate information between the front and back end.
When a user clicks the “add to cart” button, the front-end of the app would hit the API endpoint for the cart microservice, and update the customer’s cart information in the database.
Handling requests from the client-side front-end of an application is an extremely common use of APIs and is relevant to large horizontally-scaled microservices as well as simpler vertically-scaled internal tools.
APIs example 2: routing requests between microservices
Another very common pattern is the use of API Gateways to route API requests within an application.
These are actually fairly simple to understand; as the name suggests, an API gateway is effectively a single point in an application where API requests are sent, and it routes requests to the appropriate microservice within the app’s architecture.
In a traditional monolithic application, the API is the entry point to one backend. The microservices approach splits the backend into many pieces; the API is the interface to each one of these microservices.
While microservices can talk to each other directly as needed, a well-designed microservice is a self-contained entity where all API calls go through a central API gateway.
For example, our e-commerce app user will make use of the API gateway several times while using the app; first when they log in and the client requests personalization data from the ML component described above. Requests to update their shopping cart or view product details will also hit the API gateway, and be routed to the shopping cart microservice or product data microservice as appropriate.
The benefit of using an API gateway is that it reduces complexity by allowing all requests to be posted to the same location; as such, using API gateways is the standard for microservices architecture.
The API gateway can also handle authentication and load-balancing functions, and automatically trigger additional server capacity if it’s hit with more requests than expected at a particular time.
Growing popularity of microservices and APIs
Microservice architectures built on horizontally scaled servers have been around since the early 2000s, although the term didn’t really catch on until the 2010s.
The growing popularity of web applications over native apps has fueled increased demand for skill sets required to produce microservice applications. Frameworks commonly used for horizontally-scaled microservice applications like Angular, React, and Express has grown rapidly in 2020–2021 to account for more than half of enterprise developer skill demand.
The vast majority of scaled consumer-facing web applications and SaaS apps today are built on the microservices model or at least incorporate microservices for particular parts of application functionality.
Monolithic applications are mostly built when speed, simplicity, or low build cost are the primary objectives. While monolithic applications can be sensible for internal tools and low-traffic apps or experiments, any app that expects to scale up to a million concurrent users and beyond will incorporate microservices to handle its growth.
Is an API Gateway a Microservice? API gateways are not a microservice, but are commonly used in microservice system designs to communicate between the front-end of an app (the client) and the back-end services and databases that produce the app’s functionality. API gateways are an alternative to client-to-microservice designs in which the client touches individual microservice endpoints directly.
What is the difference between Microservices and Web services? The primary difference between microservices and web services is that web services are accessed over the internet. While both microservices and web services use APIs to communicate, web services are generally operated by third parties while microservices are built and maintained by the application owner.
What is the difference between a container and a microservice? A container is a virtualized package including everything needed to run an application; dependencies, frameworks, libraries, and etc. Microservices are individual function-based applications within a microservices architecture. Microservices are frequently deployed using containers to ensure no dependency issues arise when running multiple platforms and languages in the same complex application.
