2018: The Year of Kubernetes and Interoperability

Jan 8th, 2018 10:35am by Chip Childers

Chip has spent more than 18 years in large-scale computing and open source software. In 2015, he became the co-founder of the Cloud Foundry Foundation as Technology Chief of Staff. He was the first VP of Apache CloudStack, a platform he helped drive while leading Enterprise Cloud Services at SunGard and then as VP Product Strategy at Cumulogic. Prior to SunGard, he led the rebuild of mission-critical applications for organizations including IRS.gov, USMint.gov, Merrill Lynch and SEI Investments. Chip is an experienced speaker at events like OSCON, LinuxCon North America, LC Japan, LC EU, ApacheCon, O’Reilly Software Architecture Conference, and many more. In his free time, Chip loves trail hiking with his black lab, sailing catamarans and sunfish, and trying to keep up with his young daughter.

This year, 2018, will be going to be quite a year for “cloud computing.”

There are two big trends I expect to truly take-off in 2018:

Interoperability via and across open source.
Standardization around Kubernetes as the next-gen infrastructure abstraction.

Don’t worry, here come the details.

On its own, Kubernetes is a great story. What makes it even better is the soaring interoperability movement it’s fueling. An essential part of enabling interoperable cloud-native apps on Kubernetes is the Open Service Broker API. OSBAPI enables portability of cloud services across offerings and vendors. A collaborative project across multiple organizations, including Fujitsu, Google, IBM, Pivotal, Red Hat and SAP, it enables developers, ISVs, and SaaS vendors to deliver services to applications running within cloud-native platforms. In 2017, we saw adoption of the API by Microsoft and Google. Late in the year, Amazon and Pivotal partnered to enable expose Amazon’s services via the broker as well. Red Hat uses it to support the OpenShift marketplace.

A craftily designed API, OSBAPI is beautiful in its simplicity. It got the abstraction right. After several iterations, the abstraction is still holding strong, enabling OSPABI to continue to grow in use and evolve over time, eventually becoming even more powerful.

The valuable ecosystem around OSBAPI is one of the key factors to its success. The Cloud Foundry Application Runtime was being used by many Fortune 100 enterprises, and brought with it an ecosystem implementing the API. Since the technology solved the right problems, and the API was designed in the right way, it made sense for the Cloud Foundry community to bring in other members to help oversee and manage OSBAPI. With a more addressable market, there is an even greater ecosystem around it. The OSBAPI is a great example of a positive sum game — wherein everyone wins and no loses at someone else’s expense.

The Kubernetes community’s embrace of OSBAPI is a great validation. As it becomes more widely adopted, we’re seeing even more clearly the benefits of having multiple platform software systems using that API to talk to backing services. The goals we had around that API are coming to fruition. Originally developed within the Cloud Foundry community, OSBAPI was meant to be opened up, allowing it to evolve so it would be useful beyond the Cloud Foundry platform. The intent was that with more support given for using it, the more competing cloud providers would want to build on it and use it to expose their capabilities.

A great example is the work Google, Pivotal and VMware are doing with PKS that includes a connection back to the Google Cloud capabilities, so developers can take advantage of Google’s awesome machine-learning functionality. In 2018, you can expect the OSBAPI to become the standard bearer for making services available across Kubernetes and Cloud Foundry Application Runtime distributions. You can also expect this type of interoperability to extend beyond just services. Including how CF App Runtime and Kubernetes interact. A bit more on that below.

Kubernetes as the Next-Generation Infrastructure Abstraction

Kubernetes is quickly becoming the next-generation approach for consuming infrastructure. In 2018, this should become an inevitability. Until recently, IaaS capabilities were VM-centric. Kubernetes —especially managed Kubernetes services — shifts the consumer’s interaction from virtual machines to containers. Combine that with various efforts to make Kubernetes deployment and management easier for enterprise datacenters (ex: The Pivotal Container Service — PKS — from Pivotal and VMware, or SUSE’s Container-as-a Platform), and it starts to look like a universally available infrastructure API.

What Kubernetes is not, is an application-centric platform. It’s a container platform you can use for many different use cases. The question of how you build or manage your containers is one of the more important considerations now. We’re seeing a few different approaches in the Cloud Foundry community as they find ways to deploy CF Application Runtime onto Kubernetes as an infrastructure target. There are a couple of options in the ecosystem now, and while we don’t know which one is going to win in the end, there’s a clear need to run Application Runtime in a well-managed way in Kubernetes clusters.

Nevertheless, there are some limitations. While Kubernetes is beautiful in its simplicity, it doesn’t quite do multi-tenancy at the level that VM-centric infrastructure services can, even within the same company’s account. But that’s an area the Kubernetes community will improve over time.

One interesting approach is a project from SUSE to create containers out of the CF Application Runtime components and deploy them into Kubernetes clusters. This potentially provides a lighter weight CF environment within existing Kubernetes clusters and furthers interoperability between technologies — and communities.

The wide embrace of Kubernetes is significant, but it’s important to note: Kubernetes showing up doesn’t, in and of itself, change the way you architect your applications. What it does is offer a container-based infrastructure substrate, which has many advantages over the VM-centric infrastructure of the past. Cloud Native is about more than containers though. It’s about rethinking how applications should be designed, deployed and managed to fit into a much more distributed (with all that distributed entails) system.

As we’re reaching a point where Kubernetes is becoming the new model for infrastructure, Cloud Foundry Application Runtime is hyper-focused on the custom application development experience. Both can be used to tie into backing services that can exist in multiple cloud environments. And that development experience and enabler of interoperability are good for everyone: users, developers and the open source community.

This year, you can expect to see these technologies — alongside these trends — converging to create a more clear, compelling, and complete view of what “cloud native” means.

The Cloud Foundry Foundation is a sponsor of The New Stack.

Feature image by John Towner on Unsplash.

Chip has spent 20 years in large-scale computing and open source software. In 2020, he took over as Executive Director at Cloud Foundry Foundation, which he co-founded in 2015. He was the first VP of Apache Cloudstack, a platform he...