Management in the application-centric cloud

opinion
Jul 29, 20154 mins

Kubernetes is the management system of choice for containers and microservices

In June, the Linux Foundation started a project based on Kubernetes, which was developed by Google to manage its complex environment. Companies like Google, eBay, Jive, Facebook, and Lithium have moved to this environment.

The application-centric cloud is a complete change from the approach of having a single platform deal with an application, and it’s a revolution for the application to adapt to the hardware. It abstracts everything away from the application, such as resources and operational considerations, so the application developer need not worry about the environment that the application will run in because it’s in a container that is abstracted from the hardware.

The old environment was extremely complicated because both applications and operations had to worry about the details of how to operate the application. To manage this, Google created its containers through Project Borg and then turned its focus to the management of these containers, thus creating Kubernetes. Google generates two billion containers a week. Everything in Google, including virtual machines, runs within containers. They also enable the capacity to be split among multiple environments. 

Kubernetes has to manage billions of containers and created applications by composing these containers and pods (containers have a common basis). This allows Google to create an environment that is fairly homogeneous and creates a standard foundation for applications to scale no matter what hardware is underneath the container environment. Kubernetes also allocates containers to the appropriate resources, restarting jobs and moving containers when resources require it.

In July 2015, Kubernetes 1.0 was launched. Companies like Red Hat contributed significantly to the open source community to get this ready. The authors recognized that they had to move this to a foundation so that the rest of the industry could work and participate to ensure that all their needs were met. The key is that Kubernetes is built upon a single software stack and abstraction layer. The working group realized that everybody’s environment is different and wanted internal communities to work on modifying Kubernetes to meet everyone’s else’s needs.

Kubernetes uses declarative, context-based rules that enable the descriptions to be portable. There were 400 contributors to this project at the start of the project, which has enabled a lot of input from the community to reach the project. The Kubernetes environment becomes a target environment that is universal for the industry, regardless of the underlying infrastructure. It supports load-balancing, scaling, health checking, and micro service management. It can work in a cloud environment like AWS, a virtualization environment (VMware, Azure, and KVM), and a base operating system like Windows or Linux.

A target-neutral management tool was needed to be able to manage microservices, containers, and pods. It was important that the design point was the ability of Kubernetes to deploy a single container in less than 5 ms. It was also important that the project enabled containers and micro services to schedule across environments. The health monitoring is extremely good, since you are managing multiple instances of the same application.

Kubernetes works with the network and storage, as we discussed in the previous columns. There is work on rollback of these services that is deployed. It deals with phased rollouts or phased upgrades while the environment continues to run. If it sees that it needs the new capacity, it can bring up a new set of containers and deploy the workload associated with the Pod. One of the keys to making this work is an excellent scripting language that can also use other tools given the magnitude of the management technology.

Therefore, when people ask how to manage the application-centric cloud with containers, micro-services, and virtualization, we look to the community that is building the tools because the traditional management systems fail us in this new environment.

Sam Greenblatt is a consultant to technology companies to define strategies, and offers technology services beyond the company's business strategy. He will focus on the strategic requirements of clients' businesses by working with them to determine long term technology-related decisions and create the appropriate operating model. Mr. Greenblatt is a Technologist in Residence at several technology companies where he uses his background as technologist and his history of successfully helping companies bring technology to market by helping the management team of these companies source and evaluate potential technology, particularly in areas where he applies his background.

Sam served as CTO and General Manager of Engineering Solutions at Dell providing solutions, to have strong alliances, develop cross-line of business offerings and offer a cohesive architecture that will make customers’ offerings run better with the workloads that meet these needs. He is a recognized expert in Object Technology, IaaS, PaaS, and HPC (Red Hat OpenStack, Azure, HyperV, VMware). He built solutions based on Cloud, Analytics, Big Data, and Enterprise Applications (SAP and Oracle). He was chief architect and technologist at the Enterprise Solution Group was involved in the architecture, communication and technical promotion of Dell's Enterprise family of products. Sam has served on USDL (Linux Foundation) 4 years, Object Management Group (11 years), Eclipse Board (1 Year), and the DMTF Board 2 Years. He is the primary inventor on 4 US Patents in Object Technology. He was a CTO at Hewlett Packard, Candle Corporation and Chief Innovation Officer at Computer Associates. Sam also was an adjunct professor of Computer Science at both Temple University and LaSalle University.

The opinions expressed in this blog are those of Sam Greenblatt and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author