Cloud Native Computing Foundation hones in on containers, community and standards

Derek du Preez Profile picture for user ddpreez March 29, 2017
The Cloud Native Computing Foundation, focused on the Google-developed Kubernetes system, has accepted Docker’s containerd and CoreOS’ rkt.

The Cloud Native Computing Foundation (CNCF), which supports the growth of open source technologies that enable the delivery of a ‘cloud native’ architecture, this week kicked off its European conference in Berlin with the acceptance of popular container technologies, as well as the latest release of Kubernetes 1.6, the Google-developed system that is driving the movement.

A cloud native architecture is defined as one that relies on containers, distributed management and orchestration, and the use of micro-services - all of which are specifically designed for cloud environments. It’s the next level of abstraction up from virtualisation and allows for greater utilisation, lower costs and better portability.

The open source technologies that under pin such an architecture - largely driven by the Kubernetes focused CNCF - are growing hugely in popularity and have seen rapid adoption amongst buyers over the past three years.

The crowd-pleasing announcements at the event in Berlin were that Docker’s core container runtime - containerd - has been accepted by CNCF’s Technical Oversight Committee, along with CoreOS’ application engine rkt (pronounced rocket).

Containers are the latest trend in enterprise cloud architectures, given the portability and utilisation rates they achieve. And Docker has been at the forefront of adoption for buyers.

Dan Kohn, executive director at CNCF, marked the acceptance of the two technologies as a big win for the Cloud Native open source movement, claiming that CNCF has containers at its core. Taking to the stage, he said:

This is the core upstream component that is being used by millions of folks. It is used in Windows and Linux, it is backed by five of the biggest cloud companies. We have been working with Docker and the community of partners for really the entire life of CNCF. We are just incredibly excited to have containerd here, it’s just a really natural partnership.

With containderd and rkt, I think it’s really clear that CNCF is really the focal point for containerization.

Patrick Chanezon, member of the technical staff at Docker, joined Kohn on stage at the event and said that even if you weren’t aware of containerd, it’s been the core container runtime for the Docker engine since version 1.11. Chanezon said that this meant that even if today is the first time you are hearing about containerd, “you’re probably already using it on your laptop or in the cloud”.

containerd is built by docker, with input from the five largest cloud providers, and has millions of installations in all industry segments. Chanezon said that it is a “stable codebase that has now been tested”.

Chanezon said:

The role of containerd in the container ecosystem - at the base layer you have your operating system, on top of it you have a thin layer of standards (the Open Container Initiative), then on top of that implementing that is containerd the core container runtime, and then you can build your own orchestration. So containerd is really designed to be embedded.

The community is vibrant. It’s a very healthy project. Why did we give Containerd to CNCF? We chose CNCF because of the alignment of goals. We are all engineers and containerd is very aligned technically with the other CNCF projects.

Kubernetes 1.6

Alongside the container news, the latest version of the Kubernetes system (1.6) was announced. Kubernetes was developed by Google, by later open sourced in the hope that this would attract a community and eventually lead a proportion of the community to the Google Cloud Platform (although it certainly now does not need to be used in that specific environment).

Kubernetes fundamentally is a system that enables management of containerized applications in a clustered environment. It aims to provide better ways of managing related, distributed components across varied infrastructure.

Chen Goldberg, director of engineering, container engine and Kubernetes, Google, told delegates this week in Berlin that open source is no longer a second choice for developers and the enterprise. And that predicable releases of Kubernetes further help the community. She said:

The team insisted it would be open source. You can imagine it was a hard decision to make. To take something that would be a differentiator for Google and make it open source. Why open source?

Developers prefer open source because of the visibility and because what you see is what you get. And the freedom of choice. And in the last couple of years we have seen that enterprises also prefer open source, because they can make sure it meets their need, they can change anything they’d like to.

Kubernetes can run anywhere at scale. The innovation pace is unimaginable. We have just released 1.6 - yay! One of my personal contributions is that we move to a steady release cadence every three months because the community needs to know that if they miss the train, there’s always the next train. And it really helps the community to work together. We’ve also heard from users that this is why they like Kubernetes, because they know that the innovation doesn’t stop.

As evidence of the growing community, Goldberg highlighted how a year ago 67% of contributions to the Kubernetes project was Google, but that this figure has now dropped to 42% - with the next largest contributors being individuals, rather than companies or vendors. She said:

We have people with different interests and different opinions, and that’s important, it’s what makes Kubernetes work. Google will continue to invest, we have more and more engineers working on it, it’s just that the community is growing faster.

Release 1.6 saw Kubernetes increase the total cluster size by 150% to 5,000 node (150,000 pod), which it claims will help deploy applications such as search or games. It has also introduced advanced scheduling capabilities and dynamic storage provisioning. A full rundown of the release can be viewed here.

However, Goldberg picked up on a couple of areas that she and Google wants to encourage. Firstly, she called on users of Kubernetes to get involved with the Special Interest Groups (SIGs), which then contribute to the project within the Kubernetes framework. She said:

Kubernetes is a bit overwhelming, I get that, but I think the SIGs are a great way to contribute. To start to work with the community. You can choose one of the SIGs you like, something you’re passionate about. First time, just come to a meeting, you will be able to match a face to a name. You can then start to contribute.

She added that Kubernetes, and the community, needs to think about the future and how to keep the success it has experienced sustainable (with many at the event pointing out that OpenStack experienced a similar stage of success but later struggled). Goldberg focused on two key areas that are linked - conformance and open standards. She said:

Conformance - this is our responsibility to our users. If you’re choosing to partner with someone, or integrate with another company, you want to make sure that they are compliant with Kubernetes and that you will be able to upgrade to the next release and benefit from new features.

You also want to make sure your workloads can move from different platforms. This requires conformance tests, to make sure that this actually happens. And this is something that is behind the ideal. We want to make sure that as a community that we are compliant. I want to know that you can come, you can leave and move your workloads elsewhere.

Open standards are also very important. The Kubernetes community has to invest more in building those open standards. By having open standards, vendors can innovate elsewhere, so the innovation will be much greater.

The ball is in our court, making sure the success is sustainable. If you want to help us, I welcome you to join us.

A grey colored placeholder image