How Microservices Work

Microservices disperse the typical backend functionality of an application into individual, stateless functions.

Monolithic services

In a monolithic application, the controllers and supporting services are all part of the same application. You can trigger some behavior either through an API (which will call the controller or service method) or directly through the code.

Triggering microservices in comoposable systems

In a decoupled system, microservices are functions deployed to a cloud-based provider, and called through an API gateway. With the major cloud providers, there’s usually one service to host the function and another to configure the gateway (and perhaps others to add monitoring, logging, etc.).

Some systems may abstract this further through a middleware layer that provides a single source of truth for calling some collection of microservices.

In the end, the trigger is just an HTTP request. Interacting with your API may not actually feel too different if you’ve already decoupled your frontend(s) from your API(s).

“Serverless” functions

You will often hear microservices referred to as “serverless” functions, making it feel like there’s some magic happening without servers.

There isn’t.

From a serverless functions introductory article:

Despite its name, serverless computing still relies on cloud and physical servers to execute code, the difference being that it abstracts away the servers, operating systems and other infrastructure from developers.

This is a common pattern among the composable stack — the infrastructure is abstracted away from developers. If you were to get underneath that abstraction, you’d find similar paradigms to those you may already be familiar with today.

Microservice-based architecture example

Consider a simple example from a web application that has a shopping cart feature. In your monolithic application, you’d probably have a cart controller (or service) that would handle adding and removing items from a cart.

If your code is coupled, you’d call that service directly, as needed, based on other actions within the application. If decoupled, your frontend would be the one interacting with the API.

In a composable system, this looks similar to a decoupled monolith. The difference is that the services are distributed individually. However, the API gateway (or service middleware) may abstract away the feeling that this is any different.