NearForm: What’s next for Kubernetes?

Source:-computerweekly.com

Kubernetes is a fast-evolving toolset, with a growing capability to deliver speed and agility in how enterprises deploy, scale and manage their applications.

Kubernetes is going serverless

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 works 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 up front: 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.

Security in Kubernetes must change

This is a big one. Customers who come from an on-premises mindset want tighter security controls, but that security is not available for containers. Customers who come from this tradition need to take a different approach: the security they are used to 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 standardise the security across companies and avoid the ‘shamanism’ that’s ramping up 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.

Compliance, but now ‘as code’

This is more of a dream than a prediction, but I’d love to see enterprises realising this: that unlocking business benefits from containerisation and Kubernetes cannot happen unless their own processes change. Kubernetes lets developers operate in real time and supports Continuous Delivery, but for organisations 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 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.

Kubernetes & digital transformation will feed each other

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 standardise delivery pipelines, making sure that what you describe as ‘best practices’ are actually best practices, set by recognised international experts and not a set of arbitrary rules that ‘just work for your company’. Can you imagine an airplane that does not pass any security control and does not adhere to any standard? That wouldn’t happen, right? Well, the software that the airplane 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.

Standardisation & seal of approval

One last point I’d like to make is that Kubernetes badly needs standardisation. 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 standardisation 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. Standardisation and quality marks are signs of maturity, and Kubernetes needs and deserves to go in this direction.