Twistlock’s POV on the State of Containers

Thanks to John Morello, CTO at Twistlock for sharing his thoughts on the current state of orchestration and deployment of containers.

Q: How is your company involved in the orchestration and deployment of containers?

As a tool purpose-built for containers, Twistlock itself runs as a container, and our teams leverage cloud-native tooling and development techniques to build and deploy Twistlock.

Twistlock provides a complete security solution for container environments - allowing teams constant, real-time, multi-environment protection.

Twistlock’s features include environment checks, policy enforcement, and role-based access control. We can stop, start, analyze and understand what any actor is doing with the container engine, which enables us to do a lot of the heavy lifting of compliance. Another thing we do is plug into all the notifications and all the operating system capabilities that enable one process or anything at the OS level to understand what happens inside the OS. If we see anything, then we can basically alter that and block it.

Q: What do you see as the most important elements of orchestrating and deploying containers?

Automation and security are two of the most important aspects to consider and each helps the other. Organizations won’t really see the value of containers until they’re able to automate their deployment and operation. At the same time, this automation means security must be built into the deployment process because there will be few opportunities for manual intervention before an app is live. Containers and the whole concept of CI/CD mean software can be iterated on much more rapidly but this also means that security must be much more native to the build and deployment processes.

Q: Which programming languages, frameworks, and tools do you, or your company use, to orchestrate and deploy containers?

We leverage GKE (the Google Cloud Platform Container Engine, built atop Kubernetes) for our deployment and production needs. Twistlock’s platform is built in Go, to allow for performance at scale.

Q: How has the orchestration and deployment of containers changed application development?

Application development has become much more rapid thanks to containers. Because containers are reliant upon pre-built layers, and only contain the absolutely necessary functions - they’re easier to assemble and require less knowledge of OS dependencies and quirks. Because containers are portable across environments, teams can easily re-build or transport their applications from dev to staging to production — or from bare metal to public cloud. These changes allow development teams to focus on software innovation rather than compatibility issues — and reduces friction in the SDLC.

Q: What kind of security techniques and tools do you find most effective for orchestrating and deploying containers?

Security in the world of containers needs to be end-to-end; just as portable as the containers themselves. This means you need tools that scan for vulnerabilities, malware or other risks across your entire environment — from images in registry or on a workstation, through the CI pipeline, all that way to production servers. Additionally, tools that provide active threat defense — tailored to the ephemeral deployments of container clusters — must be utilized to defend applications while running, and prevent attacks.

Q: What are some real-world problems being solved by the orchestration and deployment of containers?

Containers are an enabling technology that makes software development and deployment faster and more efficient. So, it’s less about containers themselves solving problems and more about the apps that they enable organizations to build and run, and those organizations span every industry and geography. We have financial services customers building apps in containers to track credit scores and provide financial recommendations to their clients. We have government organizations using containerized apps to model the effects of weapons and identify ways to protect soldiers. We have health care companies using containers to process and visualize radiology data. Because containers are such a powerful tool and complement modern development practices so well, they’re often ‘hiding in plain sight’ and part of apps and services you’re already familiar with.

Q: What are the most common issues you see affecting the orchestration and deployment of containers?

Many organizations are pushing ahead with containers as a bit of a magic bullet — a new technology that will make application development, deployment and ongoing management seamless. The reality is that while containers vastly streamline this process — the same operational and security concerns still apply. Understanding how to transition legacy requirements around process and security to a container workflow — without negating the speed increase containers bring — is still a challenge for many teams.

Q: Do you have any concerns regarding the current state of orchestrating and deploying containers?

We’ve heard concerns regarding DevOps and IT security teams needing better visibility into containers, and have heard that people don’t know what security policies for today’s container-based technology. Containers use a different layer of abstraction than what most IT professionals are used to. Organizations often have security policies in place, but things can get lost in translation when trying to re-format their needs for a container-based pipeline.

Q: What’s the future for containers from your point of view — where do the greatest opportunities lie?

When thinking about the future of containers, I believe that cloud-native development will become more commonplace. Today, developers increasingly write code in a “cloud native” fashion, which usually translates into continuous delivery, continuous integration, microservices and the use of containers. This year, we will not only see cloud-native development become a commonplace practice, but I also wager that more than 50% of the new applications developed in 2017 will be “Cloud Native” apps.

So the opportunity, then, lies in enterprise software companies being able to speed up and streamline development via containers’ usage. Not only can organizations using containers accelerate their dev processes, they can actually improve their outcomes, by making them more secure and scalable. As the Andreessen quote goes, ‘software is eating the world’ and containers are the table it's sitting at for dinner.

Q: What do developers need to keep in mind when working on orchestrating and deploying containers?

I think the biggest thing for developers to remember is that containers haven’t removed the security threats of traditional virtualization — they’ve just changed the way these threats appear — and the routes of attack. Containers can be more secure than traditional virtual machines — and can reach this state with less developer input — but security can’t be forgotten or ignored.

Q: What have I failed to ask you that you think we need to consider with regards to containers?

In those fairly rare cases where organizations tried containers but didn’t move forward with them, why didn’t they move forward? Do organizations recognize the criticality of organizational change as part of really getting the value from a cloud-native approach? CI/CD is less about the build and orchestration software you’re using and more about the mindset shift of automating everything and tearing down the traditional friction points in deployment. Finally, how quickly do organizations expect to make containers the default choice for the way the build and run apps? We often say that containers today are where virtualization was in 2002 and cloud was in 2010. Just as today, most people would think it strange if you said you were going to buy a new physical server and run your app on bare metal, one day containers will seem just as much a logical assumption, but the question is whether that is six months or three years from now.