 from our studios in the heart of Silicon Valley, Palo Alto, California. This is a CUBE Conversation. Hello and welcome to the CUBE Studios, Palo Alto, California for another CUBE Conversation. We go in depth with thought leaders driving innovation across the tech industry. I'm your host, Peter Burris. It's a well-known fact of life at this point in time. We're going to the cloud. In some manner, way, shape, or form, every business that intends to undertake a digital transformation is going to find themselves in a situation where they're using cloud resources to build new classes of applications and accelerate their opportunities to create new markets that are more profitable. What folks haven't fully internalized yet though is what it means to govern those activities. What does it mean to use data that is in the cloud in a compliant and reliable way? What does it mean to allow rapid innovation while at the same time ensuring that our businesses are not compromised by new classes of risk, new classes of compliance issues as a result of making certain liberties with how we handle governance? So that's what we're going to talk about today. We've got a great conversation for you. Toby Knapp is a co-founder and CTO of Day 2 IQ and Charlie Betz is the principal analyst and forester. Toby, Charlie, welcome to theCUBE. Peter. All right, so Charlie, I'm going to start with you. I kind of outlined the overall nature of the problem, but let's get it very specific. What is the problem that enterprises face today is they try to accelerate their use of technology in a way that doesn't compromise the risk and compliance concerns. Well, we are hearing the same story over and over again, Peter. Companies are starting on a cloud native journey and perhaps a DevOps journey. There's some similarities there. One leads to the other in many cases. And they do a proof of concept and they do a pilot and they like the results, but both of those efforts had what from monopoly we would call a get out of jail free card. They had a pass to bypass certain regulatory or governance or compliance controls. Now they want to scale it. They want to roll it out across the enterprise and you can't give every team a get out of jail free card. Well, let me dig into this because is it that the speed with which we're trying to create new things is that the key issue? Is it that the new technologies like Kubernetes lend themselves to a new style that doesn't necessarily bring good governance along with it? What is, what are those factors that are driving this problem? I think the central factor, Peter, is the movement from stage gated governance to governance of continuous flow. And we get unpacked this in various ways, but really if you look at so many governance models and people ship them to us and we comb through them, and it's getting, you know, doing a lot of that lately, what we see is over and over again, this idea that delivery pauses, experts come in from their perspective with a checklist, they go through, they check the delivery against the checklist and then the green light is given to move on. And this is how we've run digital systems for a long time now. But now we're moving towards continuous flow, continuous iteration. Agile. Agile. DevOps. DevOps, all the rest. And these methods are well suited to be supported by architectures like Kubernetes. And there are certain things you can do with automation that are very beneficial in cloud native systems. But you're up against, you know, decades of policy that assume this older model is based on older guidance like Eitel and Pimbok and COVID and all the rest. COVID 2019 is still based on a plan, build, run model. Which is not, is not necessarily a bad thing in the grand scheme of things, but it doesn't fit into a month long sprint. It doesn't fit. And more and more what we're seeing when I say stage gates are going away, what we're seeing is that the life cycle becomes internalized to the team. You still plan, build, run, but it's not something that you can put controls on at the high level. And so the solution seems to be is that we need to be able to foster this kind of speedy acceleration that encourages the use of Agile, leads to a DevOps orientation and somehow fold good solid governance practices into the mix. What do you think the, let's take a look at 2025. What's it going to look like? And even if we're not ready for it yet. Well, I think you're going to govern a lot more at the level of the outcome. You're going to govern what, not how as much. But there are a lot of things that still are essential and just basic solid good practice, such as not having 15 different ways or a hundred different ways to configure major pieces of infrastructure. You know, there's in the, some of the reports, the state of DevOps report that came out, there was a note in there or a finding in there that it was best to let the developers have a lot of choice. And I understand that developer autonomy is very important, but every time a development team chooses a new technology or a new way to configure an existing technology, that's an expansion of attack surface. And I'm very concerned about that, especially as we see things like Equifax with the struts exploit. You know, we have to keep our environment secure, well-patched, up to date. And if you only have one or two ways that things are configured, that means your staff are more likely to do the right thing as opposed to, you know, infinite levels of variation, you know, on a hundred different ways of configuring Kubernetes. Well, presumably we want the infinite levels of variation to be revealed at the business level and not down at the infrastructure level. I think one of the things that folks mean or folks are intending or hope to be able to do with digital business, you're alluding to this, is create a digital asset, a software-based asset, because ultimately it's going to be more integratable. But you lose the opportunity to integrate those things if you're increasing the transaction costs by introducing a plethora of discordant governance models. Is that what you're seeing as well, Toby? Absolutely, and I think, you know, some aspects of cloud native that make this problem a lot bigger is actually, you know, cloud native encourages sort of a self-service model for infrastructure. And also we're seeing a shift of power and decision-making towards developers, right? So you have developers introducing a lot of these new stacks, often in a very, you know, sort of bottoms-up organic way. So very quickly, an enterprise finds themselves with, you know, 10, 15 different ways to provision infrastructure, to provision Kubernetes clusters. And often, you know, the teams that are in charge of governance aren't even aware of these things, right? Yes. So I think it starts actually with that, you know, how can we find this balance of giving developers the flexibility they want, you know, having them leverage the benefits of cloud native, but at the same time, making the folks that are in charge of governance aware of what's going on in their enterprise, making them aware of the different stacks that are provisioned, and then finding the right balance between that flexibility and enforcing governance. There's ways to do that. You know, what we see a lot is waste people building one stack on cloud provider A, a different stack on cloud provider B, a third stack, you know, at the edge, or in the data center. And so when it comes to patching security issues, upgrading versions, you know, you're doing three, five times the amount of work. Well, let me ask you a question, because we can see that the problem is this explosion in innovation at the digital level that is running into the stricture of historical practices and as a result, people are in running governance. What is it? I mean, if I think about this, it sounds to me like the developer tooling is getting better faster than the governance tooling. Where are we in the marketplace in terms of thinking about technologies that can improve the productivity on the governance side so that we can bring governance models to the developer so they don't have to make decisions at that level? Right. I think where we are in the market is, so obviously cloud native and Kubernetes specifically has seen rapid adoption in the enterprise, right? And I think, you know, the governance frameworks and tools are just now catching up, right? Right. So the typical journey we see is, you know, folks try out Kubernetes, they try out cloud native technologies. They have a very good first experience. It's easy. And so they kind of, you know, forget some of the best practices that we've learned over the years for how to secure a production stack, how to make it upgradeable, maintainable, how to govern workloads and versions, because those tools just simply didn't exist so far. We're now seeing these tools emerge. And really, it's the same approaches that have worked for us in the past for running these types of infrastructure. It's, you know, having a central pane of class for visibility, what versions am I running? You know, first being aware of what's out there and then, you know, centralizing management of these stacks, how do I, you know, lifecycle manage my Kubernetes clusters and all the related technologies? Those are the tools that are just now showing up in the market. But it's also got to, I presume, that a degree of presuming that the tooling itself does bring forward good governance practices into a modern world. Have I got that right, Charlie? Yeah, absolutely. I think this is one of the key things that the updated INO team, infrastructure and operations, and our view is that these become platform teams. So maybe we leave the INO term behind. We go with the platform teams. This is one thing that they should be doing is creating reference implementations. You know, here's your hello world stack and it's perfectly compliant. Go solve your business problem and leave the undifferentiated heavy lifting to us. And this is, I think, should be a welcome message assuming that the stack is providing all the services that the developer expects. Well, it certainly suggests that there is a reasonable and rational separation of duties and function within a business so that people that are close to the business are building the function that the business needs are out there doing it. Meanwhile, we've got infrastructure developers that are capable of building the platform that serves this multitude of purposes with the specificity required for each workload and in compliance with the overall organization. There's a key message that I want to reinforce with the audience. As we think about the future of INO, we've been thinking a lot about it at Forester. What is the future of the traditional INO organization? If I say infrastructure, that implies application and I'm talking about a stack, that doesn't go away. You know, there will always be a stack, a layered architecture. What is being challenged is when I say operations, that implies dev and I'm talking now about a life cycle. That's what's merging together. And so while the life cycle becomes something that is held internally within your feature or component team and is no longer a suitable topic of governance, absolutely in terms of the layered infrastructure, this is where it's still a thing. You know, because yes, we will have platform teams, component teams, feature teams facing the business or the end user. But it's all back to the idea that a resource is a reasonably well-bound, but nonetheless with the appropriate separation of function that delivers some business outcome and that's going to include both infrastructure at a software level and application at a software level. So look, Toby, you spend a lot of time talking to customers about these issues. When they come back to you, where are you seeing successes most obviously and why? Yeah, so where we see successes is where, you know, organizations figure out a way to give developers what they want, which is in the cloud native spaces, every development team wants to own their own Kubernetes cluster. They want to, is there a sandbox? They want to install their own applications on there. They don't want to talk to a different team when they install applications. So how can you give them that while at the same time enforcing the standards that you need to, right? How do you make sure those clusters follow a certain blueprint that have the right access control rules? You know, sensitive information like credentials are distributed in the right way. The right versions of workloads are available. Organizations that figure out how to do that, they are successful at this. So they govern that from a central place. They have, you know, a central pane of glass, you know, like our product commander where they essentially set up blueprints for teams. Each individual team can have their own cluster. It gets provisioned with this blueprint. And then from the central place I can say, all right, here is what my production clusters should look like, right? Here are the secrets that should be available. Here are the access control rules that need to be set. And so you find the right balance that way, right? You can enforce your governance standards while at the same time giving developers their individual clusters, their development, their staging their production clusters. And here's the options and what is an edible option and what is not. Right. So it seems to me as if I mentioned this earlier, but think about digital business. It's the opportunity to not only turn process or increasingly digitize process, but the real promise also is to then find ways of bringing these things together, integrate the business in response to new opportunities or new competitive factors or regulatory factors, whatever else it might be and literally reconfigure the business quickly. That has to be more difficult if we have a wide array of governance models and operational principles. Charlie, as you think about customer success, what does it mean for the future to be able to foster innovation with governance so that the whole thing can come together when it needs to come together? Well, I think that we need to move to governing again, as I said earlier, governing what, not how. I believe that teams should be making certain promises and there's a whole idea of a promise theory that's out there, a guy named Mark Burgess who is well-known in certain infrastructures, code circles. So what are the promises that the team makes within the larger construct of the team of teams and is that team being accountable to those promises? And I think this is the basis of some of the new operating models we're seeing like Holocracy and Teal. I think we're in very early days of looking at this, but yeah, you will be held accountable for objectives and key results, but how you get there, you have more degrees of freedom. And yet at an infrastructure level, this is also bounded by the fact that if this is a solved problem, if this is not interesting to the business, you shouldn't be burning brain power on solving it. And maybe it was interesting a couple of years ago and there was a need to explore new technologies, but really the effort should be spent solving the customer's problems. Charlie Betts, principal analyst at Forrester, Kobe Knot, co-founder and CTO of D2IQ. Thanks very much for being on theCUBE. Thank you. Thank you, Peter. And thank you for joining us for another CUBE Conversation. Once again, I'm Peter Burris, see you next time.