From Silos to Services: Cloud Computing for the Enterprise

Jun 26 2018   3:08PM GMT

Kubernetes is the Platform. What’s next?

Brian Gracely Brian Gracely Profile: Brian Gracely

Public Cloud
Service Broker

This past week, I gave a webinar titled “Kubernetes is the Platform. Now what?“, based on this presentation. I thought it might be useful to provide some additional context beyond what could be explained in 30 minutes. The purpose of the presentation was to explain how Kubernetes has evolved over the past couple of years, what it is capable of doing today, and looking forward to where new innovation is happening around the Kubernetes platform.

A Brief History Lesson on the evolution of the Platform market

Ever since venture capitalist Marc Andreessen uttered the phrase “software is eating the world” to the Wall Street Journal in 2011, companies of all sizes and maturity levels have been in a race to acquire software development talent. That talent enables startup companies to disrupt existing industries and business models, and that talent can also be used by existing companies to reshape how they digitally interact with customers, partners and their markets.

In order to succeed in the race to become a software-centric business, one of the most critical pieces to have in place is an application development and deployment “platform”. In today’s world, this platform is the digital equivalent of the supply chain and factory that enabled successful businesses of the 20th century. The goal of this platform is to not only simplify the ability for developers to rapidly build and deploy new applications and updates, but also be able to securely scale those deployments are demand grows and changes.    

At the time of Andreessen’s original comments, many companies and communities were trying to provide solutions to this problem through Platform-as-a-Service (PaaS) platforms. This included Heroku, OpenShift, dotCloud, Google AppEngine, Cloud Foundry AWS Elastic Beanstalk and several others. While PaaS platforms gained some traction, they suffered from several significant challenges:

  • Tied to one specific cloud platform
  • Limited developer applications to specific languages or frameworks
  • Used proprietary or platform-specific application packaging models
  • Provided limited visibility for troubleshooting applications
  • Provided limited visibility to the operators of the platform
  • In some cases, not open source or extensible

Many of these limitations were resolved with two core technologies – Linux containers (docker) and open source container orchestration, specifically Kubernetes. The combination of these two building blocks set in motion where the industry is today, with a unified architecture that allows a broad set of applications to run, and the foundation for continued innovation.   

As Kubernetes has evolved since 2015, it has been able to support a wide variety of application types, from new cloud-native applications to existing applications to big data analytics and IoT. The embedded deployment models within Kubernetes allow it to be intelligent and properly manage the deployment and availability of this variety of application types. This ability to support so many applications on a single platform results in better ROI for the platform, but also simplifies overall operations. And as Kubernetes has evolved, matured and stabilized, it has allowed new innovation to happen around Kubernetes to improve the developer experience, support even more application types, and provide better operations for applications running on Kubernetes.


Adding Services to the Kubernetes Platform

Beyond the core capabilities of Kubernetes, the community has seen opportunities to innovate around important areas for application workflows, security, developer tools, service brokers and many other areas. This has led to new projects within the Cloud Native Computing Foundation (CNCF), that augment Kubernetes:


Enabling Services off the Kubernetes Platform

While Kubernetes has done an excellent job of enabling many applications to run in containers on the platform, the world still doesn’t run entirely on Kubernetes. This means that there needs to be a common way to reach services that run off the platform. This is where the Kubernetes community has innovated around the Open Service Broker, allowing integration of 3rd-party services through a broker model. This applications applications to integrate with off-platform services, and Kubernetes operators to still have visibility into usage patterns. Brokers for services from AWS, Azure and Google Cloud already exist, as well as brokers for Ansible Playbooks. In the future, we expect that the number of brokers will continue to grow, both from cloud providers, but also being independently built to serve specific business needs.


Extending the Kubernetes API via Custom Resources

At some point in its evolution, every project must decide how broad its scope will be. Every project wants to be able to add new functionality, but this must always be balanced against future stability. While the Kubernetes community is still innovating around the core, it made a conscious decision to allow the Kubernetes API to be extensible, allowing new innovations to be Kubernetes compatible, without expanding the Kubernetes core. This extensibility is called Custom Resource Definitions (CRDs), it is already allowing significant extensions to Kubernetes. For example, most of the “Serverless” or Functions-as-a-Service (FaaS) projects – such as Kubeless, Fission, OpenFaaS, Riff, etc – integrated with Kubernetes through CRDs.


Simplifying Operations with Operators

While Kubernetes does include powerful and granular “deployment” models, those models don’t include all the things that complex applications might need for Day 2 operations. To help fill this gap, the Operator Framework was created to enable applications to not only be deployed (directly or in-conjunction with other tools, such as Helm charts), but also to codify the best practices for operating and managing those applications. In essence, building Automated Operations around those applications. The Operators framework can be used for core elements of the Kubernetes platform (e.g. etcd, Prometheus, Vault), or used for applications that run on the Kubernetes platform (e.g. many examples here). ISVs are already beginning to adopt the Operator Framework, as they realize that it will allow them to write one best practice to Kubernetes, which allows their application operator to run on any cloud that has Kubernetes.


Kubernetes – A Unified Platform for Innovation

When all of these elements are put together, it becomes clear that not only has Kubernetes established itself as the leading container orchestration standard, but it’s also established itself as the foundation of a unified platform for innovation. The core Kubernetes services are able to run a broad set of business applications, and the extensibility is enabling innovation to happen both on the platform and off the platform. This unified approach means that operations teams will be able to establish a common set of best practices. It also means that Kubernetes-based platform, such as Red Hat OpenShift, has created that application platform that Andreessen discussed nearly a decade ago as critical for any business that wants to be a business disruptor and not on the list of being disrupted.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: