A Quick Guide to Microservice Architecture
As a tech professional, it can be daunting to think about how large companies build and maintain software. Being in an enterprise setting where an app has multiple teams working in tandem, new features being deployed, and millions of users who expect no downtime can be challenging to non-engineers working in this sector.
In light of this, I set out to break down one of the most common software architecture styles that I encountered when researching how large companies build and maintain software.
One of the most ubiquitous terms I came across was microservices. Its descriptive name might give you an idea of what this architecture pattern entails. The following is a simple guide to understanding microservices and the basic external communication design patterns that a microservice based architecture might use. Keep in mind that not only are there more software architecture design patterns, there are also design patterns for every aspect of a microservice based architecture, such as security, databases, and integration between services.
So what are Microservices?
First of all, what is microservice architecture, and how is it different from apps that do not use microservices, or monolith apps? Microservices can be described as a collection of services (they could be features or components of an app) that have the following traits :
- The service specializes in a particular functionality (similar to separation of concerns, but taken one step further)
- The service can be developed, tested, deployed and scaled independently without affecting the rest of the services
- The service would ideally still work even if other services fail
- The service contains the code needed for it to serve its particular purpose
Essentially, you can think of a microservice as a small part of a larger application that functions independently of all other parts. Together they perform the functions necessary for the application to fulfill its purpose, which could be a service like Netflix, LinkedIn, or Spotify. Since microservices are independent of each other, they can be written in different languages, and each microservice can have its own repo. To contrast this, a monolith app has only one repo, which holds all features of the app, and is usually written using one language.
Whether or not an organization uses microservices depends largely on how the business is structured. For example, if the business has one team working in one office, a microservice architecture might not be necessary. Deciding whether a microservice architecture is right for a business is a topic in itself, so I will stick to explaining more technical details.
Microservice Design Patterns
Now that we understand what a microservice is, we can move on to some of the design patterns used in microservice communication. Services communicate with each other, but they also have to communicate with external clients, like api consumers. Depending on factors such as the size, complexity and user base of the app, there are different ways to establish this connection.
Direct Client-to-microservice
The first, and perhaps simplest is the direct client-to-microservice design pattern. As seen below, a client can communicate directly with each microservice. Each external facing microservice has a connection that can be accessed by the client. This is one of the most simple ways to establish this external connection, so it may seem like an enticing option, but it has several drawbacks.
Because the microservices have exposed endpoints, it can be harder to make sure that the app is secure from external attacks. Each microservice also has the added burden of security, adding a layer of complexity that could be avoided by having a layer between the microservices and the external client. This brings us to our next design pattern.
API Gateway
The API Gateway design pattern is similar to the direct client-to-microservice design pattern, but it adds an extra layer between the client and microservices.
In this design pattern, the microservice endpoints are no longer exposed publicly, so it is much easier to take care of security. The single point of entry can also help with managing traffic to microservices, which was previously uncontrolled. While this approach is an improvement, it is also not without issues. As you can imagine, a complex application could have a multitude of clients, and the API gateway would have to manage traffic, security and authorization for all services. Our next design pattern takes these issues into consideration and breaks up the singular API gateway into multiple gateways.
Backend-for-frontend
The backend-for-frontend design pattern provides an API gateway for each client. The chart below illustrates what this might look like.
This design pattern delegates client concerns to their respective API gateways, so rather than having one complex API gateway we have as many as we need to address the different concerns of our various clients. These could be split up as needed, but every added API gateway comes with added complexity, so there is a cost to having multiple gateways as well.
Takeaways
The above patterns only scratch the surface of the complexity that comes with designing a microservice architecture. There are not only countless business factors to consider, but also technical design factors that could affect performance, scalability, security, availability, etc. The most important thing to keep in mind is that microservices are not inherently superior to monolith applications. A microservice architecture must be designed with your technical and business goals in mind while taking into account how your organization operates and who it serves. When properly implemented under the right circumstances, a microservice architecture can improve development speed, decrease complexity for engineering teams, reduce cloud costs, and better accommodate a distributed workforce.
