Demystifying what’s next in Kubernetes

Kubernetes is a fast-evolving toolset, with a growing capability to deliver speed and agility in how enterprises deploy, scale and manage their applications. So what’s next for this container orchestration platform? In this post, I will give an overview of where I believe Kubernetes is (or should be) heading in 2020 and beyond.

There are some fundamental changes on the way for Kubernetes, and one of them is that it’s going to go serverless . It's happening already in AWS with Fargate, the serverless compute engine for containers that work with Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). At the moment, a developer needs to specify how many machines and what size they should be. Soon there won't be that need to specify upfront: Kubernetes will go and figure it out, with resources negotiated as and when you need them. The next step is load balancing, whereby Kubernetes will manage the loads running in the hardware that the developer doesn’t control. All this represents a fundamental change in how companies use the cloud, a phase 2 where the customer can trigger an application and AWS will automatically adapt the hardware, freeing them from having to think about the underlying infrastructure.  The core benefits of serverless in terms of operational efficiency and developer experience are magnified when deployed on Kubernetes .

This is a big one. Companies who come from an on-premises mindset want tighter security controls, but that security is not available for containers. Companies who come from this tradition need to take a different approach: the security they are used is not embedded with Kubernetes. But that’s not to suggest that security controls should go out the window in the cloud-native world . The cloud-native mindset and the on-prem mindset need to meet in the middle: a verified set of images and practices to standardize the security across companies and avoid the “shamanism” that’s ramping nowadays in the corporate world  -- a set of suboptimal security practices which are in-house designed and do not resonate with engineering. Many security engineers do not understand Kubernetes and how hard it is to enforce things like, for example, the version of Java that's in use in your containers or the number of vulnerabilities (and their severity) that you are prepared to take.

This is more of a dream than a prediction, but I’d love to see enterprises realizing this: that unlocking business benefit from containerization and Kubernetes cannot happen unless their own processes change. Kubernetes lets developers operate in real-time and supports Continuous Delivery, but for organizations like banks who have a Change Advisory Board, those processes aren’t CD-friendly.

The ideal would be the achievement of an Automated Change Advisory Board, or Compliance As Code: ensuring that the code engineers are writing is compliant and secure as they go along, rather than doing last-minute checks a couple of days before the release is due to go out. This is what we call pushing security to the left, and it saves time and problems: a last-minute stressful check could become a daily routine.

The real issue is whether enterprises are open to this kind of change - very often, they're reluctant. That's why it's very valuable to get outside experts to come in and help facilitate that change: these specialists can guide the enterprise on that path and help them envision completely new ways to handle challenges.

Take online banking services as an example; even the layout of the bank statement on the screen is quite obviously a digital version of the hardcopy bankbook. When banks tried to go digital, their first instinct was to digitize what they already knew. Then true disruptors like Revolut came along and re-envisioned not just the user interface, but the whole experience of what banking can be, with much lower charges for customers.

This is actually a disease that is escalating in enterprise IT: Conway’s law, modelling an IT system to mimic the current communication channels, instead of reinventing those channels https://en.wikipedia.org/wiki/Conway%27s_law

Enterprises who want to transform can make a start by building their internal capability in modern tools like Kubernetes, while also working with outside experts on their bigger challenges. If you're conducting a digital transformation program, it's a perfect opportunity to standardize delivery pipelines, making sure that what you describe as “best practices” are actually best practices, set by recognized international experts and not a set of arbitrary rules that “just work for your company”. Can you imagine an aeroplane that does not pass any security control and does not adhere to any standard? That wouldn’t happen, right? Well, the software that the aeroplane uses might suffer from exactly this problem.

We all need to remember that Kubernetes is just a tool ; if an enterprise doesn’t fix its processes then the tool isn’t going to work for them.

One last point I’d like to make is that Kubernetes badly needs standardization.  Duplicate functionality is an irritation, bordering on a problem, in the Kubernetes ecosystem. With so many third-party software components performing the same function, how can an enterprise determine which is the best for its needs? Without consensus or a formal evaluation process, developers can be left guessing and end up guessing wrong. Kubernetes standardization isn’t yet here, but it’s something that would really benefit the community. I’d like to see some kind of corporate seal approval that marks Kubernetes components as fit-for-purpose and having achieved a certain minimum performance and functionality -- it would be a huge benefit to the open source community. Something similar happened in Java, and today Apache Foundation software or Spring Framework are well regarded as valuable and top quality. Standardization and quality marks are signs of maturity, and Kubernetes needs and deserves to go in this direction.

If you are interested in any of these topics or would like to discuss your DevOps journey , drop me a note and we can arrange a chat.  I work with enterprises to help in the execution of their software delivery architecture strategy and our team of DevOps engineers work closely with in-house teams to bring them safely to CI/CI pipeline.  We've experience across many client engagements and together with our research into best-practice methodologies, we can collaborate with a company's team in supporting their design and build.  Working with our clients on Docker and Kubernetes . Infrastructure as a Code , Secure DevOps and Metrics and Monitoring gives us the experience many companies look for when getting applications ready for cloud deployment. David Gonzalez is Devops Delivery Architect with NearForm, a Google Developer Expert in Kubernetes and author of three books on Javascript, Microservices and DevOps. David is also a part-time lecturer in Dublin on Cloud and Distributed Systems at CCT College. He is on a mission to transform companies’ IT processes and culture to allow technology to become an enabler instead of a burden.  You can connect with David on LinkedIn