I’ve noticed a common theme among the developers I talk with regardless of where I meet them or what platform they are working on. Just about every developer I talk with is working to split up large, monolithic business applications. This is an area that has gotten a lot of focus, so it doesn’t surprise me to find so many people so focused on modernizing their applications in this way. I am surprised by just how pervasive this work is across industries. Let’s look at why this is happening and discuss some strategies and technologies for doing this work most effectively.
If you’ve ever worked as a developer in a professional capacity, you probably don’t have to read this section because you’ve suffered at one time or another with having to work with some nasty monolithic code. Monolithic applications implement both the user interface and the data access layer in one place. As a result, they are typically lengthy programs where the path through the code is about as clear as mud. They often date back to a simpler time in computing when doing everything in one place was ideal. Perhaps they were written without a great deal of forethought spent on easing code maintenance years afterwards.
There are several reasons why refactoring your code can warrant the investment of time and money. Among those reasons are:
- Simpler code is easier to add to, fix, and test, so changes can be made more quickly and with less risk. It also carries a lower barrier to entry for a new developer.
- Code written to do only one thing can leverage the best (and latest) programming languages built for that one purpose.
- Breaking a monolith apart allows you to position each piece on the best platform whether on-premise or in the cloud.
It stands to reason that smaller applications are easier to manage because there is less code to read and understand. Smaller apps also lend themselves to easier reviews because of their lower complexity, which reduces the end-to-end turnaround time for changes. Changes made with a good understanding of the affected code and with thorough reviews generally yield better quality, and both of these criteria are met when simplifying applications.
Separate pieces of code can also be easily modified in parallel without having to merge code streams between developers. Add the latest DevOps techniques with continuous integrity and delivery, turn the crank, and you’re now able to update your application at the speed of each development team. No longer are you tied to delivering a huge application all at once.
Decomposing a monolith allows you to tailor fit specific pieces with the programming language that best suits each purpose. For example, COBOL is a great business-oriented programming language for working with records and generating reports, but it wasn’t designed for making REST calls. You might want to use something like Python for calling services and computing the final results from each call. This is essentially decomposing the larger application into individual reusable services.
The services an application takes advantage of can reside anywhere — on-premise or in the cloud — so why not pick and choose the best technology for the task when building these services? With modern business applications branching out into multiple clouds, it makes sense to tailor fit for the use case.
Now that we’ve explored some of the justifications for working to refactor large, complex business applications into smaller pieces, we’ve run smack into our first challenge: how to get started. Before we talk about best practices for refactoring, we should acknowledge what monoliths are good at. I’ll discuss this through the lens of refactoring in the next installment of Escape from Monolith-adonia.