Digital Transformation - monolithic and microservices architectures

Digital Transformation - monolithic and microservices architecture

Recap:

In my previous article Digital Transformation - how to, I talked about management commitment to pursue transformation. I also talked about monolithic applications that evolved over time become a big ball of mud and hard to maintain due to the complexity, cost, and risks involved.

Remember that the monolithic architecture is having some advantages too. Many popular operating systems are monolithic kernel based architecture. Some business app may also make sense to be monolithic and may do well but big enterprise scale applications certainly not!

This series of articles is not about designing monolithic or microservices architecture but I will just touch briefly so that the reader gets along with the entire sense of digital transformation and what they need to do. Let’s take the example of a ticket booth where one person (ticketer) is sitting and selling tickets. Here are the functional use cases for the app

• Buyer request for the ticket(s) to ticketer
• The ticketer checks the inventory of tickets
• The ticketer takes the credit/debit card and processes the payment
• The ticketer gives/issues the ticket(s) upon payment processing

The simple monolithic architecture is shown below for this simple app. No presentation layer added for simplicity of comparison with microservices

The advantage of layering application components is that it gives developer flexibility to update and enhance a specific layer without changing others as long as the contract between layers remains the same. The layering the components help segregate and organize the code. But few major disadvantages of being monolithic are

• it is still one big application having all the code-components
• It will grow complicated as more features are added
• any change (a fix or new feature) in one layer will cause redeployment of the entire app
• risk of breaking something is much higher when fixing or adding features
• testing will become hell as it grows bigger and bigger

The monolithic app may still be okay for solving simple and limited scope business problems that are not supposed to grow larger but I have seen these simple starter apps keep growing and evolving most of the times and becoming a big ball of mud. My recommendation is that if you have monolithic apps that are solving major business problems and are aligned with the strategic goals of the company then plan to redesign them in microservices architecture. Otherwise sooner or later those apps will be much bigger problem for you to maintain.

Now let's break the app into smaller units by understanding their independent functional context. Please remember that this article is not a tutorial on monolithic and microservice architecture.

Here are a few points to consider in the given problem/apps

Ticketer

• Takes ticket request
• Takes money
• Issues tickets

Ticket Inventory

• Specific inventory is given to ticketer
• Inventory is updated as tickets are sold

Payment services

• Payments are processed

Here it will look like when the above monolithic app is broken into microservices architecture

Ticketing Service

• Take ticket request with payment and other info as required
• Check inventory and calls payment service
• Issue/print tickets if payment processed successfully

Payment Service

• Process payment info

Ticket Inventory Service

• Issue tickets (update inventory)

I am trying to make it as simple as possible for the sake of understanding. The microservice architecture has many advantages other the monolithic but remember its get very complex as the number of services grows. It needs to be carefully analyzed and designed.

Just before finishing for the day, remember that services in microservice architecture are designed to gracefully handle all failures assuming everything that can fail will fail. This makes the architecture very resilient.

I will talk more in the next article