 Hi, this is your host, Supreme Bhartiya and welcome to another episode of T3M, our topic of this month. And the topic of this month is Kubernetes or Cloud Native Complexity. And today we have with us, once again, Julian Fisher, CUN, founder of NNN. Julian, it's great to have you on the show. Nice to be here. Yeah, I was at QCon, I missed you there, but one of the, after discussion, you know, one thing, or one theme that keeps coming up again and again is the complexity of Kubernetes or Cloud Native Word and folks are saying that, you know, depending on who you talk to, when I talk to Priyanka, she'll say, hey, this complexity is not going to go away. The landscape is going to get bigger. And a lot of folks are all saying, hey, you know what? We have to, you know, accept it and actually learn to deal with it. So what I want to ask you, because you folks have been in this ecosystem for a very long time, all the way to Cloud Foundry days, what makes Kubernetes or Cloud Native so complex? Well, first of all, yeah, it was sad to miss QCon in Amsterdam, but I had a talk in the U.S. at PostgresCon, so there was a conflict in my schedule. So when it comes to complexity of Kubernetes, I'd say, well, first of all, you know, the foundation of Kubernetes is container scheduling and container orchestration. And if you want to, you know, operate workloads that are big enough container orchestration gets fairly complex. You know, it's just a complex problem to solve. So there's a certain lower barrier of complexity in Kubernetes that's just unavoidable. However, you know, the container orchestration part of Kubernetes has its complexity in implementation, but it's hiding that under wonderful abstractions and it makes it fairly simple for people to use. So the application developer experience is isn't dominated by that complexity too much. So you can still express, you know, still get, you know, applications and services to run, you know, without having to, you know, deal with all the possible options to do that. So I think they've did a good job here, but what increases complexity over time is less, you know, the problem of running one single Kubernetes cluster, but it's more, you know, dealing with a lot of Kubernetes clusters. That's definitely, you know, inviting some complexity, especially because you rarely run a Kubernetes cluster as it is, but instead there's a growing ecosystem of Kubernetes extension. So the ability of Kubernetes to, you know, be extended by custom resource definitions and controllers, you know, has, you know, forged Kubernetes to become the framework for building cloud automation these days. And so that ecosystem with a lot of possibilities in extensions, that's adding another layer of complexity. And if you combine, you know, all these things, you'd have a lot of Kubernetes clusters. Each Kubernetes cluster may look different, and that's a complexity that also affects the operations because it creates a lot of operational friction if you don't apply, you know, best practices and automation in a rigorous way. If you look at the complexity, if you look at ecosystem, because, you know, sometimes technology come in and, you know, the ecosystem matures and then the focus shifts to the users. And we are talking a lot about developer stories these days. Do you see that this complexity will go away? Or you think, no, complexity is here to stay. What we have to do is make it simpler. So a lot of folks can, you know, start, I mean, they're already using it, but, you know, they can consume Kubernetes and all these clouded technology in much better way. Well, first of all, you know, when it's about, you know, complexity and dealing with complexity, I'd say about Kubernetes, you know, on its own that the solutions out there to deal with Kubernetes, they became more mature over the years. So that reduces complexity in the sense that it becomes simpler to bootstrap Kubernetes clusters. You don't have to have that expert knowledge right away to get your hands on a Kubernetes cluster. But at the same time, by adding more features to Kubernetes and adding more extensions that are in demand regularly, any Kubernetes offering also requires a certain amount of, you know, popular Kubernetes extensions to be there. And then we enter slowly, you know, an area that's not as developed as you may think, which is lifecycle managing, you know, extensions and managing, you know, multiple extensions in a graceful way. Again, I'm looking at that from the perspective of running a lot of Kubernetes clusters. So if you think about most extensions, they'll give you the ability to apply, let's say, YAML specifications as one way to install them. And then there could be another package manager. It could be a Helm chart, or it could be an old M package or anything like it. But the question is, if you want to run, you know, a lot of Kubernetes clusters, and there are so many different ways of lifecycle managing Kubernetes if the YAML specification layer is not what you want, then the question is, which tools do you want to use and how good are they? So when it comes to, you know, data service automation, which is one of our passions, we've tried, you know, several of those lifecycle management tools, for example, and none of them is really suitable to cover it all. And even if you accept multiple of them to be coexisting, you know, it does not feel, you know, as easy as it should. So I think that's an area of ongoing development is if there are more extensions, how to deal with them gracefully and guide those extensions through their lifecycle gracefully. Because in the end, you know, application developers, they will set up a cluster once, you know, develop their applications, but when their applications develop, they also have to lifecycle manage all the extensions these applications depend on. So it will be essential, like when using libraries in your code, it's like, do you have a good package manager that does, you know, complexity management and dependency management is in general, hard problem to solve. And I think it's one of the bleeding edges in Kubernetes these days, especially looking at a large number of Kubernetes clusters with a good CI and CD pipeline, you can manage, you know, the lifecycle of a single cluster with a few extensions with ease, but at scale, large organizations, that's a different story. If you look at, once again, the whole ecosystem, where do you see the ecosystem is currently focused on? Are they, I mean, of course, there are so many projects once again, but if you look at the whole ecosystem, which includes vendors as well, where they are looking at solving these problems, are there other areas that they're mostly focused on? I see a lot of tiny, you know, building blocks in the Kubernetes ecosystem being developed. And, you know, I really love that about the Kubernetes ecosystem. However, I think, especially, you know, well, it's a bit our own perspective here from any nines because we deal with large enterprises as our primary customers. And I'm currently missing the tooling to deal with those large platform environments gracefully. So there are a lot of ongoing projects that are very nice and promising. I mean, look at the success story of Crossplane, for example, trying to bring, you know, inter cluster and also configuration beyond Kubernetes, you know, into a declarative, you know, language that's based on Kubernetes. And I think that shows where the direction should be headed. If you combine that with a proper tool for managing extensions, I think that would be promising. We are seeing a lot of projects that you mentioned, Crossplane. And beyond that, the focus is shifting on developers. So we see a lot of projects, we see a lot of products which are coming out and the focus is to simplify things for users without compromising on the flexibility of Kubernetes and all these cloud-based technologies. If we look at any nines, can you talk about how you folks are helping? You can talk about either your solutions or how you guide, help users as you set big enterprises as well to deal with this complexity. Within the any nines platform, there are several active areas of development. If, and obviously we're utilizing, you know, Kubernetes as a primary framework to build new generation products. So one of the problems we see is, how do you represent organizational units of a large client? We could call them business units or development teams or tenants, if you want to. So that's one of the first things. How do you say, well, this is a department and this department has a team and this team has, let's say, half a dozen dozen Kubernetes clusters for various purposes. And you would like to be able to restrict their access and management of a certain number of users to that particular tenant. And ideally, without using infrastructure means. So of course, you can set up a hierarchy of AWS accounts if you're an AWS. But one of our mantras at any nines is to be in a healthy relationship with the underlying infrastructure, which means not to depend on their tooling too much. Take the commonalities, but shy away from those vendor-specific constructs wherever possible, especially if they're provided by the infrastructure vendor and there's no alternative, let's say on another infrastructure or the alternative is vastly different. So tenant management is one. And also, if you think about the Cloud Foundry ecosystem and the idea to centralize application development in order to gain efficiency, especially operation efficiency, where I still believe Cloud Foundry is absolutely stunning, then you also have that concept of a marketplace. And I spoke to many clients and I also spoke to many developers and there's a confusion about the term what marketplace is and what its purpose is. So in Cloud Foundry, it basically serves two purposes. First, it enumerates the backing services available to consume from your application. So you could, let's say, create a database through the marketplace. So it's about browsing and discovering your options, but then it's also about provisioning it and to a certain degree configuring it, let's say by choosing service plans which could boil down to certain configurations or virtual machine sizes of, let's say, your database. So if you think about a large enterprise using Kubernetes at scale, having such a marketplace, telling the developers of individual departments which tools they can choose from is also something that needs to be covered where there are some tools going into that direction but some of them don't seem to be contemporary. So what we are going to release, possibly also as an open source framework is a framework to build a marketplace. Well, obviously it will be easy to download metadata for any Nines products, but you could also import data from AWS or GCP or any other provider. So that developers within large organizations can discover the tools that have been cleared by platform operations or the platform managers within an enterprise to choose from. So marketplace, that's more like that exploration part but then you also want to be able to provision and maybe do my life cycle management beyond using an API. So something like a generic AWS console as an open UI framework. So what we are going to do is release that UI framework so we'll be able to do white labeling, it will be able to write components for each cloud service you want to integrate in that console and the marketplace will also be built on the same UI framework. So they will go together very, very nicely and it will address the problem on make a service discovery within the organization of a client much simpler. Julian, thank you so much for sitting down with me and talk about these topics and as well I'd love to sit down and check with you again. So thank you. And thank you for having me again. It's always a pleasure. Hopefully we run bump into each other at the next KubeCon.