 Okay, welcome back to SuperCloud 2, live here in Palo Alto, California for our live stage performance. SuperCloud 2, it's our second SuperCloud event. We're going to get these out as fast as we can every couple of months. It's our second one. You'll see two and three this year. I'm John Furrier, my coach, Dave Vellante. A panel here to break down the SuperCloud momentum, the wave, and the developer impact that we're bringing back Vittorio, Viringo, who's a VP for cross-cloud service at VMware, and Sarbit Joao, industry influencer and analyst at Stack Payne, his company, CUBE alumni and influencer. Sarbit, great to see you. Vittorio, thanks for coming back. Thanks for being here. My pleasure. Vittorio, you just gave a key note. We unpacked the cross-cloud services, what VMware is doing, how you guys see it, not just from VMware's perspective, but VMware looking out broadly at the industry and developers came up and you were like, developers, developers, developers. Kind of a goof on the Steve Ballmer famous meme that everyone's seen. This is a huge, Sarbit, a big piece of it. The developers are the canary and the coal mines. They're the ones who are being asked to code the digital transformation, which is fully business transformation. And with the market, the way it is right now in terms of the accelerated technology, every enterprise grade business model's changing. The technology is evolving. The builders are kind of, they want to go faster. I'm saying they're stuck in a way, but that's my opinion, but there's a lot of growth. The impact, they got to get released up and let it go. The developers need to accelerate fast. So it's been a big part of productivity and the conversations we've had. So developer impact is huge in SuperCloud. What do you guys think about this? We'll start with you, Sarbit. Yeah, actually developers are the masons of the digital empires, I call them, right? They lay every brick and build all these big empires. On the left side of the SDLC or the, when you look at the system operations, developer is number one cost from the economic side of things and from technology side of things, they are tech hungry people. They are developers for that reason because developer nights are long, hours are long, they forget when to eat, I've been a developer, I still code. So you want to keep them happy, you want to hug your developers, we always say that, right? Victoria said that earlier. The key is to, in this context, in the SuperCloud context, is that developers don't mind mucking around with platforms or APIs or new languages, but they hate the infrastructure part. That's the fact. They don't want to muck around with servers, it's friction for them. It is like they don't want to muck around even with VMs. So they want the programmability to the nth degree. They want to automate everything. So that's how they think and Cloud is the programmable infrastructure, industrialization of infrastructure in many ways. So they are happy with where we're going and we need more abstraction layers for some developers, by the way. I have this sort of thinking frame for last year or so. Not all developers are the same, right? So if you're a developer at an ISV, you behave differently. If you're a developer at a typical enterprise, you behave differently or you're forced to behave differently because you're not right. Developers have changed. I mean, Victoria, you and I were talking earlier on their keynote, and this is kind of a key point, is what is a developer these days? If everything is software enabled, I mean, even hardware interviews we do with NVIDIA and Amazon and other people building Silicon, they all say the same thing. It's software on a chip. So you're seeing the role of software up and down the stack and the role of the stack is changing. The old days of full stack developer, what does that even mean? I mean, the cloud is a half a stack kind of right there. So developers are certainly more agile, but cloud native, I mean, VMware is epitome of operations, IT operations. And Tanzu initiative you guys started, you went after the developers to look at them and ask them questions, what do you need? How do you transform the ops from virtualization? Again, back to your point. So this hardware abstraction, what is software? What is cloud native? It's kind of messy equation these days. How do you guys grok all that? I would argue that developers don't want a super cloud. I dropped that up there. So why not? Because developers, they, once they get comfortable in AWS or Google, because they're doing some AI stuff, which is very trendy right now, or they are in IBM, any of the IPA skater, professional developers, system developers, they love that stuff, right? Yeah, the infrastructure gets in the way, but they're just, the problem is, and I think the super cloud should be driven by the operators. Because as we discussed, the operators have been left behind because they're busy, they're busy with day-to-day jobs. And in most cases, IT is centralized, developers are in the business units, right? So they're going, they get the mandate from the top, say our bank, they're competing against, they gave teenagers or like young people the ability to do all these new things online and Venmo and all this integration, where are we? Oh yeah, we can do it, and then build it, and then deploy it, okay, we caught up. And now the operators are back in the private cloud trying to keep the backend system running. And so I think the super cloud is needed for the, primarily initially, for the operators to get in front of the developers, fit in the workflow, but lay the foundation so it's secure. So I love this thinking because I love the RIF, because the RIF points to what is the target audience for the value proposition. And if you're a developer, super cloud enables you, so you shouldn't have to deal with super cloud. What you're saying is, get the operating environment or operating system done properly, whether it's architecture, building the platform. This comes back to architecture platform conversations. What is the future platform? Is it a vendor supplied, or is it customer created platform? So developers want best of breed, is what you just said, right? And operators, because developers don't want to deal with governance, they don't want to deal with security, they don't want to deal with spinning up infrastructure, that's the role of the operator, but that's where super cloud enables to John's point, the developers. So to your question, is it a platform where the platform vendor is responsible for the architecture, or is it an architectural standard that spans multiple clouds that has to emerge? Based on what you just presented earlier, Victoria, you are the determinant of the architecture, it's gotta be open, but you guys determine that, whereas the Nirvana is, oh no, it's all open and it just kind of works. Yeah, so first of all, let's all level set on one thing. You cannot tell developers what to do. Right, great. At least great developers, right? You cannot tell them what to do. That's what, I want to sort of. You can tell them what's possible. If you tell them what's possible, they'll test it, they'll look at it, but if you try to jam it down the throat, you can't tell them how to do it. Answer the question that we really had. So I think we need to help them build an architecture, but it cannot be proprietary. It has to be built on what works in the cloud. And so what works in the cloud today is Kubernetes, is a number of different open source projects that you need to enable and then provide, use this. But when I first got exposed to Kubernetes, I said, hallelujah, we had a runtime that works the same everywhere, only to realize there are 12 different distributions. So that's where we come in, right? And other vendors come in to say, hey, no, we can make them all look the same. So you still use Kubernetes, but we give you a place to build, to set those operation policy once, so that you don't create friction for the developers because that's the last thing you want to do. Yeah, actually coming back to the same point, not all developers are the same, right? So if you're an ISV developer, you want to go to the lowest sort of level of the infrastructure and you want to shave off the milliseconds to get that performance, right? If you're working at AWS, you're doing that. If you're working at scale at Facebook, you're doing that. At Twitter, you're doing that. But when you go to DMV in Kansas City, you're not doing that, right? So your developers are different in nature. They are given certain parameters to work with, certain sort of constraints on the budget side. They are educated at a different level as well. Like they don't go to that end to the degree of sort of automation, if you will. So you cannot have the broad stroking of developers. We are talking about a citizen developer these days. That's extreme. The low code. Yeah, the low code, no code. On the extreme side. On one side, that's citizen developers. On the left side is the professional developers. When you say developers, your mind goes to the professional developers, like the hardcore developers. They love the flexibility, you know? Well, app developers too, I mean. App developers, yeah. Yeah, but you're right. App infrastructure, platform developers, app developers, yes. But there are a lot of customers, the spectrum you're saying. Yeah, the spectrum. A lot of customers don't want to deal with that muck. Yeah. Like you said, AWS, Twitter, the sophisticated developers do, but there's a whole suite of developers out there that just want tools that are abstracted. Within a company, within a company, like how I see the SuperCloud is, there shouldn't be anything which blocks the developers, like their view of the world, of the future. Like if you're blocked as a developer, like if something comes in front of you, you are not a developer anymore, believe me. You will go somewhere else. First of all, I mean. You will leave the company, by the way. There you go, quit. Yeah, you will quit. You will go where the action is, where there's no sort of blockage there. So like if you put in front of them like a huge amount of abstraction, they don't like it. So they don't like it. Well, the idea of a developer, let's get into it, because you mentioned platform, you're in the term platform engineering now, platform developer. You know, I remember back on, and I think there's still a term used today, but when I graduated with a computer science degree, we were called software engineers, right? Do people use that term, software engineering, or is it software development? Or they're the same? Are they different? So who's engineering what? Are they engineering? Are they developing? Well, I think it's the, you made a great point. There is a spectrum, I mean, I was blessed to work with Adam Bosworth. That is the guy that created some of the abstraction layer, like Visual Basic and Microsoft Access. And he had, he made his whole career thinking about this layer. And he always talked about the professional developers, the developers that, you know, give him a user manual, maybe just go at the APIs or build anything, right? From system engine, down there. And then through abstraction, you get the more the procedural logic type of engineers, the people that used to be able to write procedural logic in Visual Basic and so on and so forth. I think those developers right now are a little cut out of the picture. There are some no-code, low-code environment that maybe gets into some traction, but I caught up with Adam Bosworth two weeks ago in New York, and I asked him, what's happening to these high-level developers? And you know what he told me, and he's always a little bit out there, so I'm gonna use his thought process here. He says, chap GPT. I mean, we'll get to a point where the high-level procedural logic will be written by computers. Computers, and so we may not need as many at the high level, but we still need the engineers down there. The point is the operation needs to get in front of them. But wait, wait, you've seen the chat GPT meme, I don't know if it's a Dilbert thing, where it's like, time to develop the code, five minutes. Time to decode and debug the code, like five hours, so you know the whole equation. Well, this chat GPT is a hot wave. Everyone's been talking about it because I think it illustrates something that's next-gen, feels next-gen. And it's just getting started, so it's gonna get better. I mean, people are throwing stones at it, but I think it's amazing. It's the equivalent of me seeing the browser for the first time. You know, like, wow, this is really compelling. This is game-changing, it's not just keyword chatbots. It's like, this is real, this is next-level. And I think the super-cloud wave that people are getting behind points to that. And I think the question of ops and dev comes up because I think if you limit the infrastructure opportunity for a developer, I think they're gonna be handicapped. I mean, that's the general, my opinion. The thesis is you give more aperture to developers, more choice, more capabilities, more good things could happen, policy. And that's why you're seeing the convergence of networking people, virtualization talent, operational talent, get into the conversation because I think it's an infrastructure engineering opportunity. I think this is a seminal moment in a new stack that's emerging from an infrastructure, software virtualization, low-code, no-code layer that will be completely programmable by things like the next-chat GPT or something different. But yet still, the mechanics and the plumbing will still need engineering. So there's still gonna be more stuff coming on. Yeah, with the cloud, we have made the infrastructure programmable. And you give the programmability to the programmer, they will be very creative with that. And so we are being very creative with our infrastructure now. And on top of that, we are being very creative with the silicon now, right? So we talk about that. That's part of it, by the way. So you write the code to the particular silicon now. And on the flip side, the silicon is built for certain use cases for AI in France and all that. You saw this at CES. Yeah, I saw that at CES. The scenario is this. The Bosch, I spoke to Bosch. I spoke to John Deere. I spoke to AWS guys. They were showcasing their technology there. And I spoke to Azure guys as well. So the Bosch is a good example. So they are building, they are right now using AWS. I have the interview on camera. I will put it sometime later on their online. So they are using AWS on the back and now. But Bosch is the number one, number two, depending on what day it is of the year, supplier of the components to componentry to the auto industry. And they are creating a platform for auto industry. So is Qualcomm, actually, by the way, with the Snapdragon. So they told me that customers, their customers, BMW, Audi, all the manufacturers, they demand the diversity of the backend. They don't want, all of them don't want to go to AWS. So they want the choice on the backend. So whatever they cook in the middle has to work. They have to sprinkle the data for the data sovereignty side because they have Chinese car makers as well. And for, you know, for other reasons, competitive reasons, and like, well, we'll never use AWS. People don't go to AWS either for political reasons or like competitive reasons or specific use cases. But for the most part, generally, I haven't met anyone who hasn't gone first choice with AWS, but that's me personally. No, no, but they're building. The point is the developer wants choice at the backend is what I'm hearing. Yeah. Then finish that thought. Their developers want the choice. They want the choice on the backend, number one, because the customers are asking for it. In this case, the customers are asking for it, right? But the customer's requirements actually drive their economics drives that decision making, right? So in the middle, they have to, they're forced to cook up some solution which is vendor neutral on the backend or multi-cloud in nature. So every- I think that's Nervon. I don't think, I personally don't see that happening right now. I mean, I don't see the parody with clouds. So I think that's a challenge. I mean, the fact of the matter is if the development teams get fragmented, we had this chat with Kit Colbert last time, I think he's going to come on. And I think he's going to talk about his keynote in a few, in an hour or so. Development teams, the cloud is heterogeneous. Which is great. It's complex, which is challenging. You need skilled engineering to manage these clouds. So if you're a CIO and you go all in on AWS, it's hard to then go out and say, I want to be completely multi-vendor neutral. That's a tall order on many levels. And this is the multi-cloud challenge, right? So the question is, what's the strategy for me, the CIO or CISO? What do I do? I mean, to me, I would go all in on one and start getting hedges and start playing and then look for some- Please start clear to me. Go ahead. If you're a CIO today, you have to build a platform engineering team. No question. Because if we agree that we cannot tell the great developers what to do, we have to create a platform engineering team that using pieces of the super cloud can build. And let's make this very pragmatic and give examples. First, you need to be able to lay down the runtime. So you need a way to deploy multiple different Kubernetes environment, depending on the cloud. Okay, now we got that. The second- That's like table stakes. That's a table stake, right? But now, what is the advantage of having a super cloud service to do that is that now you can put a policy in one place and it gets distributed everywhere consistently. So for example, you want to say, if anybody in this organization across all these different BU's, all these developers I don't even know, build a PCI compliant microservice, they can only talk to PCI compliant microservice. Now I sleep tight, the developers still do that. Of course, they're going to get their hands slapped if they don't encrypt some messages. So that should have been encrypted. So number one, the second thing I want to be able to say, this service that this developer built over there, better satisfy this SLA. So if the SLA is not satisfied, boom, I automatically spin up multiple instances to certify the SLA. Developers, unencumbered, they don't even know. So this, for me, is like CIO, build a platform engineering team using one of the many super cloud services that allow you to do that and lay down. And part of that is that the vendor behavior is such because the incentives that they don't necessarily always work together. I'll give you an example. We're going to hear today from Western Union. They're AWS shop, but they want to go to Google. They want to use some of Google's AI tools because they're good and maybe they're even arguably better, but they're also a Snowflake customer. And what you'll hear from them is Amazon and Snowflake are working together so that SageMaker can be integrated with Snowflake, but Google said, no, you want to use our AI tools, you got to use BigQuery. So they say, ah, forget it. So if you have a platform engineering team, you can maybe solve some of that vendor friction and get competitive advantage. I think the future proximity concept I talk about is like when you're doing one thing, you want to do another thing. Where do you go to get that thing, right? So that is very important. Like your question, John, is that your point is that AWS is ahead of the pack, which is true, right? They have the infrastructure as a service, right? They have breadth of services, right? So when do you bring in other cloud providers, right? So I believe that you should standardize on one cloud provider, like that's your primary, and for others, you bring them in on as needed basis in the sub-section or sub-portfolio of your applications or your platforms. Probably your platform. Like the Google AI example. Yeah, I mean. Or the Microsoft Collaboration software example. I mean, there's always, or the M&A. You're going to get this. You can run Windows on Amazon. By the way, SuperCloud doesn't mean that you cannot do that. So the perfect example is, say that you're using Azure because you have a SQL server intensive workload and you're using Google for ML. Great. If you're using some differentiated feature of this cloud, you'll have to go somewhere and configure this widget. But what you can abstract with the SuperCloud is the lifecycle manage of the service that runs on top, right? So how does the service get deployed, right? How do you monitor performance? How do you lifecycle it? Are you secure it? That you can abstract and that's the value. And eventually the value will win. So the customers will find, what is the value? Is it abstracting and making it uniform or going deep? How about identity? Like some take identity, for instance. That's an opportunity to abstract, right? You use Microsoft Identity or Octa and I can abstract that. Yeah, and then we have APIs and standards that we can use. So eventually, I think where there is enough pain, the right open source will emerge to solve that problem. Yeah, and I can extract things like object store, right, that's pretty simple. Back to the engineering question, though, is that developers, developers, developers, one thing about developer psychology is if something's not right, they say, go get fix it. I'm not touching it until you fix it. They're very sticky about, if something's not working, they're not going to do it again, right? So you got to get it right for developers. I mean, they'll maybe tolerate something new, but is the juice worth the squeeze, as they say, right? So you can't go to the direction, hey, it's a work in progress. We're going to get our infrastructure together and the world's going to be great for you, but just hang tight. They're going to be like, get your shit together, then talk to me. So I think that, to me, is the question. It's an ops question, but where's that value for the developer in SuperCloud? Where the capabilities are there, there's less friction. It's simpler. It solves the complexity problem. I don't need to be high-skilled labor to manage Amazon. I got services exposed. It's what we talked about earlier. It's like the Walmart example. Basically, they took away from the developer the need to spin up infrastructure and worry about all the governance. I mean, it's not completely there yet. So the developer could focus on what he or she wanted to do. But there's a big, like in our industry, there's a big sort of flaw or the contention between developers and operators. Developers want to be on the cutting edge, right? And operators want to be on the stability, you know, like a governance, right? So they want to control the, developers are like these little brady kids, right? And they want Legos. They want toys, right? Some of them want toys, by the way. They want Legos. They want to build it. They want to make a mess out of it. So you got to make sure, my number one advice in this context is that do we up your application portfolio and or your platform portfolio if you are an ISV, right? So if you are an ISV, most probably you're building a platform these days. Do we it up in a way that you can say this portion of our applications and or platform will adhere to what you're saying, standardization, you know, like Kubernetes, like Slam Dunk, you know, it works across clouds and in your data center, hybrid, you know, whole nine yards. But there is some subset on the next door, systems of innovation. Everybody has it. Doesn't matter if you're DMV of Kansas or you are, you know, metaverse, right? Or meta company, which is Facebook, they have it. They are building something new. For that, give them some freedom to choose different things, like play with non-standard things. So that is the mantra for moving forward for any enterprise. Do you think developers are happy with the infrastructure now or are they wanting people to get their act together? I mean, what's your reaction? Developers are happy as long as they can do their stuff, which is writing code. They want to write code and innovate. So to me, when Balmer said developer, developer, developer, what he meant was all you other people get your act together so these developers can do their thing. And to me, the super cloud is the way for IT to get there, let developer be creative and go fast while not without getting in trouble. Okay, let's wrap up this segment with a super clip. Okay, we're going to do a sound byte that we're going to make into a short video for each of you on you guys summarizing why super cloud is important, why this next wave is relevant for the practitioners, for the industry, and we'll turn this into an Instagram reel, YouTube short. So we'll call it a super clip. All right. Sarpy, do you want some time to think about it? You want to go first, Vittorio? You want to? I just didn't mind. Okay, okay. I'll do it again. Go back. No, we want a fresh one. We're going to already got that one in the can. I will go. Sarpy, you go first. I'll go. What's your super clip? In software systems, abstraction is your friend. I always say that. Abstraction is your friend. Even if you're a super professional developer, abstraction is your friend. We saw from the MMFC library from C++ days to till today, use abstraction, do not try to reinvent what's already being invented, leverage cloud, leverage the platform side of the cloud, not just infrastructure service, but platform as a service side of the cloud as well. And super cloud is a meta platform built on top of these infrastructure services from three or four or five cloud providers. So use that and embrace the programmability, embrace the abstraction layer. That's the key actually. And developers who are true professional developers, as you said, they know that. Awesome, great super clip. Vittorio, another shot at the plate here for super clip, go. Multi-cloud is awesome. There's a reason why multi-cloud happened is because it gave our developers the ability to innovate faster than ever before. So if you're embarking on a digital transformation journey, which I call a survival journey, if you're not innovating and transforming, you're not going to be around in business three, five years from now, you have to adopt the super cloud. So the developer can be developer and keep building great innovating digital experiences for your customers. And IT can get in front of it and not getting in trouble together. Building those super apps with super cloud, that was a great super clip, Vittorio. Thank you for sharing. Thanks guys. Thank you for coming on, talking about the developer impact super cloud too. On our next segment coming up right now, we're going to hear from Walmart Enterprise Architect how they are building and they are continuing to innovate to build their own super cloud, really informative, instructive from a practitioner doing it in real time. We'll be right back with Walmart here in Palo Alto. Thanks for watching.