Key Takeaways from Continuous Discussions (#c9d9) Episode 76 – Container Orchestration
In a recent Continuous Discussions (#c9d9) video podcast, expert panelists discussed container orchestration . Our expert panel included: Brian Gracely, director of strategy at Red Hat; Krishnan Subramanian , industry analyst at Rishidot Research; J. Paul Reed , DevOps consultant; and, our very own Anders Wallgren and Sam Fell . During the episode, the panelists discussed challenges with containers at scale, benefits of container orchestration and more! Continue reading for their full insights.
Challenges with Containers at Scale
Per @krishnan , #containers change everything from the agent-based models into a different model altogether, now we need #monitoring ! #c9d9 pic.twitter.com/vMIusOK6h7
— CloudBees (@electriccloud) August 22, 2017
Early adopters of #containers created changes in workforce per @bgracely . People are spending their time to build their own everything #c9d9 pic.twitter.com/vmZpFu12ue
— CloudBees (@electriccloud) August 22, 2017
#Containers aren't magically going to fix your bad #application - @anders_wallgren #c9d9 #microservices pic.twitter.com/oJQRu3Cas6
— CloudBees (@electriccloud) August 22, 2017
Reed on release engineering: “One of the biggest challenges that I see from a technical and operational perspective is I think a lot of people thought ‘Oh, we can get away with the release engineering that's related to containers,’ and you can't.”
Containers won’t fix your bad applications, per Wallgren : “If you've got a crappy application that doesn't scale, containers aren't going to help you. They're not going to magically make your app be multi-tenant. They're not going to magically make your app scale horizontally with data consistency where it needs to be, etc.”
Don’t focus on trying to build all of this on your own, says Gracely : “I see people spending a lot of time trying to build their own containers when a lot of this stuff you could get natively from a cloud service, from certain software vendors. What you should focus on is building software faster, releasing it faster.”
A challenge of containers is trying to unify teams that are using different technology stacks per Fell : “You’re likely going to have teams inside of large organizations. Some of them are going to start off using Kubernetes, Amazon Container Service or Azure. How do you get a full picture of all of those different workloads and to be able to absorb those different pipelines in a way that doesn't disrupt their way of working to provide you with the regulatory oversight, the compliance?”
Subramanian on challenges with monitoring: “A problem I come across regularly when talking to the practitioners is about monitoring. Because containers change everything. It's lightweight, there are thousands of them that change from the agent-based models to a different model. The monitoring services are catching up but they aren’t quite there yet.”
Benefits of Container Orchestration
The #container orchestration platforms themselves come with built-in best practice patterns to follow, per @bgracely #kubernetes #docker pic.twitter.com/1K6GkgdRpa
— CloudBees (@electriccloud) August 22, 2017
"Containers make the easy stuff trivial and the hard stuff possible" @jpaulreed #c9d9 #containers pic.twitter.com/zV92pwW8O5
— CloudBees (@electriccloud) August 22, 2017
#Containers are a great way to lock down an immutable workload @samueldfell #c9d9 pic.twitter.com/4C4tyCWNbh
— CloudBees (@electriccloud) August 22, 2017
Containers provide better environment fidelity, explains Wallgren : “Related to the portability of containers, it does help provide better environment fidelity. You are much more likely to be building and testing in a much more similar environment than when you go into production due to the self-contained nature of the images. There's still opportunity for drift and for people to mess things up, but it does give you a lot of tools to work with to help with damages, which is which is a good thing.”
Reed on legacy vs. container applications: “It's totally reasonable to make a sarcophagus that is a container out of a legacy application. Maybe the team that did that is mostly disbanded, and you don't really know what's in it, but it is making the business money and you just want to operationalize it in an even better way. But you might only have one or two containers per machine because it is very hefty and memory intensive.”
Luckily, many container platforms come with best practices built-in, says Gracely : “In general, the platforms themselves come with a bunch of built-in patterns. You can have a conversation with a developer who says, ‘I want the application to run like this. It needs to be stateful. It's a batch job. It's a short-run job, etc.’ That concept inherently lives within the container platforms today. By default you get these operational best practices.”
Subramanian on the seamlessness of container orchestration: “What container orchestration brings about is the seamless wave which wires all the different components of the application. For example, with Kubernetes, using pods and services to wire all the different components is something that makes scale seamless that reduces some of the operational rates.”
Sound advice from Fell : “Containers are a fantastic way of looking down, making an immutable workload that you can always layer more stuff on top of.”
Containers and Your Entire Delivery Pipeline
We don't want you to change your #culture , we want consistency in the downstream part of the #software delivery pipeline @bgracely #c9d9 pic.twitter.com/zvGhtCugue
— CloudBees (@electriccloud) August 22, 2017
You can't do everything just with #container orchestration, you need overall orchestration - @anders_wallgren #c9d9 pic.twitter.com/OucNx2TQ4W
— CloudBees (@electriccloud) August 22, 2017
Having flexibility at the tooling level makes adopting #containers easier, per @jpaulreed #c9d9 pic.twitter.com/mpm19y1Kir
— CloudBees (@electriccloud) August 22, 2017
It’s not just about container orchestration, advises Wallgren : “You need overall orchestration as well. The container orchestration has taken a lot of pain out of operationalizing, and it’s awesome. But there's a lot of stuff that we have to do before we go into production.”
Make sure your infrastructure is enabling your teams, says Reed : “You want to build infrastructure that allows the people making the decisions about what they need to be able to do that. If you do that right, and you have a team that's focused on building a pipeline that supports different inputs at different levels and different outputs of different types, that's where containers work beautifully. That's really where you get the benefits of containers.”
Simple advice from Gracely : “The thing that comes out of your pipeline as an artifact should be a container. That's the premise that we start with because ultimately that's the thing that's going to go run in Kubernetes and OpenShift, etc.”
Great analogy here from Subramanian : “You need to think about application components as cattle. You need to have a complete revamp of your mind shift. If you start thinking about the application components as cattle, you cannot use your legacy monolithic architectures and still expect everything towards seamlessly.”
Fell ’s advice on making the complexity of containers disappear: “As you simplify the things that you need to deploy and you make the things that have been deployed more aware of their own context, then a lot of the knowledge and a lot of the product-ization that is required in the pipeline, the complexity will go away.”
Watch the full episode:
Want more Continuous Discussions (#c9d9)?
We hold our #c9d9 podcast every other Tuesday at 10 a.m. PT. Each episode features expert panelists talking about DevOps, Continuous Delivery, Agile and more.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.