Hybrid Cloud has Won! Now What?
Transcript
(upbeat music) >> Hey, how's it going? This is Keith Townsend, Principal, the CTO Advisor and we're here at VMware Explorer 2023. And there's this company that I've been talking to for the past. How old is RackN now? >> Nine years old. >> Nine years. Oh man, it's hard to believe it's been nine years already. See, for me, I'm not in the trenches, so nine years for me is gone by just like that >> It has been a journey.
Last five have been crazy 'cause we've just dialed in the product. Got it just right. And once that happened, we started watching, that was the beautiful time of like, okay, we really solved the problem, we got everything going. And it makes working just fun. >> So that face and voice you just saw and heard is Rob Hirschfield, good friend, and sponsor of this video, CEO of RackN. So Rob, we're going to talk. We're going to take our conversation in a little bit different direction.
For those who watch the CTO Advisor and read our content, you know that we've taken the position, we've won. Hybrid Cloud has won. The idea that the public cloud is the future and will be where all applications live, it's a afterthought. That's not going to happen. What's going to happen is that we're going to have stuff in Colo, private data center. We're going to have it in the public cloud. We're going to have it in the Edge. And the operating models of that infrastructure is going to swing.
Sometimes you're going to have something like VMware Cloud on AWS. In AWS. Sometimes we're going to have IBM Cloud running on premises. It's going to be different flavors. But if you're an executive, it's terrifying. >> That is terrifying. >> That's a lot of skill sets. It's a lot of locations. It's a lot of rules. That's really hard. >> Yeah, if you're executive, I like the idea of when the thought that said that the destination is public cloud, and I don't have to worry, I don't need to invest in data center.
Those skill sets can atrophy. I can choke the data center and let everything go to the public cloud. Now you're telling me I have to deal with the data center. It's a political and governance nightmare. And then I have folks like RackN, and this is where I'm going to challenge you a little bit, Rob. >> Sure. >> And I have folks like RackN telling me that I need to spend political capital on getting my teams to collaborate on the projects.
We're just going to throw some tools out there. HashiCorp, Terraform. >> Yeah. >> VMware, vRealize or VR, whatever they call it today. I'm sorry, VMware. But you get the point. There's all these tools to do infrastructure as code and I argue RackN, it's not really a development tool, but more of a operations tool. >> Very definitely, yeah. >> And now you're arguing, your argument to me is that I need to spend political capital on getting my team to collaborate on yet another, and I don't want to call it a tool, it is a concept of.
>> When we put RackN together, we were constantly frustrated by what we hear our customers coming back to us with all the time, which was, I have the same stuff, right? I'm using the same tools like you were mentioning. I'm using the same servers or clouds. I'm using the same operating systems. I'm using the same applications on those operating systems. And then every team in my organization is doing it in a completely bespoke way. And so there's not all.
It's really hard to argue that your use of a cloud or an infrastructure or server, right? All the hybrid things you were laying out, that all the variation in that is adding business value. And so the CIOs, CTOs and even up at the CIOs are looking at this stuff saying, wait, why are we doing the same types of stuff differently inside our organization over and over again? And then for RackN, we actually go a step further and we're like, all right, does it really make sense for you to have custom anything at certain levels, right?
Can we turn automation and all of this business logic and all this knowledge into repeatable systems more like software, which is what infrastructure as code to me has always meant. It's like how do I turn my infrastructure into a software experience regardless of where it is? >> So a great example of this is actually ERP. Large organizations have gone away from having multiple ERP implementations of SAP throughout various GOs and business units. Because they ask the very same question of these teams are doing the exact same customizations, they're doing the exact same deployments.
I have all of this overhead. Why can't I consolidate this and have a best practice across my entire organization? So at the end of the day, at the end of the day the value is we can get out the quarterly report financial closings on time. Like there's real business impact to not having the same SAP instance. >> Well, we used to see this all the time, right? Companies would have an ERP instance, they'd have a ton of customization, all this work.
And then that work would have to be maintained, it would take a long time to do, it would slow things down. And we've gotten to a point where it's like, I don't want to do my custom, I want to adapt my business to follow the standards with some salt, right? With some spice mixed into that. And that is, you know really it's powerful when you can show up. And this is one of the things we do is like we have infrastructure pipelines we call which are standard processes to drive infrastructure from one state to another.
So installing VMware, installing Linux, installing Windows, right? Standard processes that just build infrastructure up. And we have all that stuff out of the box. And so when customers sit down with us, they can get out of the business of figuring that out. Just like your SAP example is really good. Like having a bespoke process to close the books is actually anti running your business well, but in IT, we we've gotten really used to having bespoke processes for like setting up servers or installing operating.
None of that's business value added. >> So I think I'm buying the argument for it being an operations tool, because if I equate it to SAP, if I'm thinking CIO versus COO versus CEO, the conversation becomes how do I, at the end of the day deliver business value? 'Cause it's on the COO to take the thing that the CIO built in SAP and operationalize this across the board from logistics to order the cash, to all of these processes to deliver value to the business.
>> You're bringing up a really important point from an operations perspective, and this is where collaboration becomes really important, right? When we look at development tooling, developers are building custom value for the business. And so their tooling ends up starting from the idea of I have something unique to my business and I'm adding it. And then they put it through a pipeline and they go into deployment. And that does tend to be team by team specific where you want to let developers use the tools and platforms that they need to do, but the operation side of the business, actually you want to consolidate that work.
You don't want your teams to have bespoke processes in an operations perspective. That's security and business risk and cost, right? So the operation side and the reason why RackN focuses on the operations component and the tooling is we're actually driving towards the normalization of that infrastructure. >> So I get the end value. I'll make sure I recap this. Infrastructure's complex. It's getting more complex. If we take the Edge, as we take our partners on the OT side and what they're doing and what they're trying to accomplish, and we want from our IT lens to give them best practices and capabilities, and then they look back at us and say, but you have eight different teams doing the same thing, how can you add a ninth or tenth or twelfth team to that?
This makes sense. I have a way to describe infrastructure. I have a way to maintain infrastructure. I have a way to deploy the infrastructure. RackN, makes sense. But in order to get there, I need a operations team that can drive home the capability. One of the things that I consistently tell when I'm leading teams and someone comes to me with change, the first thing I ask is, how can I trust it? What I've done in the past has worked and there's very little political capital win for me if I come onto your new solution.
I know you've heard this. >> It's a challenge and this is where collaboration is actually hard because if you're going to collaborate with another team, then there's times when you are doing service for that other team, right? They add something to your environment and it breaks into the shared environment and it breaks you. And you're like, if only I hadn't collaborated, I wouldn't be broken. And we definitely see a resistance from this loss of control or this increased collaboration, right? There is a degree of I have to service other people's work.
I have to give up some control. I'm not as protected. But the cost and this is what we see, 'cause we help customers build these integrated pipelines that cross silos and create standard API driven infrastructure. And the benefit of the acceleration they get is enormous. But they've had to come back and say for individual actions you actually might be a little bit slower, right? And work at a pace where you're like, well, it is a benefit to me to get this other, to work with these other groups because then things flow in.
With our customers, because we're able to share automation across customers, they actually get things coming in across their customer base and then RackN adds an abstraction. So we're not like asking rival banks to share their operational logic. That's just the opposite. But what we are doing is we're going across all these operational components, providing curation and a degree of isolation so that individual customers stay in control, but they get the benefit of using other people's learning. >> And this is no different than what we're seeing with the cloud providers with AWS.
AWS takes the learnings from multiple customers and gives a blueprint for cloud formation or Terraform or one day to see some RackN stuff in there. But the point is that the collaboration has a long term tail from a payoff perspective, we've seen it happen. Some great examples of this is Brian Chambers who's a fellow tech field delegate, and also I think he's the director of architecture at Chick-fil-A famously did the Kubernetes on, what was it? The intel notes. >> Notes, yeah.
>> And he talked about how massively successful the project was, but if he could have changed anything, he would've moved it to operations much quicker than what he did, as opposed to having it in the infrastructure. >> And there's a ton of operations teams right now like shrinking inside. >> I don't want that. >> But a lot of operations teams are challenged to move quickly. Because they end up building a lot of things and then they end up supporting a lot of things.
And you can find it in operations teams are perceived as slowing down innovation. But yeah, so he was, he was saying he wanted to transition to operations or he wanted to involve them more? >> He wanted to involve them, or at least have them earlier on in the process. One of the great things about architecture group it's a skunk work, and you can get the POC out quickly. >> Yeah. >> But if you're not walking hand in hand with your operations team, when it is time to quote unquote throw it over the wall or transition into operations, it takes longer because you didn't do the up-level work.
Contrast that to who did it well? Netflix, the Netflix journey to the cloud is that they allow their developers to put these used Java monoliths into a container and just gave it to operations. The operations deployed the containers and the developers over time picked apart the monoliths and turned them into microservices when it made sense. >> Right, and I think that looking at lessons like that, where, especially for Netflix, where they added a lot of operational constructs, they initiated a lot of operational constructs, like with their chaos engineering groups with circuit breakers, right?
With the way they did CICD. What they recognized is you could collaborate with operations if you build tooling and infrastructure around that. But that takes architectural discipline. It takes time. What we find in enterprise is a lot of times somebody builds something really quickly or to solve a specific problem and they don't have the architectural experience to build a bigger solution and complexity. Complexity can multiply exponentially and it's very hard to solve. >> So what I'm hearing from you is that this isn't I don't know, this is just something you can pick it up in a book.
I think there's, I think there's examples on the business side of how to operationalize and do collaboration. I think there's plenty of that on the pure business side. When you're talking about building infrastructures and operations, this seems like more hand to hand battle than it does. >> There's an element here from a leadership perspective where the leaders need to be measuring things that drive collaboration. They need to be asking, why is this department doing something unique, right? When we look at some of the platform engineering success work the platform engineering outside of a hype that has been getting from a development portal, but you know, real base platform engineering we've see in our customers, that's where the leadership in those organizations are really turning and saying, how do we have consistent repeatable patterns?
And then incent people to use those patterns and then build, the challenge you also have to build the patterns and then you have to maintain the patterns. But the leaders in the organizations need to be doing what they're supposed to do, which is crossing teams and finding out, asking the hard questions of why didn't you align with another team? Or why didn't you pull this expertise out of your group and let us build a platform engineering effort so that that service could be more portable.
And that protects, we have, we see this a lot, this is what's interesting about this whole leadership thing. Sometimes the leadership thing isn't even a thing. Don't do that. Some of it's like you can't have a dependency on one or two expertise elements in your organization or on your team. And pulling out those, those bus factor risks of whether or not a person, you have the skill sets to maintain an operation in your team and you don't want to. >> So if you're a director of IT infrastructure, you're a VP of IT infrastructure or development and you have kind of this disorganized initial thought of how do I go about this approach?
It sounds like you have a good number of ideas. How do people reach out to RackN? 'Cause this seems like an opportunity some consultation and say, hey, maybe you should think about it this way. >> RackN is really designed as a software product. And one of the simple reasons is that we want to be able to help our customers run their own infrastructure. We're not trying to create a dependency, right? Our customer independence is actually one of our top priorities in any interaction.
But what we've done that's really different is when we built the platform, we put the collaboration first. We put the complexity management and exercising systems first. And so what we really looked at was not how to solve an individual team's problems, but inherent in the software is this idea that I'm going to collaborate around my automation. I'm going to reuse my automation, I'm going to make it portable. And so when we sit down and show customers how to build infrastructure and automation, part of what we have to do is we actually have to show them, this is a chance for you to build something that has durability outside of what that one team does or outside of what that one problem does.
And actually negotiate. And this is fun 'cause we'll negotiate with our prospects and customers where they want the line to be in custom code and be able to say, you know what? This is a standard use case. We see this need across our customer base. We'll actually take over operational concerns from them from a soft building and maintaining the automation. They'll still run the software, but we'll actually embed that into the product so that they don't have to maintain it.
And so in ideal circumstances, we actually watch our customers bespoke custom parts of their systems drop over time rather than go up over time. And that is the thing that I think as a leader in these organizations, especially with AI and MML coming, where it's becoming super cheap for people to build new stuff and then have to maintain it. The leaders need to be taking an approach. And this is where we get consultative and help of how am I making sure that my unique value added pieces are actually unique value added pieces.
And all of the other noise actually decreases over time. And ideally you would have a KPI that measures and we help customers actually have KPIs that measure how much custom bespoke automation they have versus out of the box automation. And if that number isn't driving to less and less custom, then you're doing it wrong. And sadly, most organizations that we interact with initially, they have enormous amounts of, custom automation stuff that they're maintaining. And they're paying teams to do nothing, but churn away on things they wrote that have actually very little business value.
>> So this has been a microcosm of a lot of discussions that I've had, teams building automations and discovering that there's a lot of value in that initial deployment of automation. And then realizing, oh, I needed a system for managing the complexity of the automation. It is a vicious cycle and is why automation has gotten a bad rap over the years. com visit the YouTube channel. VMworld 2023 has been a smorgasburg. I like that word, I'm hungry, of content, not just about leadership, but technology itself.
You can DM me on Twitter. com, did we hit the high points? Are there questions for me or Rob? Happy to pass 'em along at CQ advisor. Talk to your next CTO advisor studio.
