Refactoring applications for containers and microservices

April 13, 2018

A blog post by David Linthicum, managing director, chief cloud strategy officer, Deloitte Consulting LLP

The process of containerizing an application and service-enabling it at the same time is more art than science at this point. However, certain success patterns are beginning to emerge as enterprises start to migrate legacy applications to the cloud using containers and service-orientation as the architecture.

The first success pattern quickly decides how the application is to be broken into components that will run inside of containers in a distributed environment. This means breaking the application down to its functional primitive and building it back up as component pieces to minimize the amount of code that must change.

The second success pattern builds data access as-a-service for use by the application and has all data calls go through those data services. This will decouple the data from the application components (containers) and allow you to change the data without breaking the application. Moreover, you’re putting data complexity into its own domain, which will be another container that is accessed using data-oriented microservices.

To replicate the third success pattern, splurge on testing. While many will point to the stability of containers as a way around black-box and white-box testing, the application now exists in a new architecture with new service dependencies. There could be a lot of debugging that must occur upfront, before deployment.

Modernized legacy applications must be managed differently in production than they were prior to migration. This phase is known as CloudOps, or, the operation of the application containers in the cloud.

When put into production, those charged with CloudOps should take advantage of the architecture of containers. Manage them as distributed components that function together to form the applications, but ones that can also be separately scaled. For instance, the container that manages the user interface can be replicated across servers as the demand for that container goes up when users log on in the morning. This provides a handy way for CloudOps to build auto-scaling features around the application that will expand and de-expand the use of cloud resources as needs change.

Most enterprises believe the cloud will become the new home for legacy applications. However, all legacy applications are not a good fit for the cloud, at least, not yet. Care must be given to select the right applications to make the move.

The use of containers and microservices can help make things easier. This approach forces the application developer charged with refactoring the application to think about how to best redesign the applications to become containerized and service-oriented. In essence, you’re taking a monolithic application and turning it into something that’s more complex and distributed. However, it should also be more productive, agile, and cost-effective. Those are the real objectives here.