How Smart Companies Use Containers on Their Cloud Journey: A Conversation With Ben Bertka

Ben Bertka has a message for you: use containers responsibly.

It’s hard to find a developer laptop these days that doesn’t have Docker on it. This tech beautifully solves the ubiquitous “works on my machine” problem.

For many, the question then becomes “so now what”? Where do the smartest enterprise companies go from there? How do you build on this initial success, and accelerate developer velocity?

Ben Bertka, a platform architect at Pivotal, works side-by-side with businesses like these every day. He’s helped large engineering organizations understand what’s important to boosting productivity. After all, harnessing the power of new tech is easier said than done.

We sat down with Ben recently to discuss his experiences guiding companies on their cloud-native journey. He shared a several valuable best practices used by the most successful firms.

Containers should be the automated output of development.

Gartner’s hype cycle suits the container world. After a wave of mass adoption, the market is figuring out where and when to use containers. Where is container tech working well for enterprises?

“Docker’s bread and butter is developer bootstrapping. It helps you get up and running quickly, even with complex dependencies. Every enterprise is looking at containers. They are a useful way to learn. Just make sure it doesn’t distort your view of the big picture,” says Bertka.

_{Ben Bertka}

And what is that big picture? It’s all about speed. Organizations tend to see their velocity go up when containers are an output of their development cycle, rather than a starting point.

“You’re on the right track when you have existing processes and workflows that produce containers. Ideally, containers are the result of mature continuous integration and continuous delivery. Building containers has to be a system task, not human one.”

When teams start with containers first, complexity snowballs.

“Things start innocently enough with a container. Then they add an orchestrator. Then they uncover dozens of other things you need,” Bertka notes. “These teams end up with an accidental system that doesn’t increase velocity.”

The most successful teams realize that containers by themselves aren’t a transformation accelerator.

“If you’re not happy with your software when it runs on a virtual machine, you’re still not going to be happy when it’s running in a container.”

Hand-built containers? Just say no.

When you’re operating at scale, you can’t afford artisanal builds of containers by individual teams. Bertka explains how the manual creation of containers erodes the chance for meaningful velocity improvements.

“When you use a container as a starting point, you sacrifice security, speed, and scale. Developers spend time containerizing their apps. They build images. They troubleshoot things they didn’t have to before, like how to build a Dockerfile for a Spring application. 

When IT emposes a container orchestrator, they exponentially increase the toil of the system.

“When the orchestrator requires a hand-made container, it’s dumping automatable, repetitive work to individuals. With people, there are errors. And errors pile up over time.”

Bertka even coined a ‘container haiku’ to describe this phenomenon.

Shrewd businesses also use tools that match their application downtime tolerance.

“Some apps can be down for a few hours. But for auctions and other real-time transactions, 5 minutes is a disaster. Hand-built containers can take 10 minutes to build. With higher abstraction and more automation, you can push bug fixes in less than 2 minutes.”

A less obvious area where hand-built containers are problematic: auditing and InfoSec. Human-built containers don’t offer assurances about what’s actually running in production. Bertka calls this “mystery meat.”

“Mystery meat happens even if you use container images as your deployable artifact. How do you ensure that each image meets corporate security standards? Is it IT’s job, or is it up to the developer? This leads to indecision and inaction. Systems don’t get patched. Risk goes up.”

Buildpacks, used in Cloud Foundry (and elsewhere), supports the “containers as automated output” method.

“Buildpacks are easy to audit. Vet them once, and be done with it.”

Bertka references a quote from Andrew Clay Shafer to underscore the need for automation.

“We are not telling you how to write code. That would be crazy. We are automating things every team is independently responsible for, like using Buildpacks to make your code runnable.”

Ask the right questions.

Why do you invest in IT products and services? They “abstract” away the need for you to care about something.

Which brings us to the crossroads of development teams: what’s the right abstraction for your apps? Do you need to care about container lifecycle management? Or is it better for a platform do this for you?

“Enterprises opt for something like Cloud Foundry when the container lifecycle is undifferentiated heavy lifting. The last thing you should care about is how to containerize an app. Just push your code, and have the platform do it for you,” said Bertka.

He urges teams to do self-analysis. For starters, how is your server lifecycle management going? Are you patching them reliably and quickly? If you’re not, why is it going to be different with containers? The answers are often revealing.

“If you are struggling to patch 10,000 servers today, you're going to struggle with 100,000 containers down the road. That’s the case for an industrialized platform like Cloud Foundry.”

Bertka notes that Pivotal isn’t just focused on Cloud Foundry and app-centric abstractions.

“There are some cases where enterprises will want to use serverless. We’re building Spring Cloud Function for that. A container-centric abstraction makes sense when developers need access to infrastructure primitives. That’s where Kubo fits in. We have customers using Kubo alongside Cloud Foundry. This combination helps them use the right tool for the job.”

Realize what will close the Innovation Gap.

Most companies Bertka admires seek to gain a competitive advantage with software. They want to build new revenue streams around digital experiences.

“Incumbents realize they have lost some type of advantage, in their direct market, or an adjacent one. There is are startups coming after them, or one of the big tech companies is entering their space. That’s what starts this discussion,” he explains.

Bertka talks to his customers about the “Innovation Gap” and what is going to help them close it. He explains that traditional IT improves incrementally. New projects move the needle in small chunks.  The problem is that the disruptors – the innovations – are improving at a much higher rate. 

 “There’s a realization with many of my customers that they aren’t going to catch the leaders by with infrastructure as a service, or infrastructure-as-code. A homegrown platform isn’t going to get them there either. They are closing the gap with by rapidly releasing custom software many times a day. Microservices, continuous delivery, and a DevOps culture are required. You are going to need a platform too.”

Learn from your peers.

Bertka urges enterprises to evaluate containers and other application development investments based on what others have done. He offers three recommendations.

Shrink the DevOps surface.

“Developers love the Docker experience on the laptop. The larger question is ‘what happens after you launch new code in prod, on Day 2?’ How do you handle vulnerabilities in the root file system or an app dependency? What type of downtime can you expect? How does the system handle upgrades and patches? What type of backwards compatibility is delivered?”

 “The really astute organizations understand that containers on their own widen the DevOps surface. They expand the scope of responsibility for your teams,” he says. “It’s much harder to achieve your business outcomes.”

Talk about .NET apps again.

“The great untold story of containers is that they work for Windows apps and .NET developers. When I tell customers this, their eyes light up. They can see a bright future for these apps.”

Visionaries of savvy businesses will see the advantages to running many kinds of apps, side-by-side, on a single platform.

“It’s natural for Java and .NET teams to want to use their own thing. But leaders should give their developers a single platform. Empower each team to use their favorite tooling, and they can still push code to a shared platform. You enjoy high velocity and attractive per-unit costs, because you have containerized Linux and Windows workloads running in the same place.”

The happiest group though will be your operations teams, Bertka claims. Operators have a single system to look after, with unified logging and metrics for all the organization’s modern apps. Buildpacks and immutable infrastructure tools like BOSH ease auditability and security concerns.

Be mindful of developer and operator responsibilities.

Bertka circles back to the abstraction discussion. To close the innovation gap, you have to encourage developers to move fast and take responsibility for the right things.

“When you’re migrating to microservices to improve velocity, you need the right abstraction to enable your teams. Developers can’t ask for permission or file a ticket when doing hundreds of deployments a day. Operators need automation to drive security, compliance, and resiliency.”

Want to learn more about how Cloud Foundry supports containers? This excellent whitepaper and this page have you covered. Ready to push code? Try out Pivotal Web Services.