Microservices - WTF Are They?

Discover the essence of microservice architecture beyond its surface definition.
By Jake Brauchler |
Blog tags:

What comes to mind when you hear the term “Microservice”? Do you think of a small service? While that’s correct, there is more to a Microservice architecture.

The Why

Monolithic applications have been around for a long time in software architecture. All of the logic for your application lives in one single repository and is deployed as a unit. This is great, right? Everything is in one place, I don’t have to go check a bunch of repositories to deploy my system. And you may be right- that might be what’s best in a startup. Fast and dirty, let’s build the application. However, as your system grows, having everything in one place can quickly become difficult to maintain long-term. Release cycles slow down due to the need to make sure changes aren’t breaking other parts of the system and you likely have way too many cooks in the kitchen. Distributed Systems aren’t new, but the need for faster cycles has driven a need for large scale applications to be distributed. This is where microservices make life easier. Let me clarify; I’m not saying implementing and building a distributed system is easy. The value of a microservice architecture is in the independent nature of the different contexts within your application. When the different contexts within your system are independent it allows for smaller pieces of logic to test, smaller changesets in deployments, and overall better maintainability.

The Architecture

microservice architecture

Let’s talk about what we are looking at here. In this example, we have two applications- a web application and a mobile application. Both systems will have their different UI components but they communicate with the same API gateway to reach the necessary services for the data they need. What does the API gateway do for you? As a brief overview, API Gateway provides the core functionalities of authentication, rate-limiting, and routing to your services. Now we have the contexts below the API Gateway. You might be wondering what a context is. In my eyes, a context is a logical grouping of functionality within your system. If you are building an online store, you will likely have contexts like the following:

  • Catalog
  • Ordering
  • IAM

Each one of these contexts will have a subset of functionality, and should use ubiquitous language in order to build a team shared language. For example, the IAM context would likely have services for Users, Roles, and Permissions, whereas the Catalog context would have services like Products, Prices, and Manufacturers. Lastly, Ordering would likely have services for Billing and Shipping. There will be relationships between this functionality but the core logic for each of the contexts will relate to other Domain Objects within the context.

Other Important Considerations

While this is a basic overview of Microservices, there are still other important considerations to be made when building a distributed system.