Gimme Five: The State of Containers with Tim Curless

Our engineers and solution architects are always on-the-go to meet with clients at the AHEAD Executive Briefing Center or speak at industry events, so their time is precious. We caught up with Solutions Principal Tim Curless on his way to a conference with five questions on the current and future state of containers in digital transformation. Here’s his take in our series, “Gimme Five.”

1. What are the most important elements of orchestrating and deploying containers and what tools are being used most often?

The most important element is operationalization. It is a recipe for disaster to adopt a container platform in a vacuum within a single engineering team or worse, a single individual. For both success and business value to be possible, the solutions implemented should be clearly documented and augmented with service management principles. Teams should be on-boarded such that they understand the process to implement, scale, troubleshoot, and even locate running applications, particularly during service impacting events.

It’s no secret that Kubernetes has become the de facto standard in container orchestration today. The rub is what method or platform you use to deploy and operate Kubernetes. Choices abound, falling into on-premises and cloud buckets, as well as differentiated by how many additional services they provide up the stack. Some customers opt for solutions from Heptio (VMware) to adopt Kubernetes, while others prefer a more opinionated platform-centric approach such as Red Hat OpenShift or Pivotal Container Services (PKS). Still, others choose for a managed IaaS offering from a cloud provider such as AWS EKS, Azure AKS, or Google GKE, knowing that each of these providers seamlessly integrate the full armament of cloud services in their respective clouds.

2. How has the orchestration and deployment of containers changed application development?

The DevOps movement has always been about delivering better software, faster. Along with CI/CD and microservices, container orchestration has offered one of the fastest mechanisms to achieve this goal. As organizations have moved to cloud-native development and platform services, the importance of stateful infrastructure has become a thing of the past. When running a flavor of Kubernetes, there is a common Infrastructure as Code concept that helps developers spend less time worrying about infrastructure specifics. Write a Kubernetes Deployment or Stateful Set—and that will run pretty much the same on any supported Kubernetes environment.

3. How are you securing containers for orchestration, deployment, and ongoing operation?

This is a current gap for many organizations. We are certainly intrigued by companies such as SysDig and Aqua Security, and there is a clear benefit to using these tools. Protecting environments across development, build, and runtime is crucial to ensuring compliance to whichever framework applies to your business. However, it goes beyond simply selecting a good tool. We recommend the “Shift Left Security” approach and we are starting to see that more in the marketplace. Simply put, teams need to avoid leaving security out of the discussion. The security experts should be brought in from the design phases all the way to production—rather than designing and building something, failing an audit before going live, and setting yourself back six weeks for remediation.

4. What are the most common failures you see with containers?

Lately, the most common failure is someone in the organization setting up a small Kubernetes cluster and not understanding how to operationalize it within their IT organization. Container platforms help DevOps teams move more quickly, however, it is important to couch decisions in enterprise context so that you wind up with a supportable solution. For example, an organization might have a strategy for logging and monitoring, but as they implement a container orchestration platform, they don’t verify if that strategy fits in that new world. They either march toward production without a logging and monitoring strategy for the containers environment—or they choose a solution that is completely separate and wind up managing double.

One of the largest holes in Kubernetes today is the idea of multi-tenancy. The Namespace construct exists to segregate resources and permissions somewhat, however, it doesn’t create hard and fast boundaries like virtual machines do. For some organizations or groups, this is not a problem—but for larger enterprises seeking to comply with security frameworks or protect themselves from external threats, this may not be enough. Fortunately, the Kubernetes community is doing great work on this issue, and we will likely see a solution take shape in the next 12-to-18 months.

5. From your perspective, what’s the future for containers – and what should developers keep in mind?

It’s no secret that containers favor stateless applications. It is certainly possible to persist state, however, there are often interesting implications in doing so. As we start to understand and innovate with containers, there is a great opportunity for new software design patterns to emerge. Things like Istio for service mesh are examples of this. What effects might new infrastructure patterns have on existing application patterns? What new problems can we solve, particularly around state management?

When working on containers, developers should challenge the status quo. Don’t package up old applications in containers and expect them to work substantially better. In some cases, they might, but it’s always important to question why you’re taking this approach. Could you improve customer experience or supportability using containers, but also by changing a part of your architecture? These types of questions are very important to ask while adopting containers, along with refactoring or modernizing applications.