4 Reasons To Migrate Your Monolith To Microservice

Understanding Monolithic Applications

Before we dive deep into what a microservices oriented architecture is, let's first understand what the current architectural landscape of enterprise applications is and how this may pose a problem to your business

The following is a higher level architectural diagram of what a classic e-commerce application's may look like running in your organization today. Let's break this application down into a few simple components

• user registration (login, logout, signup)

• shopping cart (add to cart, remove from cart, checkout)

• billing (pay for items, request a refund)

Each one of these components keep track of state through a MySQL shared database. For example

• User Registration needs to store usernames and passwords

• Shopping Cart needs to store the current state of your shopping cart

• Pricing service needs to store what the price is for each product

Each one of these components needs to be integrated with a monitoring solution like Grafana so your engineering teams can

• Visualize how many requests clients are making to your e-commerce application through dashboards

• Retrieve insights as to what pages client's are spending the most amount of time on

• Understand what part of the application client's are facing issues with

Disadvantages of Monolithic Applications

& How To Solve Them

1. Stuck to a Technology Stack

Let's say it's been 2 years of your web application serving customer requests in a production environment. You are starting to realize that the data collected from the shopping cart component does not fit the relational paradigms required in a MySQL database, and plan on migrating to a NoSQL database. However, you quickly realize all components in your application are tightly coupled to the MySQL database and performing the migration would require you to change the database for all the components.

You've encountered the first major issue with monolithic applications, you're stuck with the technology of your choosing because of the strong coupling between components of your application

However, if each component were its own microservice, each component could have its own programming language, and framework. This allows you your organization to innovate faster, introduce newer and exciting tech into your tech-stack and hire the best talent

2. Applications are Not Scalable

Another issues with a monolithic application is applications are not scalable. For example, you begin to notice that as your customer base continues to grow the numbers of users you have and the products you sell increase as well. Your MySQL database and FTP server seems to handle the increase in storage well, but your Pricing Service consumes more memory each and everyday as it processes more data.

Historically, the solution to this issue is to simply increase the memory of the server your application runs on. However, increasing the memory just to handle the highly memory intensive Pricing Service is not an efficient solution because the user registration, shopping cart and billing services are also living on the same server and don't require as much memory.

As you see another issue with monolithic applications is you aren't able to scale each service independently from one another. This requires your devops team or your sys-admin team to increase the specs of your VM or bare metals machine to handle worst-case-scenarios when your workloads are the most intensive. For example your devops team will increase the amount of computation, parallelism, disk space, and memory usage to handle the most popular sales throughout the year. However, each service is different and has different requirements; increasing the specs of all your services will drive your billing through the roof

On the other hand, if each component were running as its own service we could scale each service independent of other services. This allows your business to reduces its operational expenses and have budget for more important applications

3. Collaborating is Difficult

As your e-commerce application grows, you would like to separate the responsibility of each component of your application. So you begin by assigning ownership of each service to separate teams. You have the correct idea but your monolith doesn't allow each team to operate independently from one another.

It becomes difficult to know which team is working on what as multiple teams are modifying the same code base simultaneously.

New hires can have a difficult time navigating this complex code base as all the components are located in a single repository and the distinction between these components maybe difficult to conceptualize.

Additionally, creating a separate build process and a set of tests for each service becomes difficult with the lack of distinction

4. Slower Iterations

In the past when rolling out your monolithic applications to your production environments you would plan the rollout weeks in advance. This may include the team that owns the changes to draft a document describing risks and how the application will be rolled out. Next, an approval process would occur where stakeholders convey how confident that the risks associated with the rollout are handled properly.

Due to how tightly coupled the components of your monolith are with one another, the risks associated with the rollout are more severe. For example if I wanted to rollout a change I made to the Pricing Service there is a high chance that I may also introduce bugs into the Billing Service.

By decoupling each component into its own service, you're reducing the risk of introducing new bugs into your program

Microservices Are The Future

According to Oreilly, the usage of microservices is growing at a rapid pace. In order for your organization to succeed in its digital transformation journey, microservices are key.

Speed Up Your Digital Transformation Journey Today with Viral Software Solution's help

Sign up for Viral Software Solution's Newsletter to get Bi-Weekly content on Kubernetes, Devops, Data Engineering and much more