KubeAcademy: Understanding Cloud Native - Highlights

VMWare KubeAcademy has great learning material on Cloud Native & Kubernatives 

Highlights from the 3-part "Understanding Cloud Native" course

"part of becoming an expert is sounding like an expert"

Mesos was an orchestration tool powering Twitter

Borg was built from scratch and it was uniquely designed for use at Google, not something that could easily be exposed to outside parties, and more importantly it was viewed as a significant competitive advantage and rarely spoken of outside of Google.

Joe Beda, Craig McLuckie, and Brendan Burns at Google set out to create a project that incorporated everything Google engineers had learned through the design and, and development of Borg and its successor, Omega.

Kubernetes traces its lineage directly from Borg. 

Compared to the massive system that is Borg, there were many improvements made to make container technologies accessible outside the walls of Google and easier for developers to consume. 

The project was officially launched as an open source project in 2014 as part of the Linux Foundation in keeping with the, the Docker container, nautical shipping theme it was named Kubernetes, which is, Greek for helmsman or captain.

The CNCF or the Cloud Native Compute Foundation was created as a governance model for both Kubernetes as well as the many open source projects spawned out of, uh, the Cloud Native movement.

Cloud native lingo & and how it's pronounced:

• Kubernetes - "koo-ber-net-eez," or "koob" as in "koob-er-net-eez." 
• etcd, the key value data store for Kubernetes - "etsy-d." 
• kubelet - "koob-let" or "cube-let"
• kubectl - "koob cuttle," "koob C-T-L," "koob control," or "cube cuttle," "cube C-T-L," or "cube control"

Cloud native applications are applications that allow you to take advantage of the unique capabilities of the cloud - Joe Beda

Continuous integration and continuous delivery fits into the cloud native story because building, testing, packaging and ultimately releasing software is much simpler with cloud native architectures

Cloud native doesn't necessarily mean running on the cloud or in the cloud. It's about taking advantage of the cloud capabilities or the unique capabilities of the cloud which includes bringing those capabilities to the on-premises data center. So cloud native is not something you buy, but something you do, it's not somewhere you deploy your application but something that you operate on as an organization.

...where we are today with Cloud Native is that we really are looking to provide the value of distributed application architectures so that we can move fast, so that we can deal with change, and so that we can get those changes into the hands of our customers quickly.

CICD stands for Continuous Integration (CI) and Continuous Deployment/Delivery (CD). 

CI is a way to package up your code to get it ready for deployment. When you think of “packaging the code up”, think of it like putting the code into a well-defined tiny little box that’s safe, secure, and has all of the requirements it needs to run successfully. 

CD is about taking that well-packaged code and sending it to some environment. That environment could be anything from VMs on-prem to the cloud to Kubernetes.

Digital transformation means that companies start to incorporate technology in every aspect of their business, and the way companies deliver new value to their customers is through modern applications that allow businesses to innovate and create new products. 

In response to digital transformation, one of the most dramatic shifts was in the application architecture. Traditionally, applications have been monolithic units that pull together all the functionality into one single deployment unit and would sit on its own dedicated hardware or virtual machine. 

Recognizing the need for more agility, applications have become more and more granular, splitting into microservices. For these smaller and smaller deployment units, the overhead of an entire machine, including the operating system, has become too big. So containers solve that problem by allowing multiple applications to run as isolated processes inside a single operating system.

While containers solved the problem of application deployment, it did create another complexity on how to manage so many applications at scale.

This is where Kubernetes comes in to help because it provides the container orchestration piece that allows these applications to run on a platform that abstract out the capabilities of a data center into an API driven fashion. 

The efficiency of the overall product development process depends on how efficient the release management process is as a whole. 

Kubernetes has emerged as the platform of choice for developers in running application.

Companies that have adopted Kubernetes:

• Tinder dating app migrated over 200 services to Kubernetes. Their Kubernetes clusters have over 1000 nodes and are running over 48,000 containers.
• Social networking platform, Reddit transitioned to Kubernetes to leverage orchestration of provisioning. They now have seven clusters running and 30% of the engineering teams use it. 
• New York Times is using Kubernetes to speed up their deployment cycles and allow their developers to push code updates without the traditional ticketing system or process.
• Mobile game app, Pokemon GO in a short space of time grew to over 500 million downloads and 20 million daily users. They did not anticipate this exponential growth and their service could not handle the traffic. With Kubernetes scaling capabilities, they were able to orchestrate their containers and focus their time on developing new game features instead of servers. 

 All interactions with Kubernetes are done via APIs