 Welcome back everyone to the special presentation of cloud native at scale, the cube and platform nine special presentation going in and digging into the next generation super cloud infrastructure as code and the future of application development. We're here with Bic Lee who's the chief architect and co-founder of platform nine. Bic, great to see you. Cube alumni, we met at an OpenStack event in about eight years ago or later earlier when OpenStack was going great to see you and congratulations on the success of platform nine. Thank you very much. Yeah, you guys been at this for a while and this is really the year we're seeing the crossover of Kubernetes because of what happens with containers. Everyone now has realized and you've seen what Docker's doing with the new Docker, the open source Docker now just the success of containerization. And now the Kubernetes layer that we've been working on for years is coming bearing fruit. This is huge. Exactly, yes. And so as infrastructure as code comes in, we talked to Bascar talking about super cloud. I met her about the new R-lawn you guys just launched. The infrastructure as code is going to another level and it's always been DevOps, infrastructure as code. That's been the ethos. That's been like from day one developers, just code. Then you saw the rise of serverless and you see now multi-cloud around the horizon. Connect the dots for us. What is the state of infrastructure as code today? So I think I'm glad you mentioned it. Everybody or most people know about infrastructure as code but with Kubernetes, I think that project has evolved the concept even further and these days it's infrastructure as configuration. So which is an evolution of infrastructure as code. So instead of telling the system, here's how I want my infrastructure by telling it do step A, B, C and D. Instead with Kubernetes, you can describe your desired state declaratively using things called manifest resources and then the system kind of magically figures it out and tries to converge the state towards the one that you specify. So I think it's an even better version of infrastructure as code. And that really means it's developer just accessing resources, okay, declare, okay, give me some compute, stand me up some, turn the lights on, turn them off, turn them on. That's kind of where we see this going. And I like the configuration piece. Some people say composability. I mean now with open source so popular, you don't have to write a lot of code and it's code being developed. And so it's integration, it's configuration. These are areas that we're starting to see computer science principles around automation, machine learning, assisting open source because you got a lot of code. That's right. You're hearing software supply chain issues. So infrastructure as code has to factor in these new dynamics. Can you share your opinion on these new dynamics of as open source grows, the glue layers, the configurations, the integration? What are the core issues? I think one of the major core issues is with all that power comes complexity, right? So despite its expressive power, systems like Kubernetes and declarative APIs let you express a lot of complicated and complex stacks, right? But you're dealing with hundreds, if not thousands of these YAML files or resources. And so I think the emergence of systems and layers to help you manage that complexity is becoming a key challenge and opportunity in this space. I wrote a LinkedIn post today those comments about, why enterprise is the new breed? The trend of SaaS companies moving, our consumer-like thinking into the enterprise has been happening for a long time. But now more than ever, you're seeing it. The old way used to be solve complexity with more complexity and then lock the customer in. Now with open source, it's speed, simplification and integration, right? These are the new power dynamics for developers. So as companies are starting to now deploy and look at Kubernetes, what are the things that need to be in place because you have some, I won't say technical debt, but maybe some shortcuts, some scripts here that make it look like infrastructure as code. People have done some things to simulate or make infrastructure as code happen. But to do it at scale is harder. What's your take on this? What's your view? It's hard because there's a proliferation of methods, tools, technologies. So for example, today, it's very common for DevOps and platform engineering tools, I mean, sorry, teams to have to deploy a large number of Kubernetes clusters, but then apply the applications and configurations on top of those clusters. And they're using a wide range of tools to do this, right? For example, maybe Ansible or Terraform or Bash scripts to bring up the infrastructure and then the clusters and then they may use a different set of tools such as Argo CD or other tools to apply configurations and applications on top of the clusters. So you have the sprawl of tools. You also have the sprawl of configurations and files because the more objects you're dealing with, the more resources you have to manage. And there's a risk of drift that people call that where you think you have things under control, but some people from various teams will make changes here and there. And then before the end of the day, systems break and you have no idea of tracking them. So I think there's real need to kind of unify, simplify and try to solve these problems using a smaller, more unified set of tools and methodologies. And that's something that we try to do with this new project, Arlon. Yeah, so we're gonna get to Arlon and it's like I wanna get to the why Arlon. You guys announced that at ArgoCon, which was put on here in Silicon Valley at the community by in two where they had their own little day over there at their headquarters. But before we get there, Baskar, your CEO came on and he talked about SuperCloud at our inaugural event. What's your definition of SuperCloud? If you had to kind of explain that to someone at a cocktail party or someone in the industry technical, how would you look at the SuperCloud trend that's emerging has become a thing? What would be your contribution to that definition or the narrative? Well, it's funny because I've actually heard of the term for the first time today, speaking to you earlier today. But I think based on what you said, I already get kind of some of the gist and the main concepts. It seems like SuperCloud, the way I interpret that is clouds and infrastructure, programmable infrastructure, all of those things are becoming commodity in a way and everyone's got their own flavor. But there's a real opportunity for people to solve real business problems by perhaps trying to abstract away all of those various implementations and then building better abstractions that are perhaps business or application specific to help companies and businesses solve real business problems. Yeah, I remember that's a great, great definition. I remember not to date myself, but back in the old days, IBM had a proprietary network operating system, so the DEC for the mini computer vendors, DECnet and SNA respectively. But TCPIP came out of the OSI, the Open Systems Interconnect. And remember, Ethernet beat token ring out. So not to get all nerdy for all the young kids out there, just look up token ring, you'll see. You've probably never heard of it. It's IBM's connection for the internet, the layer two. Is Amazon the Ethernet, right? So TCPIP could be the Kubernetes and the containers abstraction. That made the industry completely change at that point in history. So at every major inflection point where there's been serious industry change and wealth creation and business value, there's been an abstraction somewhere. What's your reaction to that? I think a saying that's been heard many times in this industry, and I forgot who originated it, but I think the saying goes like, there's no problem that can't be solved with another layer of indirection, right? And we've seen this over and over and over again where Amazon and its peers have inserted this layer that has simplified computing and infrastructure management. And I believe this trend is going to continue, right? The next set of problems are going to be solved with these insertions of additional abstraction layers. I think that's really, it's going to continue. It's interesting, I just remember another post today on LinkedIn called the Silicon Wars AMD Stock is Down. ARM has been on a rise, we've been reporting for many years now that ARM is going to be huge, it has become true. If you look at the success of the infrastructure as a service layer across the clouds, Azure, AWS, Amazon's clearly way ahead of everybody. The stuff that they're doing with the Silicon and the physics and the atoms, you know, this is where the innovation, they're going so deep and so strong at IaaS. The more that that gets gone, they have more performance. So if you're an app developer, wouldn't you want the best performance and you'd want to have the best abstraction layer that gives you the most ability to do infrastructure as code or infrastructure for configuration, for provisioning, for managing services. And you're seeing that today with service meshes, a lot of action going on in the service mesh area in this community of KubeCon, which we'll be covering. So that brings up the whole, what's next? You guys just announced Arlon at ArgoCon, which came out of Intuit. We've had Mariana Tesla at our super cloud event, she's the CTO, you know, they're all in the cloud. So they're contributed that project. Where did Arlon come from? What was the origination? What's the purpose? Why Arlon? Why this announcement? Yeah, so the inception of the project, this was the result of us realizing that problem that we spoke about earlier, which is complexity, right? With all of this, these clouds, these infrastructure, all the variations around compute storage networks. And the proliferation of tools we talked about, the Ansibles and Terraforms and Kubernetes itself, you can think of that as another tool, right? We saw a need to solve that complexity problem, and especially for people and users who use Kubernetes at scale. So when you have hundreds of clusters, thousands of applications, thousands of users spread out over many, many locations, there needs to be a system that helps simplify that management, right? So that means fewer tools, more expressive ways of describing the state that you want, and more consistency, and that's why we built Arlon, and we built it recognizing that many of these problems or sub-problems have already been solved, so Arlon doesn't try to reinvent the wheel, it instead rests on the shoulders of several giants, right? So for example, Kubernetes is one building block, GitOps and Argo CD is another one, which provides a very structured way of applying configuration, and then we have projects like Cluster API and Crossplane, which provide APIs for describing infrastructure. So Arlon takes all of those building blocks and builds a thin layer which gives users a very expressive way of defining configuration and desired state, so that's kind of the inception. And what's the benefit of that? What does that give the developer or the user in this case? The developers, the platform engineer, team members, the DevOps engineers, they get ways to provision, not just infrastructure and clusters, but also applications and configurations. They get a system for provisioning, configuring, deploying, and doing lifecycle management in a much simpler way, okay? Especially, as I said, if you're dealing with a large number of applications. So it's like an operating fabric, if you will, for them. Okay, so let's get into what that means for up above and below this abstraction or thin layer. Below is the infrastructure, we talked a lot about what's going on below that, above are workloads, at the end of the day, I talked to CXOs and IT folks that are now DevOps engineers, they care about the workloads, and they want the infrastructure's code to work, they want to spend their time getting in the weeds, figuring out what happened when, someone made a push that happened, or something happened, they need observability, and they need to know that it's working. That's right. And here's my workloads running effectively. So how do you guys look at the workload side of it? Because now you have multiple workloads on these fabric. Right, so workloads, so Kubernetes has defined kind of a standard way to describe workloads. And you can tell Kubernetes, I want to run this container this particular way, or you can use other projects that are in the Kubernetes cloud native ecosystem, like Knative, where you can express your application in more at a higher level, right? But what's also happening is, in addition to the workloads, DevOps and platform engineering teams, they need to very often deploy the applications with the clusters themselves. Clusters are becoming this commodity, it's becoming this host for the application, and it kind of comes bundled with it in many cases. It's like an appliance, right? So DevOps teams have to provision clusters at a really incredible rate, and they need to tear them down. Clusters are becoming more... It's coming like an EC2 instance, spin up a cluster where people use words like that. That's right. And before Arlon, you kind of had to do all of that using a different set of tools, as I explained. So with Arlon, you can kind of express everything together. You can say, I want a cluster with a health monitoring stack and a logging stack and this ingress controller, and I want these applications and these security policies. You can describe all of that using something we call the profile, and then you can stamp out your applications and your clusters and manage them in a very... So it's actually standard that creates a mechanism. It's standardized declarative kind of configurations, and it's like a playbook, you just deploy it. Now, what's there is between, say, a script? Like I have scripts, I could just automate scripts. Yes, this is where that declarative API and infrastructure as configuration comes in, right? Because scripts, yes, you can automate scripts, but the order in which they run matters, right? They can break, things can break in the middle, and sometimes you need to debug them, whereas the declarative way is much more expressive and powerful. You just tell the system what you want and then the system kind of figures it out and there are these things called controllers, which will in the background reconcile all the state to converge towards your desired state. It's a much more powerful, expressive, and reliable way of getting things done. So infrastructure as configuration is built kind of on, it's a super set of infrastructure as code, because you need infrastructure as code, but then you can configure the code by just saying do it. You're basically declaring and saying go do that. That's right. Okay, so cloud native at scale, take me through your vision of what that means. Someone says, hey, what does cloud native at scale mean? What's success look like? How does it roll out in the future as you, not future, next couple of years. I mean, people are now starting to figure out, okay, it's not as easy as it sounds. Kubernetes has value. We're going to hear this year at KubeCon a lot of this. What does cloud native at scale mean? Yeah, there are different interpretations, but if you ask me, when people think of scale, they think of a large number of deployments, right? Geographies, many, supporting thousands or tens or millions of users, there's that aspect of scale. There's also an equally important aspect of scale, which is also something that we try to address with R on, and that is just complexity for the people operating this or configuring this, right? So in order to describe that desired state and in order to perform things like maybe upgrades or updates on a very large scale, you want the humans behind that to be able to express and direct the system to do that in relatively simple terms, right? And so we want the tools and the abstractions and the mechanisms available to the user to be as powerful but as simple as possible. So there's, I think there's going to be a number and there have been a number of CNCF and cloud native projects that are trying to attack that complexity problem as well. And R-Lon kind of falls in that category. Okay, so I'll put you on the spot, we've got KubeCon coming up and obviously this will be shipping this series up before. What do you expect to see at KubeCon this year? What's the big story this year? What's the most important thing happening? Is it in the open source community and also within a lot of the people jockeying for leadership? And there was a lot of projects and still some white space in the overall systems map about the different areas, get runtime and there's availability in all these different areas. What's the, where's the action? Where's the smoke? Where's the fire? Where's the peace? Where's the tension? Yeah, so I think one thing that has been happening over the past couple of KubeCon's and I expect to continue and that is the word on the street is Kubernetes is getting boring, right? Which is good, right? Boring means simple. Well, Well, maybe. Yeah. Invisible. No drama, right? So the rate of change of the Kubernetes features and all that has slowed, but in a positive way, but there's still a general sentiment and feeling that there's just too much stuff. If you look at a stack necessary for hosting applications based on Kubernetes, they're just still too many moving parts, too many components, right? Too much complexity. I go, I keep going back to the complexity problem. So I expect KubeCon and all the vendors and the players and the startups and the people there to continue to focus on that complexity problem and introduce further simplifications to the stack. Yeah. Vic, you've had a storied career, VMware, over decades with them, I've been with them for 12 years, 14 years or something like that, big number. Co-founder here at Platform, I think I've been around for a while at this game. We talked about OpenStack, that project we interviewed at one of their events. So OpenStack was the beginning of that, this new revolution. I remember the early days it was, it wasn't supposed to be an alternative to Amazon, but it was a way to do more cloud, cloud native. I think we had a cloud, a Roddy team at that time. We would joke about the dream, it's happening now. Now at Platform nine, you guys have been doing this for a while. What's the, what are you most excited about as the chief architect? What did you guys double down on? What did you guys pivot from or to? Did you do any pivots? Did you extend out certain areas? Cause you guys are in a good position right now, a lot of DNA in cloud native. What are you most excited about and what does Platform nine bring to the table for customers and for people in the industry watching this? Yeah, so I think our mission really hasn't changed over the years, right? It's been always about taking complex open source software because open source software, it's powerful. It solves new problems every year and you have new things coming out all the time. OpenStack was an example when the Kubernetes took the world by storm. But there's always that complexity of just configuring it, deploying it, running it, operating it. And our mission has always been that we will take all that complexity and just make it easy for users to consume regardless of the technology, right? So the successor to Kubernetes, I don't have a crystal ball but you have some indications that people are coming up of new and simpler ways of running applications. There are many projects around there. Who knows what's coming next year or the year after that? The Platform nine will be there and we will take the innovations from the community. We will contribute our own innovations and make all of those things very consumable to customers. Simpler, faster, cheaper, always a good business model technically to make that happen. Yeah, I think the raining in the chaos is key. Now we have now visibility into the scale. Final question before we depart the segment. What is at scale? How many clusters do you see that would be a watermark for an at scale conversation around an enterprise? Is it workloads we're looking at or our clusters? How would you describe that? When people try to squint through and evaluate what's at scale, what's the at scale threshold? Yeah, and the number of clusters doesn't tell the whole story because clusters can be small in terms of the number of nodes or they can be large. But roughly speaking, when we say large scale cluster deployments, we're talking about maybe hundreds, two thousands. And final question. What's the role of the hyperscalers? You got AWS continuing to do well but they got their core. They got a pass. They're not too much putting a SAS out there. They have some SAS apps, but mostly it's the ecosystem. They have marketplace is doing over $2 billion billions of transactions a year. And it's just like to sit in there. It hasn't really, they're now innovating on it. But that's going to change ecosystems. What's the role of the cloud play and the cloud native at scale? The hyperscalers themselves. Yeah, AWS, Azure, Google. You mean from a business perspective? Yeah, technical. They have their own interests that they will keep catering to. They will continue to find ways to lock their users into their ecosystem of services and APIs. So I don't think that's going to change, right? They're just going to keep. Well, they got great performance. I mean, from a hardware standpoint, that's going to be key, right? Yes, I think the move from x86 being the dominant way and platform to run workloads is changing, right? And I think the hyperscalers really want to be in the game in terms of the new risk and arm ecosystems and the platforms. Yeah, not a joking aside, Paul Morris, when he was the CEO of VMware, when he took over, once said, and I remember our first year doing theCUBE, the cloud is one big distributed computer. It's hardware and you got software and you got middleware. And he kind of oversimpled, he's kind of tongue-in-cheek, but really you're talking about large compute and sets of services. That is essentially a distributed computer. Yes, exactly. It's we're back in the same game. Vic, thank you for coming on the segment. Appreciate your time. This is a cloud native at scale, special presentation with platform nine, really unpacking super cloud, RLan, open source and how to run large scale applications on the cloud, cloud native for developers and John Furrier with theCUBE. Thanks for watching and we'll stay tuned for another great segment coming right up.