Containerizing Workloads: Why Migrate Workloads to Containers?

Containers are changing the way we deliver, run and manage software in the enterprise. With all the hype around it, everyone is now looking to put containers on their roadmap and harness their potential to deliver innovation at scale.

We are still very early in the container adoption cycle though and experimentation is still the most prevalent way to introduce them in the enterprise. I presented the topic of migrating workloads to containers at StackWorld 2016 in San Francisco last month (June 2016) and had some great discussions afterwards. A lot of people had some very interesting and foundational questions and concerns, such as:

• Are containers just a new hype for companies to spend money on?
• How do we decide which applications to migrate to containers?
• Moving to containers mean rewriting existing apps. That is a very costly proposition.

I thought this would make an interesting set of topics to my next few articles. So let’s examine them and others in this multi-part article series on Containerizing Workloads.

Wait … We have seen this movie before

There’s ample mindshare available [1] [2] on the potential benefits of adopting containers. If you step back a little, it looks a bit like a deja-vu. The pundits have us sold on VMs, client-server and three tier application architectures with similar benefits when we were moving out of the Mainframe back in the day. So how is this any different?

The following illustration may drive the point home.

IT must evolve to stay ahead of demands

Back in the day of Mainframes, we were transcending the boundaries of monoliths and were moving into more modular application types, which did happen in large part. With VMs and three tier architecture applications, we stepped into more portable infrastructure and applications that enabled quicker deployments than what mainframes offered.

Today, the struggle is to get out in front of the customers in a matter of days, get feedback and then improve upon the product quickly (Lean Startup) . It is a paradigm shift from months long release cycles and top-heavy waterfall SDLC . The following new capabilities are driving the change towards accelerated value delivery via technology:

• Containers give us a vehicle to develop and deploy software across environments consistently and at scale in minutes without waiting for weeks for infrastructure to bake first.
• Technologies like PaaS provide self service to the teams and help manage containers and orchestrate them quickly.
• Microservices based application architectures enable single-purpose services that scale easily on cloud native architectures.
• Public, private and hybrid clouds enable elastic infrastructure choices and deal with proliferation coherently.
• And finally DevOps for a more nimble and self organizing teams that deliver business value quickly.

Journey to Containers

We are seeing lot more developer led initiatives leading the way for technology adoption in enterprise. The journey to containers typically starts with some local experimentation first. Developers get a feel for what’s all out there, evaluate containers, PaaS and other related technologies and what they can do with them. Next comes a small pilot or two with containers and other enabling technologies to create the same application, features or component, but faster and more consistently across environments. This usually proves the viability of the new technology and initial internal sell that needs to happen before any serious commitment can be made. Then comes the decision of what applications to containerize and prepare them for on-boarding them to the new platform.

Do you build new application using containers or retrofit existing ones?

This question is front and center to the value proposition of container adoption. Natural way to get started on containers is to start to write a new application from scratch. While this approach is the easiest way to get started, it may not be very practical in an enterprise with a large footprint of existing applications that are business critical. Rewriting all of them is a very big financial and time commitment and may not be an attractive way to sell the value of containers to the business.

At the same time, one has to deal with the existing applications, since they are in the revenue generating business flows already. They have valuable data and functionality that will be needed for several years to come. You cannot just rip and replace them all. On top of that, they need to be continually enhanced to cater to new demands from the business. You need strategies that can help you get started quickly, show the value and continue to build on top of them.

Containers are not the silver bullet

A common trap people fall into is to think that moving to containers will solve all their problems with existing applications. This mindset will only lead you to trade one set of problems with another. I advise my customers to take a pragmatic approach and be cognizant of the following:

• Figure out your own way by weighing the options. This is not the case of when you have a hammer, every problem looks like a nail. If you are a shop that is still entrenched into heavy waterfall SDLC and/or monolithic architectures then it might be easier to take baby steps and ease into Agile based delivery and virtualization first. Jumping directly to containers, DevOps and microservices might be too big of a change initially. Use small incremental changes to build velocity and successes and use that momentum to venture into more modern technology like containers. But this will require slightly longer time horizon. If your industry is in a radical shift already, then you may not have that kind of a time at your hands and have to get more creative by creating incubation teams that can drive the technology leap towards containers more quickly.
• Not every application will be a good candidate to migrate to containers directly. It may make sense to keep it running on existing platform until an equivalent capability can be created on new technology. I’ll discuss more on figuring this out later.
• Container adoption journey can vary across a set of applications and could significantly differ across companies. It will be unique to your business circumstances.
• Given that containers are still a young technology, a lot of work is being put in right now by vendors and community to address key concerns in enterprise. We will continue to see a lot of innovation and disruption in the areas of networking, storage, security, service discovery, data and orchestration etc. There are sweet spots for containers right now that you should focus on and choose them as starting points, with an open mind to wider adoption in time as technology enables more paradigms. We are moving towards some exciting breakthroughs like Software Defined Datacenters, Network Function Virtualization or NFV, Software Defined Storage (already here in large part), Webscale Engineering of Applications and self service IT etc.
• Vendor platforms that do not support running exisitng applications in containers seriously limit your choice. Rewriting is not always an option (as we will examine in the next set of articles). Porting existing applications to containers can really accelerate the adoption as documented by Martin Fowler . It can give the momentum needed to build, run and support applications in production.

Next we will look at some useful patterns of migrating workloads to containers. They intended to give you a framework for your decisions on how to proceed when you have more than a handful of application types to modernize.

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