Kubernetes & CNCF Panel: Joseph Jacks, Jonathan Kratter, Christian Posta
Kubernetes and CNCF
Containers enable microservice architectures by making it easy to develop, package and run microservices in an efficient, run-anywhere format. The mutually reinforcing trends of microservices and containerization have fueled the adoption of Kubernetes, which in turn drove the proliferation of a cloud native tooling and the formation of the Cloud Native Computing Foundation.
During Kong Summit, Kong CTO and Co-Founder Marco Palladino discussed the history and future of containers, Kubernetes and the CNCF with industry thought leaders Joseph Jacks (CEO, KubeCon), Jonathan Kratter (Senior Systems Engineer, Uber) and Christian Posta (Chief Architect, Red Hat). Hear what these industry experts had to say about the state of cloud native technology in the recording.
See More Kong Summit Talks
Sign up to receive updates and watch the presentations on the Kong Summit page. We’d love to see you in 2019!
Marco Palladino: Containers and Kubernetes and CNCF trends that are transforming the way, as we know we all know by now, transforming the way we’re building our software and transforming our organizations. I’m honored to host this panel with great guests and I’ll let them introduce one by one.
Jonathan C: Right. I’m Jonathan Kratter, I work at Uber. I’m filling in for our head of tech services Shobhana today. I’m leading our Kubernetes efforts so it’s neat to come into an established organization and say, “well how can we benefit from Kubernetes replacing existing patterns.” Before this had a chance to do a greenfield Kubernetes project with a small startup called Kumofox working with Intel. We’re building a platform for IOT device backend services. So two very different scenarios.
Christian P: Cool. My name is Christian Posta. I’m an architect at Red Hat. I’ve been working on Kubernetes before it 1.0’d. I worked on a open-source project called Fabricate where we built tooling on top of Kubernetes and Red Hat has a product built on top of a Kubernetes called OpenShift and I work with our customers to build applications basically on top of OpenShift.
Joseph Jacks: My name is Joseph Jacks I’m the co-founder of a company called Aljabr currently but Kubernetes is, kind of, been my obsession for the last fourish years. Started the conference behind Kubernete’s KubeCon. KubeCon is now run by the Linux Foundation, they’re doing a phenomenal job scaling and supporting that. Also started, sort of, the first company around Kubernetes support services and tooling. Huge fan of Kubernetes. Love the Socks by the way John. Go Kubernetes. And, yeah, kind of, been writing about open-source and, kind of, open-source related things. So I’m happy to be here.
Marco Palladino: Well thanks for being here. This is amazing. Well containers and containerization technologies have been around for a while. Although we’re seeing there is a rise in popularity in the, you know, in the few last years. The technology itself has been around for, you know, almost a decade even more than that perhaps. So what do you think it’s really causing these adoption right now? What was the driver for these trend to grow in the past few years?
Christian P: I’ll take that one. I think what Docker did was pretty amazing. They built a user experience around building and using containers. And it wasn’t just the container part like the cgroups, namespace, type things. It was also the packaging, it was, “how do you take a tarball and actually distribute that and have it be relatively stable and consistent?” That, you know, solved a lot of problems around … from the beginning of just typing some code and getting a service working and distributing it to another developers laptop, to “how do we actually take things into production safely and take the application code down to its constituent dependencies in a consistent way?” So I think that solved a lot of problems, the user experience around … so I think Docker did amazing work in doing them.
Joseph Jacks: Completely, completely agree. I mean, just some extensions to what Christian said, you know, we’ve had the primitives for containers for arguably more than 20 years even before cgroups and things that existed in a kernel; the Linux kernel. We had some Solaris zones and technology way before that in different non-Linux operating systems. But I think Solomon Hykes and the innovation around Docker and the container runtime, Docker really unlocked a level of simplification for a developer to basically build an immutable image of their application state and have a way to very simply distribute that image in a consistent, repeatable way, taking advantage of consistent primitives in Linux which was, sort of, I think, the way Eric Brewer described this as, you know, the most stable abstraction in, kind of, server-side computing which, kind of, creates that portability so for sure Docker drove the usability, simplicity.
Jonathan C: I mean, I think one additional thing is, you know, these primitives have been around for a long time but like you said in your previous talk, architectures change organizations, I think organizations were hitting a point where they needed the Kubernetes architecture, they needed something that was that flexible and malleable? Yeah, five years ago, I don’t think it would have been so easily understood or adopted.
Marco Palladino: And in European what made the Kubernetes such a strong trend?
Jonathan C: I mean, the Google un-premature GkE being available. Google’s decision to create the CNCF foundation, think they give a lot of people confidence in it.
Joseph Jacks: I think it’s also going back to Docker again, I mean, Docker’s gonna come up a lot but Docker, kinda like, galvanized this movement towards, kind of, like, democratizing distributed systems ’cause the architectural complexity started to create lots of concentration of rethinking the way traditional monolithic services were architected, and breaking them down to, sort of, more compostable, decoupled components and Docker made that really easy to reason through. But we’d still didn’t have, really, like, a distributed systems API for managing these fractals of architectures and containers. And so Kubernetes is a progression from the growth of Docker to something that people could use to reliably use Kubernetes at scale and containers at scale, really. Kubernetes originally was just exclusively supporting Docker because that was, sort of, the trigger point for Google, you know, realizing that timing was actually right for releasing Kubernetes obviously, before that we had mazes and other things.
Christian P: I think the abstractions that Kubernetes went with, they seem straightforward and they seem simple, but it’s not until you’ve had a lot of experience building those types of systems do you actually get to that level of simplicity and I think Google, Red Hat, CoreOS all these people came together in the community to help drive the design and the implementation. So it’s a combination of the right abstractions and the growth in the community that made Kubernetes as successful as it is right now.
Jonathan C: Certainly from the upside of things, I think that’s absolutely the case, I mean, the slack workspace for Kubernetes is such an amazing resource and the people there are so helpful. Being able to hop online and talk with the CoreOS [inaudible 00:08:04] at 2AM in Berlin, incredibly powerful. Also, folks like Kelsey Hightower and Jess frazelle; the great presentations they gave. It was accessible and interesting, I mean, can’t rule that out.
Marco Palladino: And so we’re talking about all of these different workloads, you know, our applications they have to
deal with all sorts of things, state full applications, stateless applications, you know, and Kubernetes, like you mentioned, provides abstractions for each one of these different workloads. Do you think we are there yet? You think we are successful with that? Do you think the promise of running everything into a container … The dream of running everything in a container has been … that vision has been executed yet? Or do you think something is lacking?
Christian P: I think it’s well on its way, I don’t think it’s there yet. I think there’s still, like for example, running databases on Kubernetes, I think there’s still work to be done around operationalize that, you know, the folks at CoreOS and now Red Hat have that operator framework that are … and API’s [inaudible 00:09:18] of frameworks to help do that but I think we’re still learning that, I think we’re not there, we’re getting there, I think we’ll get that goal.
Christian P: Kubernetes was purposely not written to be super opinionated about what application architectures you ran or if it’s 12 factor or if it’s, you know, state full type applications, which the design from the beginning, again, getting the right API and the right design in place up front didn’t happen by accident. There’s a lot of thought and experience that went into them.
Jonathan C: I think the decision to keep, Sort of, kernels small to spin parts of it like Helm off from the main project. It creates a fertile environment for further iteration, but I think there’s a point in one’s voyage with Kubernetes, where you stop thinking, “Oh, how does Kubernetes do this? Or how can I do this with Kubernetes? To, “how do I solve this problem with Kubernetes?” becomes the hammer that you use and you’re fitting other things to It’s paradigm as opposed to the reverse.
Joseph Jacks: I think Kubernetes is really just like a building block. So if you look at it as a set of primitives that give you certain level of opinionation, but really great reusable semantics for dealing with distributed systems complexity at the compute level, you can layer on top of ton of really amazingly powerful, higher level abstractions that you need. Things like Kong, things like, you know, the sort of application level abstractions in open shift there’re staple service operator systems like Rook and many other tools that sort of either extend the base Kubernetes primitives that don’t solve all the problems or allow you to basically layer on additional control logic and things on top of that API.
Joseph Jacks: And so there’s a reasonably useful analogy and I think you can generalize too much but Kubernetes as this Linux kernel for distributed systems, and so eventually it, kinda, disappears into the background as an implementation detail and it becomes less front and center in terms of how you deal with it and deploy and manage it and Karen feed for it. I think there’s, a sort, of tale of like that complexity, kind of, going to zero eventually.
Joseph Jacks: I don’t think it’s unlikely that Kubernetes, kind of, gets embedded in IOT devices, inside of arm chips and things that we, sort of, know run Linux kernels today without, you know, any operational, kind of, complexity, they just get booted, designed that way when they leave a manufacturing facility or something. So Kubernetes is definitely not the end all be all like system for everything it’s a building block I think.
Marco Palladino: What in your day to day conversations with perps within your organization’s or with other organizations, right? What are you seeing? What is the state of the adoption of containers and Kubernetes? Everybody wants to do it. Everybody talks about it. What is the actual state of that?
Christian P: Yes. I mean, I work with a lot of organizations, big household name organization, here in North America that are adopting Kubernetes or OpenShift. You know, it’s a organization changing technology, not just from only the positive stuff but, you know, it forces you to deal with some of that really hard, challenging organizational parts as well because it changes the way … and you probably have deeper insight into this, it changes the way that you monitor applications, that you secure applications, that you deliver applications to production, changes the way you build the applications.
Christian P: I like to say in the past, we, kinda, had this idea that you build applications with the assumption that your database will never really go down, your network won’t really go down, your application; We might run a few of ’em, but we don’t expect any major disasters, but then when things do go down then your applications weren’t built to handle that. When you build for Kubernetes or a cloud platform, you build, knowing that things are going to fail, you have to, there’s no expectation of reliability.
Christian P: So, you know, re-architecting, and re-imagining application architectures because of that, you know, organizations are becoming successful, but it’s also forcing them to confront these realities.
Marco Palladino: Perhaps, what was the journey at Uber? You can give us some-
Jonathan C: Yeah, absolutely. So I mean, it’s still very early days within Uber IT/tech services. I think a lot of that’s due to the fact that we’ve got a fairly robust infrastructure as it is, great puppet infrastructure, great monitoring in place and so there isn’t necessarily the urgency that you might find in other less mature organizations. At the same time we have a lot of internal tools and internal tools developers and they’re saying, “hey we wanna be able to get our tools out there, we wanna be able to create a service and let people play with it, but do it within a sandbox that’s safe.” So I think it’s figuring out; how does this make sense for us? How does this integrate with existing systems? How do we permission it?
Marco Palladino: So in the journey into the adoption of Kubernetes in containers, when you see that failing, Why is it? What causes are you seeing that determine, perhaps, the main reasons that determine the failure of adopting Kubernetes and container technologies?
Jonathan C: The question often comes up, “well, why do I need this more than Docker? You know, what is this going to give me the Docker Compose isn’t going to give me?” And, you know, it’s not always easy to give someone a 30 second answer and say, “No, no, you don’t understand, this is a, you know, glorious, beautiful world where these two things are entirely separate.”
Jonathan C: Our first attempt at a cluster was using Amazon’s EKS. And we had an organizational challenge where the people responsible for AWS IAM and the people responsible for the Kubernetes cluster were in different organizations and so there was gonna be a lot of back and forth there every time off changes need to happen. So we said “well, maybe we should, you know, try a different approach.”
Marco Palladino: Christian? I’m sure you have something to add.
Christian P: Kubernetes Community has done a really good job of … from where it was [inaudible 00:16:53] days to where it is today in terms of how you can use it, how you can install it, how you can manage it. All kinds of tools have sprung up around the ecosystem. By the end of the day Kubernetes is pretty complex, so there’s no doubt that, you know, the complexity of getting it running and then keeping it running is a challenge that if an organization is not ready to invest that time and money that it’s likely to not turn out the way they hoped.
Joseph Jacks: I agree a lot.
Marco Palladino: So what do you see in the future of Kubernetes? What can, in your opinion, Kubernetes do better to make that adoption easier and more successful moving forward?
Joseph Jacks: I Think developer experience is a really wide open area for Kubernetes maturity. Dockers, gonna keep coming back up, but it’s sort of nailed the developer experience and really won the hearts and minds of just millions of developers ’cause it was just that simple and really easy to reason through and learn and, kind of, adoption is explosive as a result of that.
Joseph Jacks: The Kubernetes we’ve seen a lot more developers, kind of, come into the ecosystem as the adoption is, kind of, increased but it’s mostly an operator, sort of, DevOps systems infrastructure user base ’cause this is something that you serve up to engineering teams or development teams or platform teams to use as an API. So I think developer experience probably where companies can improve the most. I mean, having said that there’s lots of really interesting, cool tools that Google and Red Hat and many other companies have been building.
Joseph Jacks: I think OpenShift helps a lot with developer experience, scaffold from the team at Google is also taking another approach of really simplifying how you can go from, like, source code to running distribute systems, you know, service on Kubernetes without really needing to understand, you know, five different primitives or 10 different primitives and just sort of, you know, a couple of commands you’re there. I think the [inaudible 00:19:11] at Microsoft has done some really interesting things.
Christian P: And to piggyback on his answer, kinda making Kubernetes … the developers when we build and deploy on Kubernetes we don’t really care it is Kubernetes, we, kinda, want that abstracted away or hidden, right? We want like Joe said, “the experience of deploying our application” I don’t care what pods and all that other stuff is, you know, so the more that Kubernetes become stable enough and boring enough that it disappears into the background, the more successful it’ll be.
Jonathan C: I think the operator pattern, it’s been mentioned before, is something that will bridge a little bit of the gap between your infrastructure and your application layer and making sure that what those operators are operating, the quality of the packages available Helm charts et cetera, it’s really high quality, it’s supported by the creators of the software, you’re not, kinda, grabbing a random chart that someone else published, that, sort of, reliability and confidence in the community sources.
Marco Palladino: And the CoreOS team that’s now part of, you know, Red Hat also did some great work around that with a framework that makes it easier to build those operators. Seems like that’s, definitely, one of the trajectories that will make Kubernetes even more successful moving forward. Software that knows is aware of itself and knows how to scale within the infrastructure within the data center.
Speaker 5: Yeah agreed.
Marco Palladino: The ecosystem around Kubernetes and even CNCF; how do you see that developing in the camp moving forward? Right? In our journey towards more adoption in containers, in modern systems, how you see the role of CNCF in the landscape of CNCF playing out?
Christian P: It just moves up, up the stack, I think, solving problems. Once you get applications into Kubernetes, and then, you know, you deployed it, awesome, right? But now, how do you capture telemetry? How do you capture distributed tracing? How did you do load balancing and service discovery and these types of things?
Christian P: Now we’re starting to solve the problems as we move up the stack. And I think that’s where the CNCF sponsoring projects that play in that space and make it a little bit easier to build and deploy applications on Kubernetes is doing a good job.
Joseph Jacks: I think one of the consequences of the CNCF encouraging a huge ecosystem of cloud native oriented projects to grow under a common foundation umbrella is that, you know, positives and negatives. Positives, obviously, this is a place of a lot of innovation. There’s lots of additional projects, kind of, coming into the fold. On the, potentially, the negative side; someone used the word the other day which I found was interesting called optionities. There’s too many, too many, too many options and too large of a space to explore, there’s like five or six different choices for each layer in the stack.
Joseph Jacks: And, you know, you have … just like Christian was saying, how you handle secret management and persistence and, you know, service discovery, how do you deal with distributed tracing and monitoring and networking and all these different things that maybe Kubernetes doesn’t natively, kind of, address the full scope of those kinds of concerns? And so you have to, sort of, like look at what your custom [inaudible 00:23:10] or your custom infrastructure is gonna look like depending on what you really wanna be using. And so I think CNCF’s awesome driving tons of innovation, but also they’re doing a lot of really important work around driving best practices and not necessarily standards, but just, kind of, like things that help people make better decisions around choosing all the different pieces of the puzzle.
Jonathan C: One thing I think in the IT world that I’m interested in seeing how it develops is; how will we be able to take other vendors software and bring it into our Kubernetes cluster in a trusted fashion, a fashion that’s not gonna disrupt what’s already running in there? We had a very interesting experience couple months ago, we had two projects doing similar things; cataloging entities basically, one was delivered as a jar and the other was delivered as a Docker compose file.
Jonathan C: And it was couple hours before I was downloading the Spring Boot framework and trying to get that jar working, the Docker compose file we had up and going in about half an hour. So more of those type of interactions between organizations. It’ll be interesting to see where that goes.
Marco Palladino: So do you see there’s going to be some consolidation moving forward? Right? Joseph mentioned five different ways of doing things-
Joseph Jacks: I think we need consolidation, yeah, I mean, it’s just … there’s too much choice, you know, yeah, CNCF has … originally they created a landscape which was, sort of, a maze of Possibilities in the universe for all the different sections of, kind of, technology that you need to consider and evaluate in the world of cloud native. And I think Originally there were maybe 20 or so projects and five or so categories and now there are probably 20 categories and maybe close to 200 or so projects approaching 500.
Joseph Jacks: I think it’s important to have consolidation, we probably will have consolidation, there’s lots of overlapping concerns. But I think eventually … we’re in the most exciting time in history for infrastructure software, for distributed systems, for computing. It’s an insanely exciting place to be in the industry, huge amounts of opportunity. And, you know, I’m an optimist so I’m just glad we’re seeing a lot of innovation.
Marco Palladino: What steps do you believe CNCF should take to grow sustainably in the future as a foundation?
Joseph Jacks: This is really tricky, this is a tricky question. I think one of the … this isn’t really an answer to your question, one of the [inaudible 00:26:15] of the CNCF has always been to, sort of, not pick winners which I think is important but at the same time, it doesn’t quite mitigate the optionitis effect of having this massive landscape to, sort of, navigate and choose from. None are like that subway system, but times 10. Maybe somewhere in China there’s one more complicated than that.
Joseph Jacks: I think the Apache Software Foundation was similarly modeled after just being an umbrella for software projects, not necessarily a specific domain of software. And, you know, you have an ASF, you have lots of different streaming systems, you have a bunch of different databases.
Joseph Jacks: In CNCF there’s likely to be multiple implementations and options for, kind of, the more complicated areas of cloud native technology to consider. And I don’t think there’s ever gonna be one standard for each, kind of, technology with the exception of, probably, the, distributed systems API cluster management layer. I think that Kubernetes is just a really great building block and pretty unique project in that area. But I think ultimately choice people who, you know, [inaudible 00:27:35] do these re-architecture projects and moving toward the cloud computing providers and modernizing their infrastructure. Having choices is important but, you know, CNCF’s solving lots of big problems.
Joseph Jacks: And I think maybe one thing if I could offer like one suggestion would just be to get consensus in the industry around what cloud native is all about. And just continue, kind of, chipping away at that which they’re doing, so.
Christian P: Even though it’s not perfect, I’m a fan of the Apache Software Foundation, the way it runs its projects and I like that it doesn’t try to pick winners either that’s why you have however many different messaging systems, but it also has a governance model that every project follows and, you know, it lets each community figure out the best way to take the technology but the guidelines, the rules, the governance is supposed to be similar or the same for every single project.
Christian P: At the end of the day, the goal of those projects is to get more … build the community around those projects and get people to contribute, get people to use it, get people to file bug reports, and active on the mailing list and get people involved.
Christian P: And so the more any organization or CNCF can do to focus on building and growing the communities around the projects that it brings in under its umbrella, the more successful it’ll be.
Jonathan C: Not a whole lot to add here but, I think the conformance programs that they run and just in general keeping the lines of separation between elements nice and clean. I know that’s a big thing that people like about Docker and if Kubernetes can maintain that I think that’s important.
Marco Palladino: We’re seeing open-source being more and more of a driver for most of these innovation, Docker open-source, Kubernetes open-source, you know, lots of projects in the CNCF landscape are also open-source, why? Why is the open-source, in your opinion, driving so many trends?
Joseph Jacks: I think open-source is a really, really, really big deal. And this has to be one of the most polarizing topics in technology period, probably as extreme as our political polarization, which is very depressing. I think that there’s two kinda ways of looking at this; as people who look at open-source as just a way of distributing software and yeah, you can modify and distribute and contribute to the Source Code and that’s it and then there’s another which I think is less propagated but, kind of, fundamentally correct way of looking at it which is open-source changes everything, it changes the entire kind of continuum of software creation, delivery, company building, ecosystem developing, platform company developing, culture rate of innovation, it changes everything and I think it’s like, super, super fundamental, you know.
Joseph Jacks: I don’t believe we’d have the internet in its current state, without open-source, we would not have this crazy, also polarizing, space called cryptocurrencies and blockchains without open-source, we wouldn’t have, you know, the sort of massive lever of innovation around AI and machine learning without open-source, mostly driven by TensorFlow and other frameworks.
Joseph Jacks: We wouldn’t have any of this huge renaissance and massive innovation around computing, distributed systems, thanks to Kubernetes and Docker without open-source. So, kind of, open-source is this like fundamental thing and, you know, we wouldn’t have galvanized 10s of millions of software engineers around the world to actually innovate at the scale they have without open-source and I don’t think We’re going to get to the next 20 or 30 million in the next hundreds of millions of software engineers without open-source either.
Joseph Jacks: So I think open-source is really, really fundamental. And you’re right, yeah, it’s a , kind of, common thread. CNCF is a collaborative foundation within the Linux Foundation which arguably the most important open-source project created. And I think, probably, if you were to look at the most impactful, relative to size, kind of, technology entities in the world, Linux Foundation is pretty high up there because of the importance of open-source and they’ve been doing phenomenal work there.
Christian P: Yeah, I absolutely agree. And that’s what we see in our customer base at Red Hat. So Red Hat is an open-source company as some of you may know, everything we do is open-source and the customers that we work with they’re adopting and their going toward open-source because they see this level of innovation in the communities, because they can get involved and help direct them. And you know that’s strategic to them.
Jonathan C: Slightly lower level open-source is portable, I can take it from one job to the next, I can share it with friends in other places not having to go through a whole sale cycle is hugely helpful especially, in smaller organizations
Christian P: And even actually … just jumped in my head, even from a individual perspective, let’s say 20 years ago, all of the state of the art technology, a lot of it, at least, was proprietary; It was owned by the big companies. Now, if you have five hours on the weekend, you can go contribute to TensorFlow and some of these innovative communities and, kinda, reverse engineering them and understand how they work and meet the other people in the community who are driving these efforts. And really, you know, it gives another amazing avenue that we never had before, to grow your career and learn and become part of these communities. So even from a individual looking perspective, it’s awesome.
Joseph Jacks: I also don’t think we would have cloud computing without open-source. I guess S3 was the first service that Amazon released but EC2 is based on Zen open-source hypervisor. And you could arguably say, depending on how you
look at it, I don’t quite think this is true but EC2 is, sort of, the largest commercial open-source service given how widely used it is, and it’s based on an open-source or really two critical open-source projects, Linux and Zen, It’s like fundamentally based on those.
Joseph Jacks: You can, sort of, look at all software and say, “okay, all programming languages are basically open-source now and so as a consequence all software is, kind of, based on open-source.” But I think that’s stretching the definition a little bit too much. But I think open-source is gonna change everything in the technology industry over the next 10/15 years and its really fundamental.
Marco Palladino: Many in the audience are working with large organizations that perhaps are starting to look into open-source technologies, in your experience what makes a large enterprise a successful adopter of open-source?
Joseph Jacks: Freeing developers, letting developers contribute to open-source, rewarding them for contributing to open-source, providing the right incentives from the top down and I think embracing open-source competency. There’s these, kind of, open-source centers of excellence and open-source, kind of, innovation centers think those are important, especially for larger, big legacyish kinda technology companies that are still transitioning to becoming software companies and transitioning to the future.
Christian P: I’m just curious, how many people on the room use open-source technologies in their work today? If you could raise your hand. That’s-
Joseph Jacks: That’s cool.
Christian P: … almost all of them. Yeah, I think that pretty speaks for itself. I don’t think they’re going to it, I think people are doing it and they’re successful with it.
Marco Palladino: Open-source means also contributing back. Think Uber is doing a great job with that.
Jonathan C: Yeah, we’ve released a number of very interesting projects-
Christian P: Jaeger.
Marco Palladino: Jaeger’s good.
Jonathan C: … I’m really excited about our new time series database; M3, Mattermost, we’ve done a lot of work with them too. Yeah, I mean, absolutely. It’s a two way street.
Marco Palladino: It is, it is. Are you excited for the future? Future of-
Christian P: Technology?
Marco Palladino: … technology?
Christian P: Yes, absolutely. Yes, absolutely. I still think we’re at the very beginning of this landscape shift. And the successful organizations aren’t just adopting this technology, but they’re actually bringing new value to their customers and, you know, like, Uber’s a great example. So yeah, I’m really excited about how we can use this technology, but how, you know, the rest of the markets changed because of that.
Marco Palladino: Well thank you Christian, thank you Joseph, thank you Jonathan. Was great to have you here.
Group: Thanks for having us.
Marco Palladino: Yeah. Any questions from the audience? That is ready with the catch box.
Christian P: Back there. Come on Brett Favre throw that.
Speaker 7: For a company that’s starting with Kubernetes and has never done it before or even done Docker. What is the commitment that it takes? How many … I know it’s hard to say but how many people? How much time do you need to put up front in your infrastructure teams to prepare before you start using it so you can be successful? And as a follow-up question what’s the one thing that Kubernetes doesn’t do that most people think it does that is a gotcha?
Christian P: I think in the experience that we have with our customers; first of all, getting all of the teams that will be impacted by this change to the same table and get them in the same room, get them talking [inaudible 00:39:13] the networking folks, security folks, developers absolutely and, you know, that’s pretty hard by itself so getting to that level of commitment from those different organizations is important.
Christian P: The other thing is I wouldn’t … I don’t wanna squash your dreams here but I don’t think that you’re gonna be able to get from zero to running in production in Kubernetes in a month or two months, I think we’re talking six months or longer. So having a realistic expectation for how long it’ll take and the parts of the organization that will impact, you know, getting that established up front is huge.
Joseph Jacks: So huge amount of respect for, Christian, Christian’s amazing; slight disagreement, I think it’s all contextual, it depends, if you’re huge enterprise it could take you two years to get into production with Kubernetes if you’re a startup … so it depends on what your constraints are. You’re really small?
Speaker 7: [inaudible 00:40:24]
Joseph Jacks: Okay, Okay. So maybe the sweet spot is, yeah, six to nine months. I mean, if you’re a company with 20,000 engineers and like 1,000 infrastructure people or something, yeah, I mean, it’s gonna … this is like a huge transition depending on what your definition of success is. If your definition of success is literally all services, all production infrastructure, critical data, you know, literally everything is running on Kubernetes, hitting live traffic for everything transaction processing. I think there’s only a handful of companies on earth that are at that level of scale that has everything running on Kubernetes but, I mean, I’ve seen smallish startups that are going through tons of growth, kind of, get two or three really capable engineers and people connected to the right support channels in the Kubernetes community and go from literally not knowing really how to correctly pronounce Kubernetes and maybe the client tool to running in production in 30 days or even, you know, even less. So it depends. I think it depends a lot.
Joseph Jacks: But yeah, what Christian said, one thing I’ll extend on is Kubernetes kind of, like, breaks down the silos, so if you have like teams that are used to operating in isolation, security and networking, and, you know, deployment, provisioning and software engineering and all those teams that are, sort of, like living in their own islands and they never communicated before, one of the things Kubernetes does is it, sort of, unifies all those communication channels and it breaks the silos down into something that, like, really, provides a level playing field of, kind of, communications semantics about how to deal with your infrastructure, how to deal with your applications. And I think that’s part of why it’s a really powerful piece of technology.
Jonathan C: I think it’s essential that you start small, spin up a small cluster in AWS, using kops, demonstrate value quickly with proofs of concept, don’t imagine that it’s going to change overnight, sort of, incremental victories will get you there.
Joseph Jacks: Hear that?
Christian P: There was a question over here [inaudible 00:42:35]
Speaker 8: Thank you. So I have a two part question actually. So kubernetes 1.9.11 came out I think yesterday or today was announced and that’s the last one that’s coming in 1.9. 1.2-RC1 came out during this talk, right now, 10 minutes ago. Kubernetes is moving way too fast in my personal experience and a lot of Kubernetes developers and users who can say for that, so what is, like, you as architects and everybody as community members, is there a path going to be forward where innovation slows down and we slow down? Or is that going to be like the Linux kernel where there are so many distributions and then you rely on some distribution to support, you know, multi-year release, because when you run in production, for a medium sized company, it’s not super easy to just upgrade [inaudible 00:43:36] or upgrade Kubernetes. So how do you think should that be handled? And if we as community can do anything about it at all?
Christian P: That’s a good question. You’re hitting on exactly the difference between what a project is upstream in the open-source community and what a long lived product is that you need to build your business on top of and that’s where we look at it at Red Hat. So, that being said I think there are things that we can do in the Kubernetes community to support long term releases.
Christian P: But that being said things move fast and things underneath Kubernetes are changing quite drastically in some cases that, you know, you definitely don’t wanna … it’s not gonna be very feasible for customers, for example, in your shoes to constantly be upgrading all the time without the risk of breaking things all the time.
Christian P: So, like, Red hat in some cases gets dinged for, “well open shift is, you know, a quarter behind, you know, they just released Kubernetes whatever and, you know, the way we’re looking at it is our customers need that stability and that we take very seriously.
Speaker 8: Would, like, having distributions of Kubernetes be like duplication of work with what we have seen in the Linux kernel community with, like, so many distributions, I mean, there comes good and there are opinions in there. But is the community going anywhere around with that? Because there’s not really any communication in the community channels about it.
Joseph Jacks: I think Jonathan was talking about conformance in the CNCF is like a, really, useful and positive thing. And it’s very related to what you just said, which is; in order to prevent a lot of the fragmentation and duplication of work and effort around the, sort of, massive number of Kubernetes distributions. CNCF is doing a really great job, kind of, providing standard compliance checks, test framework, CI infrastructure, and a lot of other things to, sort of, make sure everyone is, kind of, at least on the right path of agreement. So there isn’t a lot of that fragmentation. I don’t think that that’s gonna prevent more distributions from being created.
Joseph Jacks: That’s just a natural evolution for the project. And it is very similar to the Linux kernel ecosystem. So, you know, we’re sort of seeing proof of this by Red Hat’s heavy investment in Kubernetes from the very beginning of the project. In fact, they’ve created major, critical components in Kubernetes that are fundamental to the project. So yeah, I think it’s both scary and exciting, and it’s probably gonna continue that way.
Speaker 8: Thank you.
Joseph Jacks: Sure.
Christian P: I think extending the metaphor of Kubernetes is a set of building blocks, it’s unreasonable to expect that everyone will build the same thing if you give them blocks. So there’s gonna be some diversity there. And part of our job is to manage it.
Marco Palladino: Thank you very much. This was great.
Christian P: Thank you all. Thanks for coming.
Joseph Jacks: Thanks, everyone.
Learn more about Kong Summit