Why Companies Succeed — and Fail — With Containers
Although containers (the virtual kind) have been around awhile, it still feels like they’re brand new. Contrast that with virtual machines, which have been in common usage for 15 years now.
Will containers one day seem as mainstream as virtual machines? It’s hard to say, but there’s certainly a lot of momentum in that direction.
Red Hat has been in the container business for about five years now, which makes them an old, grizzled veteran in the industry. And in that time, they’ve learned a thing or two about enterprise containers, and what companies need to do to prepare to add them to their infrastructure.
Red Hat has helped some of the biggest companies in the world do exactly that. Those companies include Ford Motor Company, UPS, United Healthcare, and others. These are companies in regulated industries, with strict requirements for things like security.
To learn more about the biggest challenges they faced in their container transition, I spoke with Brian Gracely, Sr. Director Strategy, Open Hybrid Cloud at Red Hat. He has long experience helping these massive businesses with their transformations to a more container-centric infrastructure.
It’s Not About the Tech
Gracely says companies have more issues with the non-technical stuff than the techie bits when it comes to container integration. He pegged it at about 60% culture, people, and processes, and about 40% technical, in terms of transition difficulties. Gracely says it’s important to understand this up front.
Developers, not surprisingly, are typically ahead of the curve when it comes to integrating containers. The infrastructure teams are more hesitant in general, which, again, shouldn’t be surprising—after all, test/dev is often the first way companies go to the cloud, and containers are preferred over VMs in that environment.
The key is to get the two groups to work together when it comes to grafting containers into the infrastructure, which is much harder than just spinning them up in a separate public cloud. Those teams need to be “in sync” or companies are for a world of hurt, Gracely says.
When the driver for a container upgrade is more business-driven, things can get even stickier. Often, a CTO or CIO will understand that containers are important to help move the organization forward, but have trouble aligning the technical direction with the necessary culture shift. In that scenario, making the business case first is the way to go—stay away from the tech until stakeholders understand the bottom-line ramifications of integrating a container infrastructure.
In all of these cases, Gracely says, one of the most-asked questions is, “Where do we start?”
He often recommends starting very small in terms of scale—even as small as upgrading a single application to be containerized.
“Break it down into simple things,” Gracely says, referring to the application. For example, find out where the application breaks. What are its dependencies? Is it a good candidate to be split up into microservices? Once companies understand how that application can be transformed, they’ll have a good sense of the technical challenges they’ll face on a larger scale.
When Red Hat’s involved, it walks the client through the process, including functionality like how the app is packaged and deployed. After a thorough analysis, they’ll have an idea what app functions can be converted for containers, and what parts will be new. “We’ll say ‘this will transfer, this part will be new.’” At this point, Kubernetes usually enters the conversation, too.
Top Tips for a Smooth Transition
There’s a lot of wisdom in there to mine. Let’s look at some of the key takeaways from our conversation, and what companies thinking about adding containers, or scaling out their current containers/Kubernetes operations, can learn.
- Start with the goal in mind. If your mindset is “We need to add containers because everyone’s doing it!,” you’ll likely make some big, expensive mistakes. If containers don’t help you achieve an important business goal, table the entire project until that goal reveals itself or you can more clearly define it.
- Understand that the majority of the pain won’t be technical in nature. You need to look at how siloed your various IT teams are, for example. If they’re uber-independent and territorial, that could easily become your most significant hurdle to overcome. If the network team is suspicious of the storage team, which is barely on speaking terms with the virtualization team, you should get those relationships sorted out before you get started, because teamwork is essential for proper functioning in this new environment.
- Break the process down into bite-sized steps. Every large operational disruption looks impossibly daunting when you’re told that “You have one year to implement a complete digital transformation of all our IT!” Take a deep breath, and start chopping up big tasks into smaller tasks.
- You have help available if needed. There are plenty of vendors out there who know lots about this, having helped companies just like yours. They can provide a bit of help, or handle pretty much all of it, depending on your needs, desires, and, of course, budget.
The Water’s Fine—If You Look Before You Leap
Containers and Kubernetes are enormously useful—we’ve produced plenty of content here at ActualTech Media that demonstrates their value. But if you dive in without understanding what you want out of it, you could easily crack your skull on the bottom of the pool. And I’m betting that’s not the outcome you had in mind when you approached the water.