Kubernetes IS doomed! Or is it?

 I randomly got a google news suggestion on my phone and an presentation on YouTube by Anne Currie came up with her talk entitled Kubernetes is doomed.

Now I just wanted to state that I'm not trying to be critical here or anything like that, but more that because I've been been in the IT industry for similar amount of time AND have actually worked at the largest cloud provider in the world and have some possible less academic (you could call this real-world experience), I've got a different perspective here based on my different experiences working WITH and IN large cloud providers solving companies global infrastructure and workload challenges.

Now, I'm also what you would consider a bit of technologist and have been working in the open source arena, including building/creating/implementing alot of solutions with tools and services based on opens source products, over a similar timeframe to her (~30 years) , so  I was pretty interested in where this was going (also, for some reason, I'm not _really_ a Kubernetes fan. I will post a blog on why a bit later).

Anyway, it turns our her presentation was putting up the argument that the Kubernetes scheduler doesn't really allow for optimisation of the problem of being "Greener", and by greener she means basically using renewable and even carbon zero computing resources.

A couple of times nuclear energy is also mentioned as a potential carbon neutral or zero source, as it could hold the key to solving for this

The biggest problems with nuclear (apart from  potential  fusion, thorium salt reators which haven't fully been commercially materialized as yet)

Waste: you need to store the waste of nuclear plants for "geological periods of time"- what does this mean?

Totally depends your definition, but there are estimates of up to 10,000 years or higher.

The technology and fuel could be used for nuclear weapons so you need to have military levels of security to protect it.

As a result, the economic incentives perhaps use to be there for nuclear power and greatly reduced as renewable energy now is starting be much cheaper than solar + wind WITH storage:

https://www.abc.net.au/news/2019-09-12/is-renewable-power-cheaper-than-coal-nuclear-malcolm-turnbull/11495558

I just want to a point here that the energy industry is WELL aware that alot of renewable and carbon zero energy sources are variably available AND that storage of the energy is required BUT that really a very active area of development to find efficiently and dense ënergy storage technologies, eg:

https://spectrum.ieee.org/gravity-energy-storage-will-show-its-potential-in-2021

https://newatlas.com/energy/hydrostor-compressed-air-energy-storage/

(and lets not forget SA: https://en.wikipedia.org/wiki/Hornsdale_Power_Reserve) 

So while, yes it s problem now, its really starting to look for the majority of energy won't suffer from the variability problem really for very much longer IMHO. 

So, I think a another solution suggested was hey, okay, lets just modify our workloads to use spot instances then.. So...

You CAN setup Kubernetes to use spots instances AND ALOTS of companies already d this to save money right now, here is a blog article on how to do this:

https://aws.amazon.com/getting-started/hands-on/amazon-eks-with-spot-instances/

So, we are kinda done here right ->>>?

BUT

Its always sunny and/or windy _somewhere_ on the globe. Optimise locally but think global - what if you _could_ just migrate your workloads over to a region which had green compute available - and then optimially and densly pack your resources into those regions.

We can _already _seperate_ our storage of containers from compute and do it globally to ship containers:

https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/

AND we can _also_ do this at the database level, which if pursuing a micro services architecture is possible:

https://aws.amazon.com/rds/aurora/global-database/

https://aws.amazon.com/dynamodb/global-tables/

meaning, you could shift your workload over to any region which had your desired "green" compute options 

I think a major point here is that, while in a perfect world, you just go green by selecting your cloud provider, and you're good, because they manage the compute and how it is powered.

I think I'm now thinking of a different solution here, and that is if your cloud provider _provides_ APIs tp select "green" compute, what you actually need is a "meta" scheduler which can figure this out, and redirect your workloads to precisely where the available capacity is and THEN densly pack out your computations on those green compute nodes.

This is not a new idea. Netflix had a similar problem with their big data workloads and they created a tool or meta scheduler to orchestrate and abstract their workloads away:

https://netflix.github.io/genie/

This was alot more tailored towards the big data batch space, but I can certainly see too many parallels here for an application of this idea to Kubernetes and/or compute in general to be ignored:

On top of that,  Kubernetes has the potential to make your workloads cloud provider agnostic, so what IF your current cloud provider doesn't have available green resources in one region? Ah well, just dynamically launched resources over to another provider and you'll be golden, right? Maybe..

This seems to be the gist of this blog  and tool/service from Banzai cloud:

https://banzaicloud.com/blog/multi-cloud-k8s/

Now, believe it or not, there's actually a really good incentive do a) go global and b) go mutlicloud...

a) Even regions can suffer outages and this has definitely happened before BUT ALSO, if you're designing your architecture for global deployment from the outset, you can actually save yourself alot of a pain later if you really need to go global and your business needs to scale at that level.

b) https://www.cloudindustryforum.org/content/five-reasons-why-multi-cloud-infrastructure-future-enterprise-it

The downsides of this approach are usually complexity and lack of an abstraction layer.

So, in answer to the main gist of the presentation is that Kubernetes doesn't quite have what it takes to do what you want to do from a green compute perspective - and I'm like - OK then, cool, point noted, with exceptions above.

On the flipside of this whole presentation.

The generally proposed solution then specifiy the workloads priority - and sift out urgent vs import etc, and set priorities on workloads. Well thats _exactly_ the mantra AWS has been telling people for a while and I think a bit of a falacy with Kubernetes - you should be able to  identify your workloads, segregate then, and optimise for them, It going to save you heaps in terms of money, efficiency, performance and security.

On this point, from working with several very "microservices lovin" engineers, architects and platform engineering teams, that instinctively and distinctively REALLY push hard AGAINST  this idea of workload segregations, and really push developers, engineering and architects into Lumping Everything Into One Platform. From my experience several very large companies with the LARGEST footprints in the public cloud, this idea becomes an anti pattern, and companies who have embraced the cloud and workload segregation, really do succeed where others fail in their cloud journey. 

TBC