Friday, June 05, 2020 / By: Bob Healey
ven for those who understand Kubernetes, it is difficult to explain it to their friends and associates who are not in the code, programming, or cloud-native world.
By definition, Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management. It was originally designed by Google and is now maintained by the Cloud Native Computing Foundation.
Ok, but what does that mean? You could say Kubernetes is a technology that makes it easier for a website or mobile app to operate better and more efficiently when there is a spike in volume or activity.
How does it do that? Now we’re getting “techy” again but Kubernetes is a Cloud-Native technology that allows you to manage something called containers and containers allow you to have more instances of the application and keep them isolated from the others which keeps the corruption of one container from affecting another while giving you more horsepower when it is needed.
Think about it this way, and I write this with all sensitivity and respect for the tragic and ongoing loss of life during the COVID-19 pandemic but this is a real-life tangible analogy that will help us explain Kubernetes to those, not on the DevOps team.
The #1 talking point from leaders early in the pandemic was FLATTEN THE CURVE! The shutdown was not to prevent people from contracting the virus rather it was to spread out the time frame in which many people contracted the virus so as to not overwhelm the healthcare systems all at once.
Why would they do that? Because if a health system has the capacity to properly care for 100 people and BAM 1,000 people need care and, worse, all of them came in at the same time, the collapse would be catastrophic and the impact would be exponentially worse.
Begs the question……..why can a system only handle 100 people vs 1,000? That is an easy answer……. because it is too damn expensive to staff resources every day for a once in a century pandemic, it is not sustainable. Same with application architecture, companies could have resources available for any possible spike in traffic but it is too costly to do so.
Whenever you hear a leader say there is no possible way anybody could have predicted or been prepared for that type of traffic spike what they are really saying is it is too damn expensive to be prepared for a very obvious thing that we all could have predicted. Make no mistake about it!
Imagine the concept of Kubernetes in the healthcare system, and why we had to flatten the curve. Health systems can accommodate 100 people but just imagine if, instantly, the number of ICU units could replicate themselves in an isolated container where they could be independent but work together where a broken ventilator or worse a nurse contracting the virus would have no impact on the others.
These ICU units could replicate vertically, meaning in the same hospital, and even better horizontally where they could be in several locations instantly making them easier patients by having more locations and less traffic for people to get to them. No military hospitals on the bay three weeks later, no pop-up clinics at convention centers. Also, imagine all non-critical procedural equipment instantly being available for COVID-19 treatment.
No more trying to bring in ventilators from Oregon or the New England Patriots flying to China for masks, no more converting shutter manufacturing plants into face shield making operations…………no more mandatory shutdown!
Obviously this is not realistic nor is it doable, I get it. BUT now imaging the concept applied to the unemployment systems that states use. How many issues did they have because the system had no ability to flatten the curve? What if they could absorb it? Imagine if they had the ability to replicate applications and scale the resources instantly, and only have to pay when they did so.
Kubernetes allows you to absorb the curve with no service degradation vs having to flatten the curve with a lack of access to your system.
Now, imagine having to explain COBOL to someone after you explain Kubernetes!