Recently, the CNCF Technical Oversight Committee (TOC) had two representative seats come up for re-election. We are happy to announce that Google’s Brian Grant has been re-elected and Huawei Technologies’ Quinton Hoole was elected to his first term as a TOC representative; filling the seat once held by Docker’s Solomon Hykes. We would like to thank Solomon for his service on the TOC and best wishes for the future.
The TOC is made up of nine representatives with impressive technical knowledge and backgrounds who provide technical leadership to the cloud native community. For additional information, please visit: TOC election process, TOC principles, and TOC representatives.
“The role of TOC representative is vital to the CNCF and its ability to create an engine for innovation for the next era of applications,” said Alexis Richardson, TOC Chair. “I want to thank everyone for their service on the TOC the last two years helping to build this committee and identifying and guiding the first set of projects into the CNCF; your role has been vital. We look forward to our continued work with Brian Grant and welcoming Quinton Hoole as we continue to move toward our goal of enabling customers to deliver Cloud Native applications faster.”
Below please find a short interview with
Please share a little bit about your technical background and work with the TOC thus far.
BG: I co-lead Google’s Kubernetes efforts and have been a key architect of the open-source project since its inception. I have contributed to most areas of the project at some point. A number of aspects of the design, including core concepts, such as pods and labels, were inspired by my work on Google’s internal container-management projects, Borg and Omega. I currently co-chair SIG Architecture and am a member of the Kubernetes Steering Committee. Prior to my work in this area, I worked on high-performance computing, compilers for interesting chips, dynamic compilation, and dynamic frequency/voltage scaling.
As a TOC member, I sponsored seven of the current 18 CNCF projects, participated in due diligence for several projects, and contributed to the logical reference architecture and TOC principles document. With 11 years at Google, I have developed a good idea of what a mature cloud-native ecosystem could look like. I also bring the perspective of a project maintainer, and have been working with the CNCF to improve support for Kubernetes and the other projects. I provided a lot of input to the devstats dashboard, for example.
QH: My background is primarily at the intersection between classic computer science, large-scale computing infrastructure, and the commercial and industrial application of those. Before Huawei, I was at Google, where I first ran the SRE teams responsible for keeping the revenue critical ads systems cranking out cash. After that, I served as a tech lead on the early Kubernetes project team. Prior to that, I was the founding engineer of Amazon’s Elastic Cloud Computing (“EC2”) project, where I lead a lot of the early design, implementation, and productionization of what became the AWS we know today. A string of startups and early-stage tech companies preceded that, across a variety of industries including financial services, aviation, telcos, call center automation and travel.
I became involved with the TOC about a year ago when I started helping out with the evaluation of candidate projects for the CNCF. There is such an explosion of interest in this space, and making sense of all of the potential contributions and different technical approaches proves to be both interesting and quite challenging. I think that my background in deep, large-scale tech as well as the myriad of real-world applications of it, often helps me to see the important seedlings when they begin to sprout, so that they can be appropriately nurtured.
How has the cloud native landscape evolved the last few years?
BG: One development that many have noted has been the emergence of Kubernetes as the de facto standard container platform, and the large ecosystem growing around it. To take advantage of its capabilities and ecosystem, users want to run all kinds of workloads on Kubernetes, from machine learning to virtual machines to functions. There’s also interesting work happening around application lifecycle automation to manage all of these workloads in a portable fashion.
Service meshes, such as Istio, have also recently sparked the interest of many, for the control and observability they offer, as well as their ability to bridge different environments.
QH: I think that the most important evolution has been the wide-scale commercial adoption of the kind of hands-off system operation pioneered by companies like Google and Amazon in the early 2000’s. I remember that even at the time we started EC2 in the mid-2000’s only a handful of companies were taking that approach very seriously. In those days, just being able to get hold of data center machines within minutes from a public cloud operator, rather than months from a hosting service or corporate IT provider was considered revolutionary. But until fairly recently, despite all the positive press about DevOps and data center automation, an awful lot of software systems were still essentially run by hand. That has clearly changed dramatically in the past few years. Fully automated software operations are pretty mainstream these days.
How do you see this evolution continuing in the next few years?
BG: We’ll see efforts that have started over the past year come to fruition. For example, I expect we’ll see integrations across the major cloud-native technologies, Kubernetes, service meshes, and functions. We’ll also see new capabilities address areas that are of particular concern to enterprises, such as identity, policy, and security. And, now that the deployment platform is settled, clearer choices will emerge for development and continuous-integration solutions.
QH: I think that the big change is going to be in what we consider to be the scope of “the cloud”, and how we develop and operate software to run on it. Rather than essentially being a bunch of servers in relatively secure, reliable data centers, as it is today, “the cloud” is rapidly transforming into a much more loosely connected pool of machines and devices that encompass everything containing a microprocessor. You might call this “IoT” but it’s actually much broader than that. It spans things like connected cars, cameras, smart cities, traditional mobile phones, tablets, watches, home-, retail- and industrial-automation systems, traditional data centers etc. Heck, even my home aquarium includes a computer and a bunch of sensors and probes, all connected to servers in data centers.
Many people don’t even realize that the cellular base stations that you see everywhere have a bunch of computers in them. We still need to figure out how to efficiently build and operate reliable and secure software that ties all this stuff together in meaningful and useful ways. As we achieve that, I think that there is likely to be an explosion of innovation. Today most of that base technology already exists, but it’s just way too hard to gain access to and automate across it with clever software. We really are still in the stone age in that regard, despite all the recent advances. My personal view is that we need something akin to what Linux is today for standalone machines and devices, only it needs to be designed to operate this big new distributed machine I described above.
Today we really do still build software for single machines and tie it together with things like microservice fabrics. But I don’t think that approach is going to take us where we need to go in this new cloud world. Microservices are an important component, but there’s much more required. We need an operating system that spans everything, and that we know how to program. Similar to how Linux decides which CPU to run your process on, and which part of disk, main memory or flash your data should be in at any point in time, we need that for this new cloud, deciding where to put data, where to do processing, and how to keep all that secure. Today a lot of that logic still sits inside cloud application programs or traditional infrastructure automation, but that approach doesn’t work at all well, for a variety of reasons. We need to push it all down into this new distributed operating system to make meaningful progress, I think. And we need to learn how to program this new distributed machine. I’ve taken to calling this the Distributed Cloud Application Platform, for want of a better term, and it’s something I’m spending a lot of my time figuring out and building at the moment.
What do you hope to accomplish as a TOC representative?
BG: From its founding, it took some time to establish how the TOC should operate, what types of projects we were looking for, and so on, so I feel we’re now hitting our stride. I plan to continue to grow our project portfolio, particularly through the Sandbox, as I expect to see an increasing number of early-stage projects submitted to the TOC for review. To help guide this growth, I’ve already started on an update to our official definition of “cloud native”, since the current definition is somewhat narrow.
I’d also like to share what Kubernetes has learned as it has grown and matured with the CNCF’s other projects, and possibly share some of the tools we’ve developed for the project.
QH: I think this ties back a lot to the previous question. I see one of the primary responsibilities of the CNCF as creating an environment conducive to the creation of the cloud environment I described above. That requires an enormous number of traditionally competitive companies and their customers to come together and collaborate in meaningful ways to produce concrete, useful technology that interoperates effectively. That definitely requires a monumental team effort. I think that all of the players can enjoy a huge upside if we can make this all work well. So what I hope I can contribute most to the TOC helping to crystallize a fairly common vision across as many of the players as possible, and directing as much energy as we can collectively muster towards reaching that goal as soon as possible.