Containerizing Workloads: Augment with New Layers Container Adoption

Sometimes fiddling with critical business applications is not an immediate choice. Maybe because:

• There aren’t enough people around who know the details,
• There are too many touch points that will make it fragile to touch the code for even slightest of modifications,
• There is a lot of business logic in stored procedures or
• There aren’t good test harnesses that provide enough coverage for us to know that modification in one (or few) part or component doesn’t break something else.

Regardless, in this situation the best way to get started might be to “open up” the existing application by creating integration points to make its data and functionality available. Such that data can be queried and functionality can be invoked externally with proper inputs and generate desired results. This approach effectively makes the current application a backend to new microservices based APIs. Martin Fowler describes this approach as Strangler Pattern .

The most important reason to consider a strangler application over a cut-over rewrite is reduced risk. A strangler can give value steadily and the frequent releases allow you to monitor its progress more carefully. —Martin Fowler

When to apply Augment or Strangler Pattern

Makes sense when one or more of the following applies:

• There is an immediate or foreseeable need to add new functionality to existing system(s) to enable new business value.
• Application is scattered over a very large set of components, not loosely coupled, data and functionality are not cleanly separated and/or written on a platform that is not natively supported on Linux.
• Application is commercial off the shelf (COTS) and provided by a vendor that does not support containerization.
• Migration introduces new challenges to port large amounts of data and other artifacts to the container platform.
• Current application can be kept mostly intact and can serve specific business functionality when queried.
• Test harnesses are either not available and/or do not provide reasonable code coverage. This makes it hard to gauge whether new changes break existing system.

Characteristics of Augment Container Adoption

Important characteristics of Augment container adoption are:

• Existing system(s) are kept running in their native environment for as long as necessary.
• Integration points for data and functionality are created as needed. No need to massively expose everything in one shot.
• New functionality is created on modern technology, preferably on a container platform.

Benefits of Augment Container Adoption

Some key benefits of this type of container adoption are:

• No big bang. Since existing systems are generally kept intact initially, they keep serving the lines of businesses.
• Business value is delivered right from the first iteration. There is no need to defer value. Allows business to capitalize on new functionality right away.
• Reduced risk and incremental adoption of new technology.
• Allows for bite size learning of new platform to deliver value. Teams can see both legacy and containers working concurrently for a reasonable time.
• Allows time for Ops teams to learn and operationalize container platform.

As with Lift and Shift pattern, this one also paves the way to modernize existing systems, but at an incremental pace. It practically provides a clean on-ramp for organizations to take a leap, while reducing their risk.

There’s another important idea here - when designing a new application you should design it in such a way as to make it easier for it to be strangled in the future. Let’s face it, all we are doing is writing tomorrow’s legacy software today. By making it easy to be strangled in the future, you are enabling the graceful fading away of today’s work. —Martin Fowler

Extrapolating the progression to complete systems modernization, the pathway to complete container adoption might look something like this:

Augment strategy may pave the way to ultimately retire the current system and slowly replace pieces of it with the new vertical microservices. Each service is independent with its own data and configuration and represents single unit of functionality. The initial set of (micro) services might look like just passthrough for existing legacy implementation. But once we have a way to proxy the legacy behavior with the new layer, enabled with integration points, we have the latitude to modernize functionality at the back end and make front-end (micro) services more specialized and single concern. The integration layer might not be needed eventually.

Next we will look at Complete Rewrite and discuss the dynamics of the three approaches. Stay tuned.

Containerizing Workloads Series

1. Migrating Existing Workloads to Containers at Stackworld 2016
2. Containerizing Workloads: Why Migrate Workloads to Containers?
3. Containerizing Workloads: Patterns of Migrating Workloads to Containers
4. Containerizing Workloads: Augment with New Layers Container Adoption.
5. Containerizing Workloads: Adopting Containers by Completely Rewriting Applications