How To ‘Refactor’ Monolithic Applications into Microservices

Chris Stetson is Chief Architect of Microservices Engineering at NGINX.

Monolithic applications are extremely common in businesses today. These applications, built using traditional IDEs, are easy to develop, test and—at least at first—to deploy and scale. There’s just one thing: The monolith will only get bigger and more complex, eventually becoming a spaghetti-code monster for organizations looking to respond quickly, reliably and efficiently to changing business needs and customer demand.

Monoliths are beneficial in certain situations and especially in the early days of app development because it’s a familiar and well-known way of developing applications. Monoliths put business logic into the core of the application, implemented by modules that define services, domain objects and events. Database and messaging components, or Web components that expose APIs or implement a user interface, surround the core and interface with the external world..

However, while developers built these applications in a modular way, they deployed them as monoliths—for example, Java applications packaged as WAR files and deployed on application servers or packaged as self-contained executable JARs, or Rails and Node.js applications packaged as a directory hierarchy.

There are many benefits to this model in the early stages of a project, but as applications grow and add feature, things start to get complex and less agile over time. And the more successful an application is, the more likely it is to become difficult to manage--comprising the original info and line after line (after line after line) of added code.

At this point, continuous delivery just isn’t possible and the monolith needs to be broken down into smaller pieces. Regression testing alone on a large monolith can take a prohibitively long time, especially if you have manual UI or pen testing requirements in your process. Indeed, it will be difficult for developers—especially those new to the application—to work on it at all, let alone truly understand it. The time it takes to fix bugs and address vulnerabilities—not to mention add new features—will increase exponentially.

All of this would be problematic in any case, but companies today need to be able to respond efficiently and effectively to new customer demands and changing market dynamics. If making a change to a critical application is the equivalent of turning around an ocean liner, your company’s ability to compete will be severely compromised.

As a result, monolithic applications can be a barrier not only to innovation but to success: Adopting new languages or technologies can be challenging and a monolithic application can be difficult to scale, mitigating the business’ ability to accommodate increased demand. . With the popularity of DevOps, microservices and containers, monoliths could also be a barrier to hiring new talent who want to work on the latest technologies.

So, what’s a company to do? Well, Amazon, eBay and Netflix are great examples of successful and very large companies deploying applications using microservice architectures. In this model, applications are split into a small set of interconnected services based on business capability. Each service implements a set of distinct features—in effect, serving as a mini-application with its own business logic, adapters and even database schema. Services can be grouped together in different ways, with the sum of their parts serving as new products.

The microservices model is “an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API,” according to Martin Fowler, an author, software developer and early proponent of the idea of microservices. “These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

The Time Is Now for Microservices

Microservices is not a new idea, but the concept is more important than ever in the current, dynamically changing business environment. Each service has a well-defined boundary and are interfaced through some sort of API. The model enforces a level of modularity that makes individual services much faster to develop, test and deploy. Your developers get the added benefit that services are much easier to understand and maintain.

The microservices model also makes it easier for teams of developers to focus on a single service rather than the entire monolithic application. Developers are not hamstrung by whatever technologies were used to build the original monolith, and they can choose the technology—and iterative timetable--that best suits the service task. Likewise, each service has its own database schema. This goes against the idea of an enterprise-wide data model, but enables developers to use the type of database that is best suited to the service’s needs (known as the polyglot persistence architecture).

If you think that the microservices model can help tame your company’s data beast, here are three things to think about to get you off (or to continue) on the right foot:

Microservices are not perfect, nor are they a cure for whatever application issues are ailing a company. However, microservices are helping companies to better align their business and IT needs—and to tame the monolithic beast.

Opinions expressed in the article above do not necessarily reflect the opinions of Data Center Knowledge and Penton.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.