 Hi, this is Yohsapan Bhartiya and welcome to another episode of T3M, our topic of this month. And topic of this month, obviously, was about KubeCon, CloudativeCon, and specifically complexity of Cloudative applications and workloads. And today we have with us, once again, Rob Hershel, CEO and co-founder of Reckon. Rob, it's great to have you on the show. Rob, it's a pleasure to be here. This is an exciting topic. Yeah, I missed you at the show, but I'm happy that we can discuss the show here today. I'm pretty sure, like always, you were tracking KubeCon, CloudativeCon. Was there any specific theme or any specific discussions, especially when it comes to cloud complexity that popped up or that you noticed? The ongoing theme that we continue to see is just the number of moving parts involved in Kubernetes. And so we see quite a bit of challenge for people trying to understand what they need to do with Kubernetes, how they use it, who to buy it from, how to support the vendors, how many Kubernetes clusters they have set up and managed. And it's a stunning thing to me because, without a doubt, Kubernetes has reached a critical mass in adoption. And we're still struggling with some of these very basic issues like how to create a service match. One of the things I was very excited to see was more collaboration around gateways and standardizing gateway technologies so that some of the service mesh debates and wars hopefully will settle down a bit. And I think that'll let people move with a lot more confidence in building these systems or at least picking, not stressing as much over picking a vendor, or that's finding places where variances are going to come into different systems that they pick. When we look at this cloud native of Kubernetes, complexities, challenges, what are some of the core challenges that your users are facing from a very, very practical perspective? For us, one of the things that we see in our user base is they do not have a concrete preferred Kubernetes vendor. And that is a good thing in that they feel like they can have a degree of portability. But the idea that you would have one Kubernetes vendor is we have not seen that emerge as a standard, right? On premises, there's a handful of vendors VMware and Red Hat are dominating. Each cloud has their own capability, their own option. And you were saying it's great that there's choices. One of the things that really contributes to complexity is the variations that creep in between different environments. And choice is really important. We see this on the bare metal hardware side all the time. Our vendors need, and it's very important for them to have vendor options and flexibility, not just from a supply chain perspective, but so they can pick the appropriate hardware vendor for their use case. Same thing with Kubernetes. You want to pick the appropriate Kubernetes vendor for your use case and also have options so that you're not locked in. Those choices do contribute to complexity, useful complexity in people's environments. And what we're stuck with on the other side of it is helping customers manage that complexity and eliminate it. You have to have ways to manage it. But it's part of the ecosystems that we have. And we hear people talk a lot about complexity. This is the topic of the day. And we don't hear people really coming back with very meaningful answers on how to address the complexity. It's something Rackand actually spends a lot of time talking to customers about and working on architecturally. How much you have seen that this clouded word has kind of dodged that vendor lock in bullet? Or you think that no, that challenge still remains for customers? An excellent question. To a large extent, Kubernetes has done a good job having the API be portable across different vent providers. And that's been a remarkable thing. It contributes a lot to the industry. But we actually don't have a lot of insight into what the implementations are behind those systems. And because Kubernetes has such a complex ecosystem, individual vendors' choice about which parts of that ecosystem they've implemented and how they implement it can create variations that you're going to have to deal with as a customer. And so one of the challenges that you have with Kubernetes having such a broad ecosystem is this vendor, this sequence, this platform has these components implemented, linker D versus Istio. And so until we have gateways that standardize those things, which are in the works, then you end up having a lock-in effect because one vendor chooses to implement one set of the ecosystem and another vendor chooses a different side of the ecosystem. And that's a challenge because of the way Kubernetes is formed. I think it's a benefit to the community in general. It's definitely a benefit to the vendor community where they can enter and be part of Kubernetes without having to conform to somebody else's project. But it's very confusing to the users. It presents a lot of options. It means that technology comes into market that is going to have to go through several iterations because companies are trying to establish a first place or a first name in a certain industry. It's part of the open source ethos. And it's also very hard for customers to adopt from a production perspective. And one of the things that you see is a lot of use of Kubernetes, a lot of different vendors, but you have to make narrowing decisions to get things into production. You did a series on platform engineering and one of the challenges with platform engineering is everybody's doing everything. And that's very tricky for companies to support in an operations production perspective. And so the funnel has to narrow for Kubernetes to reach another tier. But it's not clear yet that the vendors have a lot of incentives to keep aligning around an increasing set of functionality. It's just the opposite, right? We see the functionality sets continue to increase. And from Racken's perspective, we ultimately were a software company. We like to see people running systems and doing things themselves and having autonomy and making choices for that. And the best open source, in our opinion, is ones where people actually have a lot of control over the software that gets run. And we're not there at the moment with Kubernetes. Most people are hosting the software or consuming it in very prescribed ways. And as we were talking about this complexity, I want to see because Kubernetes is being used in production, of course, depending on who you're talking to. Can you talk about how companies are dealing with this complexity or what is the best way? Because the thing is this complexity is not going to go away. Just the way we look at security, security is not going to become easy. What we have to do is to make it easier for users to be aware of entry. So despite all this complexity, as you also said, we are not going to eliminate the complexity. We have to just enable our customers to be able to deal with it. We seem to as an industry be running around looking at the sky and complaining about complexity. And what I like to remind people of, and this is actually part of Racken's architectural philosophy in general, is the antidote to complexity is not simplicity. It's not giving things up. It's giving users or reducing the pieces and parts that you have. We've actually been moving consistently in the opposite direction, and we don't expect people to do that. The antidote for complexity is exercise, which means that when you have systems that are highly complex, what you want to be able to do is use them, automate them, run them. And the way that we get a complex system to be more maintainable and less scary is by using the parts of the system on a regular basis. We like to talk about this from a hardware perspective. The idea that you would set up a server and just run it for years and years and be excited that it never went down is over. The way that you deal with any type of infrastructure is that you exercise it, you reset it, you reboot it, you patch it, you replace it. That type of highly dynamic environment where you're running the system really combats the complexity of that system. And you might think, oh wait, I'm using the system more, I'm just going to break. And that's exactly the point. You're actually exposing the weak points. You have a chance to address issues as they arise. That type of engagement with the systems that you're using and then automating them so that they are resilient and robust, that actually makes the system itself much more resilient and makes the complexity less scary. Because what we're really talking about with complexity is not that the system is complex, what we're really saying is I am worried about the risk that I won't understand what broke. Or I'm worried about not being able to bring in and make changes to it because I don't understand the failure modes or what the change could do, what are the ripple implications. And the way you deal with any of those types of risks is literally you run the system more so that you're confident that you understand its behavior. And that's a really important point for how people need to deal with this. If you think you're going to buy Kubernetes, bring this back to Kubernetes, and set it up, install your application on it, and then walk away. And I think you're not thinking about cloud native correctly. You're not talking about dealing with complexity. The best way to deal with Kubernetes infrastructure or really any infrastructure in the modern era is to have ways that you are constantly tweaking, tuning, patching, updating, running it through the extent of its capabilities. That is the best defense against complexity. When we talk about complexity or when we talk about reliability, I do want to talk, as you said, we talked about platform engineering, SREs. I had a very great session yesterday around observability as well. And the point, the same thing came up that their vendor, their confusion, a lot of awareness is still needed. And when it comes to breaking the systems, what are your thoughts about how many companies, because once again, things are overwhelming when we throw a jargon at them, companies get scared. The whole chaos engineering approach where you are constantly testing your systems. How much are you seeing that and is rack and playing any role in that space as well? We do help customers a lot in helping them automate systems and do it reliably. What I see happening in market is there is a real automation reliability crisis. If you sit down and ask people how confident are they that their automation will run, they are always confident of the things they just wrote or they just ran. But if you ask them, you haven't touched it in a week or two weeks or a month or six months, their confidence in the systems really goes way, way down. Once again, exercising helps keep the systems fresh. But we need to be able to be very confident that systems will continue to run and operate as we automate them. I've seen a lot of projects where people spend millions of dollars in person years of effort to automate systems and then don't feel like they can reliably do patches and upgrades and run the system or copy that automation site to site to site and use it across their industry without a lot of manual intervention. That is a crisis. We don't have the luxury to be building automation that is bespoke and specialized. We really have to have ways to have portable automation, reusable automation. It's actually a core element of what Rack End does is actually look at ways to build automation where we are modularizing, decomposing, creating reusable parts of that automation. What that means is that that exercise phenomena we just talked about happens across our customer base. Happens across our customer's teams. Happens on an ongoing basis. If you aren't running that automation, somebody else is and you get the benefit of that cross industry experience. That's a very different outlook than the way we typically approach automation. It's a serious problem if you're dealing with systems and you're not 100% confident that you're going to push that button and it's going to do what you think it's going to do, then we have a really serious challenge behind that, building that automation. The discussions we're having around developer portals and things like that really are meaningless if when the developers ask for an environment, if that environment doesn't come up reliably, it doesn't get built to spec, you're actually not doing any work that's going to help the developer. They're going to be bypassing that system inside of a week. The systems need to work and we have to invest the time pay down the technical debt and embrace architectures that actually encourage robustness and reliability in the automation, which you can only do through code reuse. I'll go back to KubeCon or other events that are coming up. What role do you see that these events play where all the different players from the whole ecosystem, not just vendors, not just developers, but users. We saw developers, DevOps, SRs. I mean, it was very, very diverse use. Do you think that these events are also kind of helping users by bringing them together to kind of not only talk about this complexity but also sessions are there to tell them, hey, how you can, as you said, deal with this complexity because the complexity is not going away? I think Kubernetes is in transition from being a developer of Kubernetes conference to a user operator developer for Kubernetes conference. And Kubernetes as a community really needs to embrace that or figure out how that's going to work. I know I heard a statistic that half of the people at KubeCon were new to this was their first KubeCon, which means that we have people coming in who are there looking at Kubernetes as a product, right? And not as a I want to write Kubernetes code per se. That transition is actually a very tricky transition and we need to understand as an industry how we're going to help people use that product. And it's also going to be a new wave of innovation not on Kubernetes itself, but on helping people use Kubernetes in ways that combat the complexity or exercise the systems or have better reuse models. That sort of usability layer on top of the platform is key but I think we're going to have to embrace those users and look at what they need. We do not see from an enterprise and we're back into a lot of enterprise customers and work with them from a customer perspective. There's a lot of interest in Kubernetes and how Kubernetes works. We are still very early in the journey for these companies really embracing tool chains above and around Kubernetes. And that's going to be the next phase of innovation here, but in a conference like KubeCon it's going to have to figure out how to bring that group of people into the fold. It's a different user base. Thank you so much for taking time out today and talk about Kubernetes complexity and what I loved what you said was that the complexity is not going to go away. We have to learn or help our users deal with it. Thanks for that and I would love to chat with you again. Thank you. Looking forward to it. Thank you.