In another installment from the Red Hat Summit track from the Office of the CTO, this video is an informal discussion between Brandon Philips (previously CTO of CoreOS, acquired by Red Hat) and Clayton Coleman (Chief Engineer for OpenShift), interviewed by Steve Watt. They focus on Kubernetes as a platform of the future, identifying interesting trends in the open source ecosystem.
[youtube=https://www.youtube.com/watch?v=YAFKlOB8vBw&w=560&h=315]
This discussion is a good example of the type of technologists that comprise the modern open source ecosystem, and epitomized by these three from Red Hat. Their backgrounds in real world development and operations combines with a genuine desire to help people that fuels their work in open source communities and product creation.
In the case of Brandon and Clayton, they both have experience deploying and operating Linux at large scales, and the types of challenges you get going from single to multiple systems using open source software.
As developers working in the same open source communities, especially Kubernetes, Clayton and Brandon have a shared understanding of what is terrible about software and a vision for how it can be incrementally better. Underpinning this exchange are healthy and honest reflections on problems that help lead to better solutions.
Initiated by a question from Steve Watt, Clayton and Brandon turn the discussion to the Kubernetes operator framework. As the first implementation of the operator framework, the etcd distributed database is “simple enough that it moves the discussion to the next phase,” Clayton says. The idea of Kubernetes operators is to provide simple to consume higher level services, which are above the compute/network/storage that Kubernetes provides natively.
This part of their discussion highligts a common theme they return to several times in the video — making things easy for developers is the core focus for the work they are doing with Kubernetes, OpenShift, and beyond.
By making services available via an API, the operator framework is part of easing the developer’s experience. If launching e.g. an application monitoring service is just an API call away, developers will quickly move to use it.
After discussing the past trends that lead to Kubernetes, Steve Watt asks Brandon and Clayton for what other trends they see in open source that will affect the Kubernetes ecosystem as a platform.
Clayton begins by identifying a trend and need for connectivity across different points of a spectrum that he describes. This spectrum ranges from one-off efforts to high-scale systems, from coddled servers to stateless services. It needs to provide flexibility at many different points in the spectrum, with an emphasis on making services easily availble and consumable to each other.
For his first trend, Brandon drills down to how standardizing on the Kubernetes API is a major game changer for enterprise teams. In his example, an enterprise architecture group diagrams a new application on a whiteboard, then divides the work among teams such as networking, application developers, and operations. The common situation has been each team then working in their own domain, and running into problems at each connection to the other teams.
In the Kubernetes world, these many different personas agree around the Kubernetes API. This allows them to transfer the whiteboard diagram to Kubernetes, with the API reflecting 1:1 for each part of the diagram.
Brandon says, “It’s been a while since we’ve had something like that, not until we all agreed on one language … have we really been able to say, any language, any compute infrastructure, whatever, this is an API we agree upon. I think this is a unique opportunity moving forward over the next few years, (it) enables teams to be a lot friendlier with each other.”
For his next trend, Clayton talks about the mistake of thinking because you aren’t operating at massive scale tools that handle massive scale aren’t useful for you. He labels this meme as, “You’re not Google”, used by others as a dismissal of choosing tools that are designed or capable of operating at massive scale.
“No, you are not Google, you have far more interesting problems than they do,” Clayton says. It is fine to use “overpowered” tools to do your work, as long as the tools can provide a single node as easily as 5000 nodes via the ease of an API. He describes that the Red Hat goal of “taking the toil out of developers lives” benefits from the very powerful tooling and thinking that the largest-scale uses provide.
Steve then asks Brandon to respond about the future of applications enabled in Kubernetes. Brandon mainly sees the complexity increasing. Applications started low-risk, with stateless apps, and the trend has shifted as people try higher-risk applications. Current distributed databases with native Kubernetes operators show where the trend is at today.
In order to get there, Clayton sees a need in the broader open source ecosystem to trend toward doing a better job at helping people get oriented before they dive into the technology. With the right orientation, people will find the flexibility they need to do many and varied interesting things. The service broker API in Kubernetes, he said, is one way the community built out that flexibility.
Responding to a question about the next generation of open source software and it’s relationship to Kubernetes, Brandon says, “We are at an inflection point for open source software.” It has always seemed true that when a piece of open source software needs to run on more than one system, it was too daunting to setup yourself, and many people and projects would fall back to a public cloud service.
“The opportunity that (comes) with Kubernetes,” Brandon says, is where “open source systems that always felt too complex to run yourself … and defaulted to just-ask-the-cloud-service, we can actually bring it back to open source.” He continues, “Open source services can be deployed on this open source platform, which is Kubernetes. I think that’s a pretty important innovation.”
The exciting thing to Brandon is that this gives the open source communities a solid target, much the way the Linux kernel solved the single-machine use case.
Clayton brings his comments toward a close by highlighting the value of being a fast-follower, that of seeing someone else’s ideas and being inspired. He picks that up as a strength of how open source software has evolved — people working together, starting from a small need of one or a few people, and growing through empowering other people and being generous.
“That’s our current inflection point,” Clayton says, “of open source being reinforcing” of itself. While people with a similar problem might consume a common service, they are just as likely to work together now to solve that problem on open source to make something better, together.
While the history of open source has also been a history of getting in our own way, those lessons lead to containers where we can build something that runs on our laptops, and it runs in test and production just as well.