A Year of Kubernetes: What’s Beyond the Horizon?
In part one of this two-part series on what has transpired in the cloud-native community—and specifically the Kubernetes ecosystem in the past year—we discussed the emergence of Kubernetes and cloud-native as the next evolutions of IT. We also discussed some of the challenges of onboarding these technologies. In this article, we try to understand why the bench is short, what the future holds and where security fits into all of this.
Short Bench, or, the Emergence of the Full-Stack Engineer
There’s this old joke about a company looking for a person with 10 years of experience in subject X when the subject itself has existed for only three years. This is about the state of the cloud-native job market—everybody wants experienced professionals to lead them to the promised land, but how can you be a seasoned professional when the tech is only several months old and keeps changing under your feet? This is an issue not only for organizations trying to recruit teams but also for vendors trying to recruit technical staff and sales teams to actually cover the emerging field of cloud-native.
The most popular topic that came up in many discussions I had at KubeCon was the steep learning curve to get started with Kubernetes or the various ecosystem plugins. Most people stepping into these cloud-native engineer positions usually come from an IT background, but there are many developers also that have started moving down the stack as part of this technology shift.
For many developers, the world of networking, routing, storage, load balancing and many other terms introduced by these technologies is foreign and unfamiliar. On the other side of the curve, we have IT admins who are used to managing virtualization systems and physical and virtual network devices. They usually are not familiar with coding practices, release cycles and the CI\CD pipeline in general. To quote one of the discussions I had at the latest KubeCon with one such IT person: “Just as I thought I got a handle on containers being the ‘new’ VMs, they throw Istio at me.”
Of course, we already have many DevOps-oriented engineers out there, but the demand is high and the supply scarce. I think that the definition of the cloud-native IT team is not yet set in stone. However, to be part of it, not only do you need some sort of full-stack understanding of how applications are built and work, but also an understanding of how hybrid networks and data centers are built, managed and secured.
Cloud-native is a whole new frontier awaiting explorers, holding many new opportunities but at a price of a steep learning curve and a long journey outside of your comfort zone—regardless of which side of the rails you are coming from.
Kubernetes Security is Still Maturing
There’s a long-told tale that security baked into products as an afterthought is the core of all evil. Security professionals encounter this all the time—various systems getting patch after patch due to the fact that many security controls just weren’t part of the initial design, whether due to lack of security awareness or just the “let’s make sure it works first before we invest in security controls” approach. Kubernetes is not much different in that regard. As with any project, you first prioritize resources to make things work faster and at scale. For example, RBAC and Kubelet TLS bootstrap were introduced only in recent versions and API read-only port was changed to disabled by default only a few versions ago.
Kubernetes has a plugin-oriented architecture delegating different duties to external services.
Network security is one of those duties which de facto means that Kubernetes doesn’t really have any built-in network security controls on its own. On top of that, the capabilities provided by the external services are very container-oriented. It’s not your good ol’ gateway firewall or even your cloud deployment’s security groups.
The main concern of security and network admins is the additional overhead that these new network security controls for Kubernetes introduce—especially when they didn’t have a say in choosing these controls but are reliant on the architecture choices that in many cases were done by other people who are less concerned about security.
The fragmentation of security controls creates an inconsistent behavior across architectures—and, more importantly, an inconsistent security posture. As most organizations own both hybrid environments and Kubernetes-based deployments, they actually need to configure security policies across environments (VM to pod, pod to VM) and not only per each environment (VM to VM, pod to pod). In that respect, we see many security admins asking for greater visibility and control across these architectures. In many cases we see that on one hand, organizations can’t extend their existing legacy security controls to Kubernetes, while on the other hand, Kubernetes or container-oriented solutions do not extend to the hybrid or virtual world. We see organizations looking for a hybrid platform to cover all of their assets—legacy, hybrid or containers with one common policy and minimal overhead.
Put a Bow on It
In trying to predict where this space will be five years from now, one thing is clear: There will have to be some point of convergence for many of the underlying technologies included under the CNCF umbrella that are strongly tied to Kubernetes. Just take a look at the current landscape; it’s a mess.
At a certain point the excitement around Kubernetes will cool down and some companies will disappear while others will get bought out and community leaders will move on to the next IT fad. The different runtimes, network and storage plugins will converge to a few well-defined sets provided by managed solutions providers and open source platforms.
The same goes for the security ecosystem around containers and Kubernetes. As containers become first-class citizens in our data centers, no longer will they be managed by dedicated solutions but instead will converge into the existing security platforms. We already see this with vulnerability management systems and have started seeing this with network security and CI\CD systems where organizations are looking for holistic solutions and not pinpointed ones just for containers.
One thing is certain: Containers, Kubernetes and the whole cloud-native movement are revolutionizing the way we build applications and are driving our businesses rapidly forward. This is no longer a marketing slogan but a reality adopted all over the world at scale.
There still remains a lot of work to be done to turn some of the dreams into a reality, and with Istio and serverless, the next iteration in the evolution of computing is looming just around the corner.