The Move to Microservices: Is it the Right Architecture for my Organization?

Introduction

The Microservices design pattern has been amongst the most popular topics for discussion among system and software engineers in the IT industry. However, it is one of those things that has proven to be easier said than done. In many cases, it’s not difficult to see how IT projects and engineers end up with suffering consequences of the wrong design and incorrect implementation due to misapprehension of the architecture. In this whitepaper series, we will offer our insights to help you to prepare your journey into Microservices design.

In this first paper of the series, we will show how a Microservice architecture is different from the traditional Monolithic architecture and what is the key characteristic you need to be aware of before facing the challenges of this new design pattern.

Monolithic vs. Microservices Architecture

When the application code base is small, the traditional, Monolithic architecture is simpler to design, develop, test, deploy, scale, and maintain because of:

• One implementation code base
• One application to test
• One artifact to deploy, such as jar and war in Java case
• One application log file to generate and review for troubleshooting in production
• One application to replicate to scale

However, as the requirements grow and the code base for the implementation becomes larger and more convoluted, it will become increasingly difficult to understand and manage. It will require more time for developers to understand the existing code base before making changes and the impact analysis tends to be less accurate. Developers will end up with multiple unit tests as it’s not possible to write unit tests that are isolated for the changes.

The below show some of the typical drawbacks of the Monolithic application development.

• Longer time to understand the implementation
• Integrated Development Environment (IDE) takes longer time to load and compile
• Impact analysis is less accurate
• More missing uses cases in testing scenarios
• Longer learning curve for new resources
• Parallel development often difficult
• Poor reusability at the enterprise level

The application performance will get degraded and hard to optimize because:

• As the application grows it gets slower and more encumbered by growth in code
• Continuous deployment becomes difficult and often impossible, a major drawback
• Scaling requires replicating the entire application behind the load balancer
• It becomes difficult to partially replace outdated solution components, often making organizations feel locked into a single technology and unable to adopt newer, and usually better applications

In the book, Microservice Patterns by Chris Richardson, the author warns organizations of the slow walk into the monolithic hell.  Fortunately, the Microservices architecture and design patterns allow us to build decoupled solutions that pave the way for a more sustainable IT architecture.

The basic concept of a Microservices architecture is to design and develop small services that have only limited responsibilities and integrate them as API or backend process.

The main benefits are:

• Easy to understand and
• Independently deployable and scalable
• Enable teams to be autonomous
• Avoid vendor lock
• Easier to replace an obsolete technology stack or language
• Better fault tolerance and isolation
• Continuous deployment and parallel development are very possible

These benefits are good enough to address all challenges discussed for Monolithic architecture.  They are possible because the

size of the implementation of each service is small enough to handle and they are completely decoupled.

How do you know when you need to adopt Microservices?

There is no mathematical formula or checklist that you can use to have one absolute answer for this question. But, there are three signals you should know that trigger the need to start considering the Microservice.

The first one is delivery speed. As the Monolithic application code base grows, it becomes more difficult to understand, analyze and build upon. As a result, the overall duration of software development life cycle become longer. This is the first signal.

The second warning signal is an increase in the number of defects from each testing cycle and following each new production release. Developers and testers will begin missing test scenarios or increasingly make mistakes as the application carries more convoluted logic.

The final signal comes as you encountered more difficulty when attempting to scale horizontally. These challenges can range from financial cost to technical inability.  For example, as the number of users grow increase, and your architecture is unable to scale out and you’re considering duplicating your entire technology stack then it’s time to consider the Microservice.

Key Characteristic of Microservices

Now, the idea of decomposing a big application into a series of mini services seems to make sense to escape, what has become the monolithic hell. But in the meantime, we have to realize where we are escaping to. The new reality we must face is the distributed system.

Because of the name of Microservice, it’s easy to get misled to the size of the service. But in the Microservice architecture, the service is not always tiny but should be a right size to become self-contained in terms of functional coverage.  In addition to that, the bigger challenges reside in how to orachestrate logic across the various services, how to make them communicate, how to define clean API’s, how to manage distributed data, and how to centralize the common concerns.

­As you can see in the Figure above, it’s one application artifact to manage with the Monolithic architecture that gets confined by the application container. On the other hand, in the Microservices Architecture, the individual services are independent but need to get controlled as one distributed system.

As the Microservices pattern gets you out of the monolithic hell, you might end up with the jungle of the complexity and get lost completely. We have a map of the Microservices journey to guide you through and lead to the right path.  In the next paper of the series, we will walk you through obstacles and challenges in your way and how to conquer them.

Figure 1: High Level Microservice Architecture

About the Author

Chung Ha is Principal Integration Engineer at BigBear.ai who has more than 20 years of IT experience in designing and implementing innovative business solutions.  He has a wide range of skills and experiences in enterprise IT system solutions for on-prem, cloud, and hybrid environments.  He is specialized in microservice system design including migrating monolithic applications to microservice architecture.