What Is a Serverless Microservice?

Microservices are smaller pieces of an application that operate independently of one another and can be deployed in several ways. A serverless microservice is deployed within a serverless architecture.

What Is a Microservice?

Imagine taking an application, slicing it into pieces, and running it as a collection of smaller components rather than as a single monolithic unit. That is essentially what microservices architecture is. Each piece of the application is called a “microservice,” it performs only one service, operates independently of the other parts of the application, runs in its own environment, and stores its own data. Despite the name, microservices do not have to be small. What makes them “micro” is that they handle only one service and form part of a larger application.

Think of an application built from microservices as being like an American football team, where each player performs a distinct role, but together the players form a team (the entire application) that collectively achieves a goal. Or think of microservices as the different systems in the human body (circulatory, respiratory, etc.), and the application as the body as a whole.

From a user’s perspective, an application built with microservices has a single interface and should work exactly like an application designed as a single package. Behind the scenes, however, each microservice has its own database and operates independently of the rest of the application. Additionally, microservices within the same application can be written in different languages and use different libraries.

Microservices are often contrasted with monolithic architecture. Monolithic architecture is the classic way to build an application. A monolithic application is a single stack, with the user interface at the top, business logic in the middle, and the database at the bottom. A monolithic application is typically hosted on a specific server or set of servers. One downside of building an application this way is that any small change to the application means the entire stack must be updated. Another downside is that if one part of the application breaks, the entire application may fail.

Advantages of Microservices

• Resilience: Because the application is split up, one part of the application failing or crashing does not necessarily affect the rest of the application’s components
• Selective scalability: Instead of scaling the entire application, only the microservices that receive a large amount of usage can be scaled
• Easier to add or update features: Features can be rolled out or updated one at a time, rather than updating the entire application stack
• Flexibility for developers: Microservices can be written in different languages and each can have its own libraries

Can Microservices Be Part of a Serverless Architecture?

Microservices can be deployed in several ways; they can be part of a serverless architecture, hosted in containers, developed using PaaS, or, theoretically, used to build a locally hosted application. However, the advantages of building an application from microservices are perhaps most apparent when the application is hosted in the cloud, either using containers or within a serverless architecture.

What Are Serverless Microservices? How Does Serverless Microservices Architecture Work?

Serverless microservices are deployed within the serverless vendor’s infrastructure and are only run when the application needs them. Depending on the size of the microservice, it can also be broken down into smaller functions. To learn more about how serverless computing works, see What Is Serverless Computing?

What Is the Difference Between a Microservice and a Serverless Function?

The tech community is still defining this distinction, but typically a microservice is larger and can perform more than just one function. A function is a relatively small piece of code that executes a single action in response to an event. Depending on how developers divide up the application, a microservice may be equivalent to a function (meaning it performs only a single action), or it may consist of multiple functions.

To extend the football analogy, consider all the duties of a quarterback: throwing passes, handing off to the running back, and so on. If the quarterback is like a microservice in the context of the team (providing the “quarterback” service), then each of these smaller activities is a function. However, the line between a microservice and a function can sometimes be blurry, just as there are certain players on a football team who perform only one task, like the kicker.