Tactics for Containerizing and Moving Applications to Public Cloud

Introduction

The Hybrid Multi-Cloud architecture provides a strong value proposition for clients to optimize investments in cloud technology. Inherent in the architecture is a set of choices that can be made about where to run workloads. One key choice is whether to move a given workload to a private cloud or to a public cloud. There are some technical factors that get incorporated into this as well as a set of financial questions that are regularly faced. These were outlined in a previous article.

The drive towards leveraging containers and Kubernetes is a key direction in which the entire industry is heading, albeit in various ways on various schedules. Containerization of existing applications as opposed to fully refactoring applications is a subject of discussion and another place where guidance is required and experience is valued highly. This is also area which we have written on regularly in these articles.

Once a direction to move to public cloud have been chosen and a decision to choose a containerize or a repackage strategy is made, how to execute this modernization effort is the next question. There are a set of tactics involved in making the journey. Those tactics need to fit within an overall framework which your organization has constructed to properly adopt the cloud and pursue the benefits of a cloud native approach. Again, others have covered this well so we can go a bit deeper into one particular set of tactics.

If we’re looking strictly at applications that are to be containerized or repackaged and landed on a public cloud, what are the right tactics to achieve this? We think that there are 3 primary paths as it relates to the technology platform, all influenced by the maturity of operating model, the availability of various technical components of the architecture required to do the containerization or repackaging.

Option 1) The obvious choice is to create a public cloud container landing zone, like OpenShift, and target the results of containerization to that landing zone.

Option 2) The next interesting possibility is to establish an on-premises landing zone, and at first temporarily target that landing zone, only to follow up later with an effort to migrate the containers to the public cloud landing zone.

Option 3) The 3rd approach, which is sometimes considered, especially when there is pressure to evacuate a data center, is to move the applications to the cloud ‘as is’ and then proceed with containerization onto the public cloud container landing zone upon arrival.

These options are summarized in the following figure:

In addition to the containerization implications of the options, consideration should be given to the other elements of an application that might have to come with to make the public cloud applications work properly. This is constant in all options but is part of the overall move to cloud and containerize activity.

The rest of this article will explain each option in a bit more detail, discussing the pros and cons of each option that should be considered. You will have to plug in your specific information to determine what makes the most sense for your situation.

Establish a Baseline

First, the most reasonable way to start through this path is to establish that there is indeed a choice to be made. It is safe to say that developer and developer ecosystem costs of targeting on-premises versus public cloud are similar. However, the cost of standing up and maintaining a platform like OpenShift on-premises is a larger burden than leveraging PaaS in a public cloud setting such as OpenShift on IBM Cloud. If you already have an established on-premises OpenShift, then the incremental costs of temporarily hosting some containerized workloads is more manageable. Further, if you have existing hardware with available capacity, then on-premises Kubernetes platform becomes more cost effective until that capacity is depreciated or claimed for other purposes. This is a baseline set of costs to consider which affect option 2, when doing comparisons.

The following figure shows how IBM presents such a platform in a common way across on-premises private clouds and public cloud providers:

From this figure it is easy to see the consistency that the platform offers. This opens the door to considering some different tactics. With the hybrid multi-cloud platform concept in place, we can start to look at the options outlined earlier.

Option 1 — Single Move to Cloud

In this option, containerization activities start in the public cloud with development and continues through test and production until the application “go live” occurs when a load balancer or router redirects from the old on-premises implementation to that of the containerized version.

Pros

1. This is the simplest, fastest and most cost-effective approach. Infrastructure on-premises can likely be retired as the new platform is populated with containerized applications in the public cloud.

2. Supports a strategy to reduce data center footprint and improve application agility all in a single modernization motion.

Cons

1. Problem determination during the testing of the containerized application on public cloud will be somewhat more complex, because there will be some ambiguity around whether a problem is introduced via the move to public cloud versus the modernization to containers.

Remember, this applies only for those applications that have been deemed appropriate and feasible to move to the public cloud landing zone in the first place (See part 1 of this series). Other applications are most certainly targeted for a private cloud and are not what we are focusing on here. Those private cloud landed applications are the ones that have strong affinity and probably low latency requirements to backend systems that are also not going anywhere anytime soon.

Option 2 — Multiple Moves — Modernize in Place then Move to Cloud

This strategy involves containerizing on-premises and then having a second activity which will migrate the containerized application to a public cloud. It should be pointed out that we would still recommend running some level of Dev/Test in the public cloud even in this option, as that’s ultimately where this application is going to end up, per previous description of the class of applications we’re discussing. And, since the hybrid multi-cloud architecture provides consistency, development in public cloud and production in private cloud will not significantly affect your development activities.

Pros

1. The containerization phase allows accrual of containerization benefits such as reducing technical debt (operating system, middleware patching, older hardware) without the extra time it would take to establish and prove out a public cloud platform. Maybe you have not got all the networking and security sorted out with your public cloud provider and the Kubernetes stack. While that is expected to come soon, using this option allows rollout to proceed anyway.

2. It will be easier to do problem determination and thus reduce risk, because you have effectively got the applications running in public cloud via dev/test and on the private cloud for production. You can always compare and contrast functionality and qualities of service across the two.

3. Allows time to transform dependencies to be cloud-compatible so that by the time containerization has completed, a level of data transformation has completed as well, allowing for a unified migration from private to public.

Cons

1. The total project will be longer in time because of the interim production stopover on the private cloud.

2. Incurs the cost of standing up and maintaining a container platform like OpenShift on-premises, which is typically greater than the cost of a public cloud provided container platform. While this platform might already be in place because of a hybrid strategy, at a minimum there is a cost to provide the capacity and additional management.

3. Some application in their containerized form will be more portable than others. Simple stateless applications that talk to databases should be quite easily moved as a second step assuming the database service itself is invariant to location. Applications that more directly leverage storage might require some different setup on the private cloud landing zone than they would on public depending on the storage options available. Just be aware of the possible difference and budget for that.

Option 3 — Multiple Moves — Move to Cloud then Modernize in Place

In this option, the application is moved to a public cloud as-is and containerized later in the project timeline.

Pros

1. If you need to exit a data center on a stringent timeline, this approach will be the lowest risk approach, while still offering a path to the benefits of containerization.

2. Moving as-is will incur the cost and require the work involved with dealing with dependencies that might have to remain on-premises. This will make the second stage of getting to containers after landing on public cloud somewhat easier.

Cons

1. There is a separate virtual machine to virtual machine move project which must be funded to get the workload moved to the public cloud. This will include labor for planning, infrastructure stand-up and testing cost. DevOps processes might also need to be upgraded just to get to a virtual machine type of model. This mostly becomes throwaway work once containers have been implemented.

2. Virtualization licensing costs and target environment infrastructure costs, in addition to the labor noted above, are also required and become throw away for the most part. The tip here to make the best of this option is to not lock into long term agreements on the virtualization platform capacity in a public cloud if you know that the ultimate landing zone is indeed containers.

3. There is some risk that the move happens and then the containerization work doesn’t proceed because the project stops when the move is complete. This will keep the benefits of containerization locked away just that much longer.

Final Words

In the presence of a good hybrid multi-cloud architecture, supported by a platform that offers consistency, there are a number of strategic choices to be made. What kind of modernization is appropriate for an application is one question to consider. Then the next question is where to deploy a modernized application for production. Once a set of applications are targeted for public cloud, there are some tactics to consider so that getting to that public cloud and unlocking the value can be done in a technical viable and financially feasible way.

The information presented here allows for different applications to pursue different tactical approaches on their way to a public cloud landing zone. The obvious option is to modernize and move in a single motion. This has clear financial advantages and reduces technical complexity. There is a likelihood, however, that even if you take the high ground of using the single move to cloud option, you might find cases where the other approaches are useful. These have been presented and discussed using our experiences with large clients as inputs to this topic.

Thanks to Greg Hintermeister and John DeMarco for their thorough review of this article.