An Overview of Microservice Architecture Implementation Patterns

by Noah Howard

Introduction

When building an application, there are many different implementation strategies that people use. The most popular strategy is to build a monolith. Monoliths work well at the start, but over time monoliths have a tendency to run into problems as the user base scales and the code base scales. One solution to this is to use microservices. Microservices have become very prevalent in recent years as advancements have been made in cloud computing technologies. Businesses can use microservices to optimize their costs and scale rapidly. This has allowed for some extreme advancements in how effeciently software can be used by millions of users, such as how Netflix handles their entire production load and optimized their costs. However, it can be difficult to figure out the best way to implement microservices because there is a lot of information online about different ways to do it and most approaches are heavily opinionated on which approach has worked best for the author. There are a couple of strategies for implementing microservices and the “best” one really depends on what needs to be accomplished.

Service Mesh Pattern

One of the patterns that is commonly used is a service mesh pattern. In this pattern, each service runs its own public facing API, rather than only doing that internally. It is left up to the client to figure out which service to use. This is typically done with a central registry of the services and an API to give the client the address to the correct service. The registry usually handles load balancing too. Using a service mesh enables complete decentralization for the platform.

Service meshes are good if there is a large platform written in several languages. It solves a lot of problems with logging, error tracing, and security ¹. It is also the most decoupled approach to writing microservices, so it is good if the application is very high traffic since each service is completely self contained and can be scaled individually. Here are some pros and cons to the service mesh approach:

Service Gateway Pattern

Using a service gateway pattern, the monolith is still split up into several small services but instead of the client discovering which service to route to, there is one centralized “gateway” that determines the service to route to in the background, without the client having to do anything special. This also allows for the exposure of multiple types of API’s, such as a RESTful API and a GraphQL API without having to do anything special. The gateway will handle whatever is sent and ensure that it is converted to the proper request for the service ².

This approach works well because it has the benefits of a microservice architecture but without the overhead of a completely decentralized solution. It is very easy to take an existing API and move it over to a service gateway pattern by just breaking the code out into pieces and adding a new gateway for routing. Instead of having to update the entire platform to use the new decentralized approach, it can be updated piece by piece. Here are some pros and cons to this approach:

Conclusion

References