Table of Contents
Escaping Monolithic Hell
Return to Microservices Patterns
Escaping monolithic hell
The symptoms of monolithic hell and how to escape it by adopting the microservice architecture
The essential characteristics of the microservice architecture and its benefits and drawbacks
How microservices enable the DevOps style of development of large, complex applications
The microservice architecture pattern language and why you should use it
“Like many other aging enterprise applications, the application is a monolith, consisting of a single Java Web Application Archive (WAR) file. Over the years, it has become a large, complex application. Despite the best efforts of the development team, it’s become an example of the Big Ball of Mud pattern (https://laputan.org/mud). To quote Foote and Yoder, the authors of that pattern, it’s a “haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle.” The pace of software delivery has slowed. To make matters worse, the application has been written using some increasingly obsolete frameworks. The application is exhibiting all the symptoms of monolithic hell.”
“…a typical enterprise Java application. The application has a hexagonal architecture. In a hexagonal architecture, the core of the application consists of the business logic. Surrounding the business logic are various adapters that implement UIs and integrate with external systems, such as mobile applications and cloud services for payments, messaging, and email.”
“The business logic consists of modules, each of which is a collection of domain objects. Examples of the modules include Order Management, Delivery Management, Billing, and Payments. There are several adapters that interface with the external systems. Some are inbound adapters, which handle requests by invoking the business logic, including the REST API and Web UI adapters. Others are outbound adapters, which enable the business logic to access the MySQL database and invoke cloud services such as Twilio and Stripe.”
Despite having a logically modular architecture, the application is packaged as a single WAR file. The application is an example of the widely used monolithic style of software architecture, which structures a system as a single executable or deployable component. If the application were written in the Go language (Golang]), it would be a single executable. A [[Ruby or NodeJS version of the application would be a single directory hierarchy of source code. The monolithic architecture isn’t inherently bad.“
The benefits of the monolithic architecture
Benefits of the monolithic architecture
“In the early days of an application, when it is relatively small, the monolithic architecture had lots of benefits:
- Easy to make radical changes to the application — You can change the code and the database schema, build, and deploy.
- Straightforward to test — The developers wrote end-to-end tests that launched the application, invoked the REST API, and tested the UI with Selenium.
- Easy to scale — run multiple instances of the application behind a load balancer.”
“Over time, development, testing, deployment, and scaling became much more difficult.
Living in monolithic hell
…”Monolithic architecture has a huge limitation. Each sprint, the development team implemented a few more stories, which made the code base larger.
”…small development team has now become multiple Scrum teams, each of which works on a particular functional area. As a result of outgrowing its architecture, the application is in monolithic hell. Development is slow and painful. Agile development and agile deployment is impossible.“
The monolith “developer team commits their changes to a single source code repository. The path from code commit to production is long and arduous and involves manual testing. The application has become large, complex, unreliable, and difficult to maintain.”
Complexity intimidates developers
…“too complex. It’s too large for any one developer to fully understand. As a result, fixing bugs and correctly implementing new features have become difficult and time consuming. Deadlines are missed.”
…“overwhelming complexity tends to be a downward spiral. If the code base is difficult to understand, a developer won’t make changes correctly. Each change makes the code base incrementally more complex. The clean, modular architecture doesn’t reflect reality.” The app has “gradually becoming a monstrous, incomprehensible, big ball of mud.”
…“analyze the dependencies between the thousands of JARs in their multimillion lines-of-code (LOC) application.”
Development is slow
”…day-to-day development tasks slow. The large application overloads and slows down a developer’s IDE.“
”…the application takes a long time to start up.“ “The edit-build-run-test loop takes a long time, which badly impacts productivity.”
Path from commit to deployment is long and arduous
…”deploying changes into production“ (path from ”commit to deployment“) is a long and painful process.”
…“deploys updates to production once a month”
Software-as-a-Service (SaaS) applications use continuous deployment: “deploying changes to production many times a day during business hours.”
“Apparently, as of 2011, Amazon.com deployed a change into production every 11.6 seconds without ever impacting the user.
Our monolith app company “adopted agile. The engineering team is divided into squads and uses two-week sprints.”
“One problem with so many developers committing to the same code base is that the build is frequently in an unreleasable state. When the monolith developers tried to solve this problem by using feature branches, their attempt resulted in lengthy, painful code merges. Consequently, once a team completes its sprint, a long period of testing and code stabilization follows.”
”…testing takes a long time. Because the code base is so complex and the impact of a change isn’t well understood, developers and the Continuous Integration (CI) server must run the entire test suite. Some parts of the system even require manual testing. It also takes a while to diagnose and fix the cause of a test failure. As a result, it takes a couple of days to complete a testing cycle.“
Scaling is difficult
”…different application modules have conflicting resource requirements. The restaurant data, for example, is stored in a large, in-memory database, which is ideally deployed on servers with lots of memory. In contrast, the image processing module is CPU intensive and best deployed on servers with lots of CPU. Because these modules are part of the same application, the monolith must compromise on the server configuration.“
Delivering a reliable monolith is challenging
”…lack of reliability with frequent production outages.“
”…lack of testability means bugs make their way into production.“
”…application lacks fault isolation, because all modules are running within the same process. Every so often, a bug in one module — for example, a memory leak — crashes all instances of the application, one by one.“
”…developers don’t enjoy being paged in the middle of the night because of a production outage. The business people like the loss of revenue and trust even less.“
Locked into increasingly obsolete technology stack
The monolith architecture ”…forces them to use a technology stack that’s becoming increasingly obsolete.“
“Monolithic architecture makes it difficult to adopt new frameworks and programming languages. It would be extremely expensive and risky to rewrite the entire monolithic application so that it would use a new and presumably better technology.” Devs must “maintain an application written using an increasingly obsolete technology stack.”
“The Spring framework has continued to evolve while being backward compatible, so in theory the monolith might have been able to upgrade. Unfortunately, the monolith application uses versions of frameworks that are incompatible with newer versions of Spring.”