Modern development - NearForm: The 5 (next) pillars for Kubernetes
As we know, Kubernetes is an Open Source technology for container management across hybrid cloud environments.
Initially created by Google (and subsequently open sourced and managed under the auspices of the Cloud Native Computing Foundation), it is deployable on most cloud service provider platforms
As defined on TechTarget, Kubernetes automates the deployment, scaling, maintenance, scheduling and operation of multiple application containers across clusters of nodes. Containers run on top of a common shared operating system (OS) on host machines but are isolated from each other unless a user chooses to connect them.
According to Cloudacademy, Google’s internal platform, Borg, inspired Kubernetes. It was used for managing and scheduling billions of containers to implement services.
Writing on this subject on behalf of Cloudacadem at the start of 2020, Samantha Kaylee says that, “Containers have made stateless applications more flexible for scalability and provide an unalterable experience of deployment artifact. They have drastically reduced the number of variables that were previously confronted between production systems and test systems.”
Also opinionated on Kubernetes and all round container wealth, health and stealth is David Gonzalez in his roles as Devops delivery architect with NearForm.
Five (next) Kubernetes pillars
Gonzalez says that Kubernetes is going serverless. As evidenced at AWS with Fargate (a serverless compute engine for containers that works with Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS)… the push is on for serverless because at the moment, a developer still needs to specify how many machines they need (and what size they should be), rather than being able to plug into
“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,” said Gonzalez.
Pillar number #2 for Gonzalez is a change in security, because of the lack of embedded security in Kubernetes itself.
“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,” he said.
Pillar #3 is all about an enterprise evolution.
Gonzales says that this is more of a dream than a prediction i.e. enterprise execs [corporate ‘suits’ in the C-suite] unlocking business benefit from containerisation by understanding that Kubernetes (in any kind of full-blown form) cannot happen unless business processes change.
Compliance as code
He says that Kubernetes lets developers operate in real time and supports Continuous Delivery, but – he laments – 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,” said Gonzales.
This comes back to a symptom that runs across enterprise IT: Conway’s Law i.e. modeling an IT system to mimic a current channel, instead of reinventing that channel for digital.
Build digital around the tools
Gonzales says that, going forward, Kubernetes and digital transformation will feed each other. This will mean that enterprises that 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.
“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,” he said.
Finally, Gonzales says that Kubernetes needs standardisation and a seal (or seals) of approval.
“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.”
He would 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.
Kubernetes has some growing to go still… and some of its adolescent changes will surely feel like growing pains — so this won’t all be plain sailing (Kubernetes navigation joke intended) on a fair wind.
Image: Wikipedia