Containerizing Workloads: Patterns of Migrating Workloads to Containers

In the last article of the series, I covered some of the reasons why planning to migrate all or part of existing application portfolio to containers can be instrumental in accelerating innovation cycle. I also talked about common pitfalls and try to dispel some myths. Now lets examine the journey to container migration and patterns that can help you make informed decisions.

I have seen three distinct patterns in container adoption so far. And everything else is some hybrid combination of them. They are:

• Lift and Shift: This one literally involves taking all the components of your existing application and containerize them one-by-one. And yes it is possible to repackage existing applications into set of containers with a few caveats. This is usually the most cost effective option and vendor platforms that lock you out of this choice should be frowned upon.
• Augment: We did this with mainframes back in the day, by building new middleware applications. Same concept here, except this time it is the middleware applications that will service new REST API based micro services cloud apps. This type of approach was documented by Martin Fowler in his Strangler Pattern . The new apps “augment” the existing one(s) and is built using containers. This approach allows an organizations to adopt containers at their own pace and introduce change incrementally.
• Rewrite: Current system is replaced with one or more new applications that are built on containers. This approach requires deep domain knowledge of existing applications to be present within the teams writing the new apps. It might also be the most time consuming option.

Figure 1: Patterns in Migrating Workloads to Containers

Now pay attention to this. The selection of one or more pattern for migrating to containers depends strongly on your starting point. Say if you are starting with a portfolio of all Mainframe based applications, then there is very little use of Lift and Shift pattern there. You have to look at either Augment (my favorite) or Rewrite. I will cover how to navigate through the portfolio of applications and select an appropriate path later in this series. And this topic is going to be discussed in quite detail under each of the patterns.

In reality, all three patterns will be used to onboard a portfolio of applications to containers, along with some hybrid approach.

Where are we headed?

It is important to keep an eye on the eventual goal here. That is, graduate to a more nimble application delivery paradigm that will allow us to deliver value faster, enabled by container platform. In the context of migrating to containers, we will argue that the goal looks like a combination of microservices based backends, supported by API front-ends, orchestrated by a PaaS and both can scale independently.

Figure 2: Microservices based API capability delivered via containers

• Frontend APIs: are a collection of services on the edge of system that act as external interfaces. This is what a consumer of a service will see and interact with. They are built mostly around a single business concern (for example, customer profile, transaction, orders etc.) and have one-and-only-one responsibility each. Ideally the front-end APIs need to avoid heavy implementation of business logic and limit to concerns such as user access, authorization, content based routing, request routing, API versioning, provisioning and caching etc.

One main reason for using services as components is that services are independently deployable. If you have an application that consists of a multiple libraries in a single process, a change to any single component results in having to redeploy the entire application. But if that application is decomposed into multiple services, you can expect many single service changes to only require that service to be redeployed. – Martin Fowler

• Microservices: are self contained units of services that bundle functionality, data and configuration into a single deployment unit. They are built, run and managed as atomic units and ideally have everything they need to run. They are built around business capability, rather than a system wide implementation and contain lion’s share of business logic for a given business concern. Martin Fowler outlines this vision in his momentous article on Microservices .
• Container Orchestration via PaaS: some people might consider this optional, but I would argue that this is as important as adopting containers. A well built PaaS like OpenShift helps you get from 0-60 quickly and gets out of your way. It gives you everything that you would otherwise end up creating yourself anyway. Talk about a great head start with many features out of the box that can cut down the effort on deploying, running and managing containers in a sandbox or production environment.

Lift and Shift Container Migration Pattern

This pattern is mostly about forklifting your existing application, its configurations and supporting runtimes into a set of docker containers. An application can potentially be broken down into one or more containers, depending on how it was built and the desired level of granularity within containers.

Figure 3: Lift and Shift Container Migration Pattern

When to apply Lift and Shift Pattern?

This migration pattern makes sense when one or more of the following situation applies:

• Existing application is well written with clean separation of concerns. Usually three tier web applications that have clear separation of presentation, business and data are very straight forward to containerize and deploy. Other types with such clean separation will also be straightforward.
• Built on a platform that can be run on Linux. This covers a large swath of applications, but certain platforms like COBOL, Mainframe specific languages and tools and Windows-based applications are currently not supported by container technology. So if your starting point is a platform that is not supported on Linux (usually the other way around), then you may not be able to use this pattern. Note that .NET has become a supported platform on Red Hat Linux recently . So the choices here are abundant.
• Team has full access to the source code, configurations, data sources and external integrations.

What does Lift and Shift Pattern looks like?

Important characteristics of this type of migrations are:

• Data and external integrations are generally kept intact. For example, databases continue to run where they are, messaging is kept intact and other system interface such as mass storage are also not changed.
• Application runtimes, along with its configurations are deployed on containers.

Benefits of Lift and Shift Pattern

Tangible benefits from Lift and Shift include:

• A time boxed sprinted effort that yields tangible results quickly. It is perhaps the fastest way to achieve container adoption.
• At the end of the first iteration, workloads can be run in production. In fact, I recommend that the applications be deployed into production as soon as possible. This starts the other important container adoption processes necessary to achieve maturity such as operational readiness, monitoring, support readiness, learning from the entire experience of full cycle delivery to production etc.

Containerizing individual components of an application using this pattern seems like a great goal, but it is just the beginning. As I mentioned earlier that we are marching towards a more nimble delivery capability around APIs and micro services via containers. A complete journey using Lift and Shift pattern might look something like this:

Figure 4: Complete Lift and Shift Container Migration Pattern

The first order of business is to get up and running in containers, by porting (or lifting) the applications into one or more container images, tie off configurations and deploy using container orchestration PaaS. We call it “Scale out with containers”. Getting to this step could be a matter of few iterations and Agile Sprints. Once you are stable, it is usually time to hit production and let it run for some time.

Moving to complete Microservices and APIs on containers will take focused effort, reduction in technical debt, a lot of refactoring and sometimes creating new code to compliment existing one. It is wise to identify vertical business aligned functionality and then implement each of them as atomic units. That is, all the way from front-end to backend micro services and back. If this topic is of interest, I will write about it in another article, so make sure to let my know either by leaving a comment here or reaching out to me via twitter (@zeebluejay).

Next we will look at Augment with New Layers pattern. 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