NeuVector on Containers
NeuVector on Containers
This take on containers and orchestration considers their use in CI/CD workflows, their impacts on performance, and how to handle security concerns.
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
Thanks to Fei Huang, CEO at NeuVector for sharing his thoughts on the state of orchestration and the deployment of containers for DZone’s upcoming Containers Research Guide, which will be published in early-August.
Q: How is your company involved in the orchestration and deployment of containers?
A: NeuVector is a containerized security solution, so our customers are designing us into their pipeline using orchestration and deployment platforms. It’s a natural fit with their deployment model, unlike agent-based or traditional security tools. The NeuVector technology integrates with the orchestration and deployment tools to automatically discover services and build a security policy.
Q: What do you see as the most important elements of orchestrating and deploying containers?
A: On top of the container engine, I think several major container elements are storage, network, security, and management. All these are facing new challenges and rapid evolution. Data persistence, network visibility, and security with overlays, workload, and release management are all good examples of this. That’s why we need new technologies and processes to address these challenges.
Q: Which programming languages, frameworks, and tools do you, or your company use, to orchestrate and deploy containers?
Q: How has the orchestration and deployment of containers changed application development?
A: Containers really help to improve the quality and speed of CI/CD workflows. For example, we use containers to deliver our build toolchain instantly, to run automation tests with excellent isolation, and to update or deploy automatically. Regardless of whether it’s on-premise or in the cloud, it is the key technology that enables our application development to be fully automated with scale and flexibility.
Q: What kind of security techniques and tools do you find most effective for orchestrating and deploying containers?
A: It’s important to leverage best practices for securing containers before production, such as image scanning, host security, and access controls. But integrating run-time security is also critical because hackers will always find a way around static controls. In a run-time environment, technologies like auto-discovery, behavioral learning, and security policy white-listing are all now possible with containers, and they are highly accurate and scalable.
Q: What are some real-world problems being solved by the orchestration and deployment of containers?
A: It’s all about the speed, scale, and costs of developing and running applications. We have a customer who decided to use containers directly on physical servers, saving a lot of money compared to VMs in the cloud. We also see customers starting to use containers on different public clouds because now they can instantly launch, migrate, and scale applications based on granular cost-benefit analysis.
Q: What are the most common issues you see affecting the orchestration and deployment of containers?
A: The rapid evolution of container platform components such as orchestration, storage, networking, and system services (load balancing, name services etc.) is making the entire stack a moving target, which makes it difficult to have a stable application or service on top of them. When they do go into production, security plus visibility are big concerns because of increased layers of virtualization – especially networking.
Q: Do you have any concerns regarding the current state of orchestrating and deploying containers?
A: Once in place, a container-based CI/CD pipeline is incredibly powerful. But getting there is not easy. Orchestration systems are not easy to setup and automate quite yet, even for the most popular ones like Kubernetes. Security is an unknown frontier. I’m hoping the ecosystem of container technology companies will work together to make it easier for the average enterprise to adopt containers, securely.
Q: What’s the future for containers from your point of view - where do the greatest opportunities lie?
A: Container security should be a transparent layer of the underlying container services infrastructure so that developers don’t need to worry about it. It’s why we built technology that readily plugs into container platforms and network overlays, and it gets easier and more powerful as they evolve to add more built-in services such as service discovery and secrets management. The declarative nature of containers will make securely spinning up containers in the future as easy as spinning up a cloud server instance today.
Q: What do developers need to keep in mind when working on orchestrating and deploying containers?
A: A container is not just a packaging tool. Developing containerized applications requires developers be aware of how the application will handle run-time situations in a micro-service way. For example, to address scaling up or down, hitting resource limits, migrating or updating components, persisting data, communicating with other containers, and so on. When developers or DevOps people address these issues up front it makes it easier to secure the applications in production.
Q: What have I failed to ask you that you think we need to consider with regards to containers?
A: Specific to container security, I want to emphasize that it’s not one-size fits all. The complexity of virtualized environments requires there to be multiple layers of security in place. There are many best practices for preparing a secure environment for containers, but the real challenge is getting the security and visibility needed when containers are running in production and there are suspicious activities happening in real-time. That’s where we’re focused on developing the NeuVector security technology.
Opinions expressed by DZone contributors are their own.