The Benefits of Monolith Refactoring

It seems we are just now starting to achieve the kind of resiliency that you see in science fiction movies. Sudden spike in demand?  A properly architected system will automatically scale up the components it needs in order to meet demand and then scale back down, just like in the movies. That’s because one of the greatest advantages of using the cloud is the near infinite scalability and elasticity you can achieve by using APIs and event-based architectures.

Unfortunately for those of us who have inherited legacy applications (or maybe even wrote them in the first place!), those functionalities are still in the realm of science fiction until we expend the energy to retire some technical debt and move that architecture into the cloud.  

Monolithic applications usually have a standard three tier architecture — a database tier, a business logic tier, and a presentation (web) tier.  And while the initial version of the application likely solved a specific problem, over time the application likely took on additional functionalities — usually well beyond the original scope of the project. This is a good thing because it validates that the application adds value! Unfortunately, with each new component, developers add another card to an already fragile house of cards. Developers, eager to satisfy new requirements and proud of the work they’ve done, add additional layers to the system. And they keep adding, until the application becomes a virtual labyrinth of dependencies and complexities.  Over time, no single developer actually understands the entirety of the system. There’s also a good chance that one or more key developers/architects of the system is no longer associated with the application.

Inevitably, the system will hit a catastrophic failure right after an upgrade. Some corner case of adding a new feature made it through QA and the whole system became unusable. Developers roll back the application to the previous version and begin an arduous “post mortem” process to find the root of the problem.

Such a development team will find no end of remediation, testing, QA, regression, CI/CD, and other buzzword-worthy activities to keep them busy. Yet, the root cause is the fundamental architecture of the application itself. Too big, too complex, too integrated — a single point of failure cascades throughout the system.  While the development team struggles with finding the “right” answers to their problems, their customers (internal or external) suffer with instability, uncertainty and a growing fear of change which begins a vicious cycle of code ossification and technical debt building.  All the while, the business loses agility and potentially key features due to moving to slowly.

Enter a microservices architecture. The biggest players in the industry rely on them for their maintainability and scalability.  Rather than being integrated into a single application, microservice architectures break up function or method calls, modularizing them as web-based APIs.  

This simple but powerful change allows you to make use of battle-tested techniques to scale out rather than up.  While there is always a limit on how much you can scale up (adding more memory, more CPU, more local disk, etc…), the limits on scaling out are much less constrained.  Using infrastructure like load balancers lets you distribute all of those calls to multiple servers or even containers. Suddenly getting a rash of customers adding things to their shopping carts?  In a monolithic application, your business logic server might hit the limits of CPU power, memory or cache to run the service reliably, causing the entire service to become slow or nonresponsive.  In a microservice architecture, your shopping cart service runs independently, on its own servers or containers, giving you the ability (particularly if you are using containers and a container orchestrator) to scale up new containers to meet the demand.

Updates become easier as well.  As long as your service responds with the correct information from its API call, the underlying logic can change independent of any other component of the system. This allows for smaller development teams who fully comprehend the service they develop and support. It also means that if they have a critical bug, they can fix it and deploy it without coordinating with the rest of the organization. Unlike in the monolithic model, they can update a portion of the service without fear of taking the whole thing down. Or perhaps you’ve been wanting a mobile version of your website. Coding an app to simply make API calls rather than re-coding your application for proper presentation on a mobile browser is more intuitive to mobile phone users and offers a better, more native experience. 

One other factor to consider is that programming language preferences change over time, as does the availability of programmers who understand those languages. Some of you may remember languages like COBOL which were once de rigeur, but now most view as ancient.  In a monolithic architecture, you have to either find or train new people on whatever language you chose when the project began. However, in a microservices architecture, individual service teams can choose whatever language they want, provided that it has the means of responding in a web-based API. Developers have more control over the language they use and can use the best tool for the task in a microservices architecture.

For example, we worked with a healthcare organization that had built a monolithic application; it had begun as an app to meet a specific need and quickly grew to meet new and changing customer demands. However, rapid development meant that new features and functionality were created without consideration for the monolith that the team was building. Over the long term, code became increasingly fragile, due to many interdependencies. Afraid that this would lead to instability and frequent breaks, the team began looking for an alternate approach.

Flux7 helped the firm build a Docker container, cloud-based microservices architecture that provided the healthcare organization with a homogeneous deployment framework ideal for the variation in technology stacks across its services. This approach helped streamline infrastructure needs, making it easier to port services across environments. Moving services to the AWS microservices architecture one at a time allowed the healthcare firm to achieve its goals of high availability and security while moving it away from its monolith setup to create greater agility.

You Can Read the Complete Case Study Here
 
Organizations looking to speed up application development, time to market, scalability, and maintainability should take a serious look at what it would take to break up the monolith and move to a microservices architecture.  Flux7’s IT consulting services have been helping organizations migrate to more sustainable, scalable architectures for several years. Microservice architectures coupled with the elasticity and scalability of cloud automation enable businesses to lean in to technology transformation,  taking advantage of market opportunities as they happen rather than react months or even years later.