Thawing the Monolith to Support Agile Microservices

While writing this article, we discovered the Wired magazine article proclaiming the return of real Wooley Mammoths. Jurassic Park / Chris Pratt fans everywhere are wide-eyed and enthused to ponder the implications of bringing back a prehistoric animal. But this is not what we want to talk about today.

Monolith applications are older in nature, yes. But seems those Baby Boomers and Gen-Xers were on to something... Nowadays we speak our own dialect of technobabble. Some of that gibberish includes words like microservices and monoliths. Let’s unpack these.

Microservice: Independent services handling specific functions, promoting flexibility and scalability. Microservices allow for modular development, enabling teams to work on different components simultaneously and scale each service independently as needed.

Monolith: Single, cohesive software unit encompassing all functionalities. Monolithic architecture simplifies development and deployment processes but may pose challenges in scalability and maintenance as the application grows larger.

The age of microservices is upon us...or is it? Microservices bring improved scalability, flexibility, and agility that many fast-moving businesses crave, but moving from traditional monolithic architecture to microservices can be tricky. The benefits of microservices were on the mind of Mark Fussell, a 22 year Microsoft veteran and co-founder of cloud application tool developer Diagrid, as he reflected on the rise and reign of microservices during his keynote address at the The Distributed Application Runtime (Dapr) conference:

“Although you may think of microservices as a technology thing, ultimately it’s actually about the business that drives it in the end. People want great experiences, they want them to be feature-rich, secure, and reliant...they need to deliver faster, and more complex technologies.”

During his two decades at Microsoft, Fussell led the Azure Office of the CTO Incubations Team. During his keynote, he described the attributes of delivery speed, software complexity, and evolving architecture as primary drivers of the ongoing microservices transition.

Traditionally, business organizations built software application stacks that became monolithic in structure and function. Unfortunately, the monolithic application architecture also tends to be cumbersome, difficult to manage, and slow to adapt to the need for dynamic, agile changes. Consequently, many enterprises have (or plan to) break these monolithic application architectures down into microservices, to form a new microservices architecture or stack.

The structure, function, and purpose of a monolith

Before we consider the structure and function of microservices architecture, it is essential to lay a foundation by defining monolithic applications. Atlassian speaks to monolithic architecture, calling it the traditional model of a software program, self-contained and independent from other applications. The word “monolith” comes from a description of something large and glacial, as opposed to the more nimble microservice architecture. A monolithic application is a single-tiered application where the user interface and data access code are combined within the same program.

eCommerce applications are among the classic examples of a monolithic applications. Even though they consist of several components, including a user interface, e-Store inventory module, shipping and dispatch module, as well as customer order and invoice modules, they are designed, developed, and deployed as a single application, with an RDBMS (Relational Database Management System) as the single data source.

There are distinct benefits to creating a monolithic eCommerce store (and other) applications. These benefits include the ease with which the software development and operations teams can develop, test, deploy, and scale horizontally by running multiple copies to deal with the increase in load when the e-store gains traction.

Drawbacks of monolithic architecture

The counterbalance to the monolithic architecture benefits (or the drawbacks) far outweigh the benefits. Some of these issues and challenges include:

• Maintenance challenges: Once the application architecture becomes too large and complex to understand, it becomes a problem to maintain.
• Size and speed: Once the monolithic application reaches a specific size, the rate at which it starts up slows right down. Consequently, it is cumbersome and clunky; thereby, preventing dynamic and agile upgrades.
• Application updates: Every time an upgrade is released, the entire application must be updated.
• Challenges when upgrading parts of the application: Monolithic applications are challenging to upscale because of the inherent conflicts between modules.
• Reliability: A bug in any one of the modules has the potential to bring down the whole system and keep it down until the problem is solved. Because all instances of this application are identical, every instance will have the same issue and must be upgraded as part of the solution.

In summary, while the benefits of monolithic architecture make it worthwhile to develop, test, and implement the application and data stack at the outset of the product’s lifecycle, the problems with maintenance, upgrades, and new feature releases can outweigh the initial advantages.

The microservices approach to the monolithic application

This brings us to our discussion of the new(er) kids on the block: Microservices.

Microservices are an approach to application development in which the large application is built on a suite of modular services. Unlike monolithic architecture, microservices compose a single application from a collection of smaller, loosely coupled services instead of creating one large, tightly coupled application. Each module supports a specific business goal and uses a simple, well-defined interface to communicate with other sets of services. Each module or service also has its own data source.

To expand upon the microservices definition, let’s consider how the architecture of our afore-mentioned eCommerce application would look when divided up into microservices. The modules now become individual services that include:

• Authorization Service
• Order Service
• Catalog Service
• Shopping Cart Service
• Payment Service
• Dispatch or Shipping Service

The pros and cons of microservices architecture

There are distinct advantages to microservices architecture, along with a few disadvantages. To summarize, most of the monolithic application architecture drawbacks we discussed are also seen as benefits in the microservices stack. Some additional benefits include:

• Continuous deployment and delivery of large, complex applications.
• Improved quality assurance processes.
• Improved fault isolation - In other words, if there is a fault or bug in one of the services, only the affected service is taken down to fix the defect. The rest of the stack remains up and functional.
• Technical variety that lends itself to specialization and sub-projects.
• Microservices function across multiple technology stacks and operating systems - In many ways, they are platform-independent.

On the other hand, disadvantages of implementing the microservices architecture include the following:

• Creating a distributed architecture is more complicated than a monolith.
• Developer tools are predominantly oriented towards developing a monolithic application than an application divided up into microservices.
• The initial deployment can be tricky.
• Testing processes are more complex and consume more resources.

Microservices: Breaking up the monolith

Of course, the elephant (or Mammoth) in the room here is the option we have yet to discuss: Breaking up an existing monolith into microservices. While this has become a path well traveled in recent years, it is not always pain free. NextData founder and CEO Zhamak Dehghani put it succinctly when she said:

“It is a worthwhile journey, but not an easy one.”

Heeding those words of wisdom from an industry veteran, let’s consider an overview of how to break a monolith up into a microservices stack.

It is essential to start with a simple service, based on functionality that is critical to the application’s architecture and frequently upgraded. In other words, start with the most complex and core part of the application’s functionality. This element must also be totally independent of the remaining monolith. Once this service has been correctly implemented, the rest of the monolithic architecture can be tackled. As Dehghani correctly states,“each step of migration should represent an atomic improvement to the overall architecture.”

Eating the elephant (one bite at a time)

At the outset of this journey, everyone involved in the process must have a common understanding of the microservices ecosystem. In summary, as highlighted above, the microservices ecosystem is a platform of services, each encapsulating a business capability or function.

In order for these services to speak to each other, each microservice must expose an Application Programming Interface (API) that the developer can discover and use to pass data (or as a particular service) to fulfill its function and return data to the asking microservice. Other important facts and considerations during the decomposition process include:

• Each microservice operates independently, which allows developers to build, test, and deploy without dependencies on other services.
• Maintenance tasks for each microservice are isolated from others, ensuring autonomy in updates and fixes.
• Microservices encapsulate single business functions, preventing cross-functionality and maintaining clear boundaries.
• The transition from a monolithic architecture to a microservices stack incurs a high cost and requires multiple iterations.
• Despite the name "microservices," the term refers to breaking down a monolithic architecture into smaller services based on business function size, rather than a specific size threshold. Thus, services need not be split at predefined sizes.

Monoliths: Back from the brink?

The drawbacks of microservices have spawned a mini-comeback for monolithic architecture in 2024. Microservices boast modularity as a key selling point, but this introduces complexity that comes from managing and orchestrating a full suite of microservices. Monolithic architecture still brings simplicity, and allows developers to concentrate on feature development rather than service interactions. Despite the negative reputation garnered by monolithic architecture, the inherent simplicity can accelerate development timelines, a critical advantage recognized by industry leaders standing pat with monolithic architecture, including GitHub, Airbnb, Netflix, and SoundCloud.

In conclusion

In the ever-evolving landscape of software architecture, the transition from monolithic architecture to agile microservices remains an ongoing topic of discussion. Mark Fussell's reflections at the Dapr conference underscored the pivotal role of business objectives in driving this shift, and highlighted the need for enhanced experiences, speed, and reliability. While they have inherent benefits, monolithic applications also present challenges in maintenance, scalability, and adaptability, which led many enterprises to embrace microservices in recent years.

Breaking monoliths into microservices is a journey worth taking, but one that comes with some challenges. The transition demands careful planning, iterative refinement, and a clear understanding of the microservices ecosystem. As some industry leaders reconsider the merits of monolithic architecture, the conversation continues, highlighting the importance of this architectural decision.