4 container adoption patterns: What you need to know

Containers have quickly won a key role in enterprise IT plans for a practical reason: They help organizations gain speed. And for digital businesses, speed equals revenue. But how are your peers using containers, what’s the best adoption pattern for your company – and what speed bumps should you avoid?

At this time of digital transformation, it’s crystal clear why today’s businesses desire speed. When a rival uses technology to make an unexpected move, or makes a big acquisition, you must react quickly. For example, the recent Amazon acquisition of Whole Foods demands fast action from supermarket competitors. To achieve that kind of business speed, IT leaders want to flip the 80/20 paradigm, where IT traditionally spent 80 percent of its budget on maintenance and 20 percent on innovation. CIOs seek to allocate more budget to help the business be agile and nimble. 

[ Want more background on using containers to aid agile dev teams? See our related article, DevOps success: A new team model emerges. ]

Containers, DevOps, and microservices all fit together to help CIOs achieve that goal of agility. In short, containers corral applications in a neat package, isolated from the host system on which they run. Developers can easily move them around during experimentation, which is a fundamental part of DevOps. Containers also prove helpful as you move quickly from development to production environments. (For more, see this background guide on containers.)  Of course, technology alone doesn’t solve the problem. CIOs must also manage the cultural challenges that arise when you start working in cross-functional DevOps groups and rethinking boundaries and process. 

But CIOs can learn plenty from their peers’ work on both fronts of culture and technology. On the technology side, when working in the trenches with companies adopting containers, you see many of the same goals and hurdles. Let’s examine the four typical ways companies adopt containers – and what you should know about each pattern.

How companies tap into containers

First, understand that there’s not one perfect container adoption path for your company. You may begin using containers on one path, then hop across to another later. Also, different groups inside a company often use containers in different ways - so it’s common to see multiple usage patterns at once. 

Pattern 1. Container Platform  

Many companies begin using containers and then realize they need a platform. Often, a particular group, say a DevOps group, is working hard to drive change. This group needs an agile technology platform in order to experiment and deploy quickly, so they start working with containers. They get IT leadership on board, convincing them that containers are here to stay. The key question becomes, what platform will we use to deploy and manage the containers? While there are plenty of open source container tools to experiment with, an enterprise-grade container platform typically comprises dozens of open source projects, including Kubernetes orchestration, security, networking, management, build automation and continuous integration and deployment capabilities out of the box. In sum, a platform addresses management, governance, and security concerns.

Watch out for:

• Identify low hanging fruit. Web servers and app servers are often easiest to deploy as containerized workloads to get a quick win. Then you can move on to databases and stateful systems. Pay close attention to integration with existing build and deployment tools and processes to demonstrate progress against status quo.
• Prioritize container security. Because containers contain system specific libraries and dependencies, they’re more prone to be affected by newly discovered security vulnerabilities.  Trusted registries, image scanning, and management tools can help identify and patch container images automatically. (For more background, see this Red Hat whitepaper: “10 layers of container security.”)

Pattern 2. Cloud-native apps

Some companies seek containers mostly to house cloud-native apps being created by application development teams, including new work and revamps of existing apps. These apps are often microservices-based. The goal is to break up an app into its underlying services, so teams can update the apps independently. Flexible APIs also typically fit in here. You want apps that can engage with other apps, systems, and data - both yours and your customers’ and partners’ – using a secure, well-understood set of APIs. You also need to integrate with existing systems. 

Containers, in concert with microservices and APIs, make it easier for the dev teams to develop, collaborate, and deploy cloud-native apps.

Watch out for:

• Consider new runtimes -- Monolithic app servers that you’ve deployed in the past will not likely run your next-gen apps in the future, as event-driven, reactive, and serverless technologies emerge. A container platform needs to supports a broad range of existing and cloud-native runtimes and frameworks.
• Don’t forget about developer tools -- While runtimes are evolving, new cloud-based developer tools promise  to eliminate the complexity of creating and managing different work environments, using self-learning technologies and automated workflows, to help developers build higher-quality code faster.

Pattern 3. Hybrid cloud

In this commonly used pattern, an operations team, or another group managing a large group of apps, has seen the advantages of public cloud. Elasticity, speed, and performance have strong appeal. But the group needs to run some apps in existing on-premises environments - perhaps for historical, regulatory, or security reasons. The group also typically grapples with existing bare metal server or virtualized environments, and perhaps some existing private clouds. They may want more flexible storage options as well. For an IT group thinking about all this, cloud management becomes crucial. 

The key questions: How do I get an abstraction level, a platform that runs well in all these environments and lets the operations team manage apps seamlessly? And how do I let developers deploy to one place, which can hide a variety of underlying infrastructures? That convenience is important to speed. 

Watch out for:

• Culture change backlash. As a banking CIO leading a significant transformation recently noted to me, none of this works unless people get on board with changes in mindset and behavior. IT leaders driving cultural change need support from both the C-suite and evangelists in the smaller teams.
• Inertia. The easiest thing to do is just do nothing. Some IT leaders will say “There’s so much change happening around me, I’ll just wait.” While you may be apprehensive to start the journey, or take a new hybrid cloud route, the business demand for speed will not go away.

Pattern 4. Business innovation

In this pattern, a company starts up a small team to solve a specific business problem - say a mobile app to improve customer experience. The feeling is, “the way we’ve been working we’re not working quickly enough.” We need more modern practices. We need people to be change agents.” The company needs the group to quickly create, iterate, and make sure that IT can later scale out the solution. These groups often get new, enabling technologies and permission to run by different rules.

Watch out for:

• Debate around skills. Expect to hear questions such as, “Do our IT team members have the skills to keep up with the group’s new technologies? Do we need a bunch of new hires? What about our investments in existing skills?” You will likely need a mix of both new hires and cross-training. Consider bringing an outside expert to assess the situation and put together a plan to get you where you want to be. (For more advice on team skills, see this related article: Ellucian CIO: Cloud era demands new IT skillset.)
• Allow people to experiment and fail fast - or watch talent go elsewhere. When companies don’t let IT teams experiment and fail fast, they struggle to attract talent. For example, take Macquarie Bank, based in Australia. Their CIO needs to recruit talent to build attention-grabbing customer experiences. One tactic: Within the first week of working at Macquarie, every new developer gets to push one change live. The recruiting message of the Facebooks of the world is “Come work on a feature used by millions.” The Macquarie CIO attracts people with the promise of experimentation and speed. (For more, see this case study on Red Hat’s work with Macquarie Bank.)

Parting advice 

No two digital transformations look alike. No two DevOps journeys will be the same. And as these four container adoption patterns show, you don’t have to use containers exactly like the company down the street, or like your rival. But you can learn from them. Consider these parting tips for IT leaders trying to move faster, using containers: 

• Established companies will face greater challenges than cloud natives. Netflix has pioneered with fast-moving dev teams, but Netflix had no existing infrastructure to throw out. Some CIOs still have COBOL apps to support. Grappling with both old and new technologies, and making tradeoffs, is normal. Make sure the C-suite understands that – and stop constantly comparing yourself to Netflix in this regard.
• Don’t let scale concerns stop you in your tracks. Only a few Facebooks exist in the world, scale-wise. You don’t need all the resources or skills of Facebook in order to make significant business change. Start experiments with smaller groups. As you succeed and become more comfortable, expand out in terms of technology and talent.
• Coach people on the IT team to understand they’re not alone. Encourage people on your team to engage with their peers outside the company, to talk about technology and culture challenges.

Do you have additional advice for IT leaders pursuing speed using containers and/or DevOps? We’d love to hear from you in the comments section of this article.