Introduction to Microservice Architecture

Microservice essentials

Hello there, welcome to our first article on microservice architecture and design principles. This article is the first in a four-part series about designing, building, and deploying microservices.

At a high level, we shall have the following articles in this series:-

1. Introduction to Microservice Architecture (this article)
2. Microservices Via Gateways
3. Microservice Service Discovery
4. Refactoring Monoliths to Microservices

This series is intended for developers and architects who have an interest in building or migrating their existing solutions into a microservice architecture-like model.

The History of Microservices

To understand the microservice architecture, you need to know where it came from and the building ideology behind it.

The term “microservice” was coined as early as 2005 by Dr. Peter Rodgers describing it as “Micro-Web-Services” which led to other persons, expounding and working on that same ideology. The main building ideology since that time has been to be able to create an application that breaks a single large application “monolithic” design into multiple independent processes and components that eventually make a complete working application.

Microservice Definitions

There are multiple definitions for the term microservice, but for a long time, there has been a consensus on what microservice architecture and microservices are which is defined below.

A microservice is a small, business process oriented service.

A microservice architecture is a set of loosely coupled microservices that work together to achieve a common goal.

The image below shows a visual description of both

Microservices forming a Microservice Architecture

The microservice architecture was developed so as to solve the challenges that faced monolithic architecture.

A monolithic architecture/application is a self-contained and independent application and can perform every step needed to complete multiple business processes end to end.

Suppose you were comparing the monolithic architecture to the microservice architecture you will notice, they both achieve handling multiple processes end to end, but instead of as a single self-contained application, the microservices architecture separates each process into loosely attached services thus managing each business process independently.

Just to note, there is nothing that actually implies that a microservice should be small, or a monolith should be huge. In both architectures, the size is dependent on the number of responsibilities that developers tend to build into them. Each microservice will typically handle small business processes that are related.

Principles of Microservices

1. Autonomy — Microservices should be able to operate independently of each other. This principle enhances the performance and reliability of the services thus improving the overall quality of the system.
2. Loose Coupling — Microservices should be able to work independently but still be able to communicate with each other when needed.
3. Single Responsibility — Each service should be designed to handle a single responsibility or a single business process, or if necessary a single group of related business processes.
4. Fault tolerance — With each service attaining the above principles, the services should be fault tolerant in the case scenario a service fails the rest shall continue to perform their functions.
5. Discoverability — Microservices should be hosted in a structure that makes them discoverable via a gateway, which we will discuss in the next article.

A microservice architecture following the above principles definitely brings up a couple of benefits that would increase the efficiency of your system/applications.

Why should you adopt the microservice architecture?

For you to choose this kind of architecture, let’s understand the kind of challenges that you might be facing probably in a monolithic architecture and how this architecture would help you solve them.

1. Application Changes — As is normal in every application there are tweaks in the system which mostly just affect one part of an application. In a monolithic structure, either a large or small change would need a whole rebuild of the application.
2. Application Size growth — As the application grows, the codebase and different parts of the application tend to get mixed up and become hard to maintain.
3. Application Footprint — A huge application always consumes more memory and requires more computing power thus requiring more resources in terms of servers and such.
4. Application technology — A single huge application will most likely limit your development to specific technologies such as Java or Python only or a specific tech stack.
5. Team Scalability — With a growing application all in one, adding more team members to the codebase would bring a couple of issues on dependency.

Benefits of Microservices

1. Scalability — Smaller services can scale both horizontally as well as vertically.
2. Autonomy — Building smaller services allows your team and changes to your application to be more independent of each other.
3. Modularity — Each service becomes responsible for fulfilling fewer responsibilities, resulting in a more compact, more cohesive code.
4. Availability — A good microservice architecture and implementation allow for the different smaller services to continue to operate even if one service goes down, due to the loose coupling principle.
5. Focused — A microservice architecture allows the business to develop services that are more specific and focused on different business processes.

Limitations of Microservices

1. Debugging — It’s much easier to debug interactions in a system when the codebase or functionality is all in the same place. For a microservice, the codebase is different thus debugging get’s a bit harder.
2. Versioning — For a monolith versioning is easy because the codebase is all in a single repository which is not the case for a microservice architecture.
3. Deployment — Deploying a single application is easier even for the DevOps process unlike for a microservice where you really need a mature DevOps process.

Conclusion

This article basically informs you on the basics of microservice architecture, from where it comes from to its principles, pros, and cons, and why you should get started with the architecture.

Just to note, if you are already running a monolithic application successfully and want to convert to a microservice architecture, you need to realize that different teams implement the principles of microservices in different ways. Each team has unique outcomes for how small their microservices are, or how many microservices they need.

To determine if microservices are the best approach for your application, first identify the key business goals or pain points you want to address. There might be simpler ways to achieve your goals or address the issues that you identify rather than jumping straight onto the microservice architecture.

Great! now that you know the basics of microservice architecture, watch out for the next article on Microservices Via Gateways where we will discuss how to better implement that architecture using an API Gateway.

In case of any queries feel free to reach out.

Author: Collins .H. Munene

Socials: LinkedIn

Profession: Software Engineer | Security Analyst | Immersive Tech Developer | Mentor

Sponsored by: Devligence Limited