The best workloads for containers: All of them (really!)

I was recently asked which types of applications are best suited for containers. My response: All of them.

With few exceptions—and I mean very few exceptions—developers can use containers for every workload. The question isn’t “Should I use containers?” The question developers should be asking themselves is this: How will my workload benefit from containers?

You’ve probably heard by now that development teams use containers because they offer enormous flexibility, improved productivity, reduced downtime, better security, … the list goes on.

A recent IBM online survey of more than 200 developers, developer executives, and IT leaders revealed that containers have revolutionized developers’ output and the way they work. Top business benefits developers identify experiencing are:

  • 66 percent: Greater levels of innovation
  • 64 percent: Faster response to changes in our market
  • 61 percent: Improved employee productivity

At a time when disruption is happening in virtually every industry, and more businesses are being forced to focus on technology and innovation, these numbers should jump out. Staying relevant in today’s landscape requires businesses to innovate at higher levels and respond immediately to changes in the marketplace.  

I stand by my earlier statement that every application can benefit from containers, but the degree to which you’ll be successful (and the likelihood you’ll reap the benefits listed above) is more a matter of where your application is in its life cycle.

If you’re building a new cloud-native application, it almost goes without saying that you’re going to do that using containers, either directly with Kubernetes or indirectly with a serverless functions platform. This allows the highest productivity levels and is the most efficient way to run your application. Containers offer these benefits while recognizing and factoring for the heterogeneous environments that you need to run in.

While cloud-native applications are a no-brainer for containers and Kubernetes, it becomes a little trickier for many of the enterprise clients that we at IBM work with who have existing applications that they want to move to the cloud.  In ”How containers can bring AI and blockchain to your apps,” I wrote about how modernizing and extending your applications with containers can help you add new features to your application like blockchain and artificial intelligence.

One enterprise client in the financial sector we recently worked with in this capacity was running more than a dozen WebSphere and Java EE applications. Due to the complexity of running an operational application server environment, what tended to happen over time—and we’ve seen this with many clients—is the operations team ran one big WebSphere server and then installed different applications into that shared application server environment and ran it as a single environment.

That meant the life cycles of all those applications were essentially coupled. If you wanted to do an operating system upgrade, a WebSphere version upgrade or a Java version upgrade, the client had to coordinate that with all the teams that were running in that environment. This tends to grind the whole delivery process to a halt. It becomes very difficult to make operational changes and application changes because you can’t update your app to run new technology because you have to coordinate with your hosting environment. To upgrade their host environment, they would have had to coordinate with the other 12 apps and see if they were able to upgrade.

By modernizing those applications to containers and separating them so that each application runs in its own set of containers, the client saw both operational and development benefits. On the operational side, the client was able modernize the platform and get more efficiency and better resiliency. Developers were happy because they could now update their applications independently. The barriers to innovation and speed to market were eliminated.

Moving to containers unlocks development speed and operational efficiency in a way that no other process can accomplish. It also gives developers the flexibility to move that workload around.

And what modern developer wouldn’t want that?

This article is published as part of the IDG Contributor Network. Want to Join?

Powered by WPeMatico