(bright music) >> Hi, everybody, this is Dave Vellante, welcome back to Supercloud 2. Last August, at the first Supercloud event, we invited the broader community to help further define Supercloud, we assessed its viability, and identified the critical elements and deployment models of the concept. The objectives here at Supercloud too are, first of all, to continue to tighten and test the concept, the second is, we want to get real world input from practitioners on the problems that they're facing and the viability of Supercloud in terms of applying it to their business. So on the program, we got companies like Walmart, Sachs, Western Union, Ionis Pharmaceuticals, NASDAQ, and others. And the third thing that we want to do is we want to drill into the intersection of cloud and data to project what the future looks like in the context of Supercloud. So in this segment, we want to explore the concept of data architectures and what's going to be required for Supercloud. And I'm pleased to welcome one of our Supercloud sponsors, ChaosSearch, Ed Walsh is the CEO of the company, with Thomas Hazel, who's the Founder, CTO, and Chief Scientist. Guys, good to see you again, thanks for coming into our Marlborough studio. >> Always great. >> Great to be here. >> Okay, so there's a little debate, I'm going to put you right in the spot. (Ed chuckling) A little debate going on in the community started by Bob Muglia, a former CEO of Snowflake, and he was at Microsoft for a long time, and he looked at the Supercloud definition, said, "I think you need to tighten it up a little bit." So, here's what he came up with. He said, "A Supercloud is a platform that provides a programmatically consistent set of services hosted on heterogeneous cloud providers." So he's calling it a platform, not an architecture, which was kind of interesting. And so presumably the platform owner is going to be responsible for the architecture, but Dr. Nelu Mihai, who's a computer scientist behind the Cloud of Clouds Project, he chimed in and responded with the following. He said, "Cloud is a programming paradigm supporting the entire lifecycle of applications with data and logic natively distributed. Supercloud is an open architecture that integrates heterogeneous clouds in an agnostic manner." So, Ed, words matter. Is this an architecture or is it a platform? >> Put us on the spot. So, I'm sure you have concepts, I would say it's an architectural or design principle. Listen, I look at Supercloud as a mega trend, just like cloud, just like data analytics. And some companies are using the principle, design principles, to literally get dramatically ahead of everyone else. I mean, things you couldn't possibly do if you didn't use cloud principles, right? So I think it's a Supercloud effect, you're able to do things you're not able to. So I think it's more a design principle, but if you do it right, you get dramatic effect as far as customer value. >> So the conversation that we were having with Muglia, and Tristan Handy of dbt Labs, was, I'll set it up as the following, and, Thomas, would love to get your thoughts, if you have a CRM, think about applications today, it's all about forms and codifying business processes, you type a bunch of stuff into Salesforce, and all the salespeople do it, and this machine generates a forecast. What if you have this new type of data app that pulls data from the transaction system, the e-commerce, the supply chain, the partner ecosystem, et cetera, and then, without humans, actually comes up with a plan. That's their vision. And Muglia was saying, in order to do that, you need to rethink data architectures and database architectures specifically, you need to get down to the level of how the data is stored on the disc. What are your thoughts on that? Well, first of all, I'm going to cop out, I think it's actually both. I do think it's a design principle, I think it's not open technology, but open APIs, open access, and you can build a platform on that design principle architecture. Now, I'm a database person, I love solving the database problems. >> I'm waited for you to launch into this. >> Yeah, so I mean, you know, Snowflake is a database, right? It's a distributed database. And we wanted to crack those codes, because, multi-region, multi-cloud, customers wanted access to their data, and their data is in a variety of forms, all these services that you're talked about. And so what I saw as a core principle was cloud object storage, everyone streams their data to cloud object storage. From there we said, well, how about we rethink database architecture, rethink file format, so that we can take each one of these services and bring them together, whether distributively or centrally, such that customers can access and get answers, whether it's operational data, whether it's business data, AKA search, or SQL, complex distributed joins. But we had to rethink the architecture. I like to say we're not a first generation, or a second, we're a third generation distributed database on pure, pure cloud storage, no caching, no SSDs. Why? Because all that availability, the cost of time, is a struggle, and cloud object storage, we think, is the answer. >> So when you're saying no caching, so when I think about how companies are solving some, you know, pretty hairy problems, take MySQL Heatwave, everybody thought Oracle was going to just forget about MySQL, well, they come out with Heatwave. And the way they solve problems, and you see their benchmarks against Amazon, "Oh, we crush everybody," is they put it all in memory. So you said no caching? You're not getting performance through caching? How is that true, and how are you getting performance? >> Well, so five, six years ago, right? When you realize that cloud object storage is going to be everywhere, and it's going to be a core foundational, if you will, fabric, what would you do? Well, a lot of times the second generation say, "We'll take it out of cloud storage, put in SSDs or something, and put into cache." And that adds a lot of time, adds a lot of costs. But I said, what if, what if we could actually make the first read hot, the first read distributed joins and searching? And so what we went out to do was said, we can't cache, because that's adds time, that adds cost. We have to make cloud object storage high performance, like it feels like a caching SSD. That's where our patents are, that's where our technology is, and we've spent many years working towards this. So, to me, if you can crack that code, a lot of these issues we're talking about, multi-region, multicloud, different services, everybody wants to send their data to the data lake, but then they move it out, we said, "Keep it right there." >> You nailed it, the data gravity. So, Bob's right, the data's coming in, and you need to get the data from everywhere, but you need an environment that you can deal with all that different schema, all the different type of technology, but also at scale. Bob's right, you cannot use memory or SSDs to cache that, that doesn't scale, it doesn't scale cost effectively. But if you could, and what you did, is you made object storage, S3 first, but object storage, the only persistence by doing that. And then we get performance, we should talk about it, it's literally, you know, hundreds of terabytes of queries, and it's done in seconds, it's done without memory caching. We have concepts of caching, but the only caching, the only persistence, is actually when we're doing caching, we're just keeping another side-eye track of things on the S3 itself. So we're using, actually, the object storage to be a database, which is kind of where Bob was saying, we agree, but that's what you started at, people thought you were crazy. >> And maybe make it live. Don't think of it as archival or temporary space, make it live, real time streaming, operational data. What we do is make it smart, we see the data coming in, we uniquely index it such that you can get your use cases, that are search, observability, security, or backend operational. But we don't have to have this, I dunno, static, fixed, siloed type of architecture technologies that were traditionally built prior to Supercloud thinking. >> And you don't have to move everything, essentially, you can do it wherever the data lands, whatever cloud across the globe, you're able to bring it together, you get the cost effectiveness, because the only persistence is the cheapest storage persistent layer you can buy. But the key thing is you cracked the code. >> We had to crack the code, right? That was the key thing. >> That's where the plans are. >> And then once you do that, then everything else gets easier to scale, your architecture, across regions, across cloud. >> Now, it's a general purpose database, as Bob was saying, but we use that database to solve a particular issue, which is around operational data, right? So, we agree with Bob's. >> Interesting. So this brings me to this concept of data, Jimata Gan is one of our speakers, you know, we talk about data fabric, which is a NetApp, originally NetApp concept, Gartner's kind of co-opted it. But so, the basic concept is, data lives everywhere, whether it's an S3 bucket, or a SQL database, or a data lake, it's just a node on the data mesh. So in your view, how does this fit in with Supercloud? Ed, you've said that you've built, essentially, an enabler for that, for the data mesh, I think you're an enabler for the Supercloud-like principles. This is a big, chewy opportunity, and it requires, you know, a team approach. There's got to be an ecosystem, there's not going to be one Supercloud to rule them all, so where does the ecosystem fit into the discussion, and where do you fit into the ecosystem? >> Right, so we agree completely, there's not one Supercloud in effect, but we use Supercloud principles to build our platform, and then, you know, the ecosystem's going to be built on leveraging what everyone else's secret powers are, right? So our power, our superpower, based upon what we built is, we deal with, if you're having any scale, or cost effective scale issues, with data, machine generated data, like business observability or security data, we are your force multiplier, we will take that in singularly, just let it, simply put it in your object storage wherever it sits, and we give you uniformity access to that using OpenAPI access, SQL, or you know, Elasticsearch API. So, that's what we do, that's our superpower. So I'll play it into data mesh, that's a perfect, we are a node on a data mesh, but I'll play it in the soup about how, the ecosystem, we see it kind of playing, and we talked about it in just in the last couple days, how we see this kind of possibly. Short term, our superpowers, we deal with this data that's coming at these environments, people, customers, building out observability or security environments, or vendors that are selling their own Supercloud, I do observability, the Datadogs of the world, dot dot dot, the Splunks of the world, dot dot dot, and security. So what we do is we fit in naturally. What we do is a cost effective scale, just land it anywhere in the world, we deal with ingest, and it's a cost effective, an order of magnitude, or two or three order magnitudes more cost effective. Allows them, their customers are asking them to do the impossible, "Give me fast monitoring alerting. I want it snappy, but I want it to keep two years of data, (laughs) and I want it cost effective." It doesn't work. They're good at the fast monitoring alerting, we're good at the long-term retention. And yet there's some gray area between those two, but one to one is actually cheaper, so we would partner. So the first ecosystem plays, who wants to have the ability to, really, all the data's in those same environments, the security observability players, they can literally, just through API, drag our data into their point to grab. We can make it seamless for customers. Right now, we make it helpful to customers. Your Datadog, we make a button, easy go from Datadog to us for logs, save you money. Same thing with Grafana. But you can also look at ecosystem, those same vendors, it used to be a year ago it was, you know, its all about how can you grow, like it's growth at all costs, now it's about cogs. So literally we can go an environment, you supply what your customer wants, but we can help with cogs. And one-on one in a partnership is better than you trying to build on your own. >> Thomas, you were saying you make the first read fast, so you think about Snowflake. Everybody wants to talk about Snowflake and Databricks. So, Snowflake, great, but you got to get the data in there. All right, so that's, can you help with that problem? >> I mean we want simple in, right? And if you have to have structure in, you're not simple. So the idea that you have a simple in, data lake, schema read type philosophy, but schema right type performance. And so what I wanted to do, what we have done, is have that simple lake, and stream that data real time, and those access points of Search or SQL, to go after whatever business case you need, security observability, warehouse integration. But the key thing is, how do I make that click, click, click answer, and do it quickly? And so what we want to do is, that first read has to be fast. Why? 'Cause then you're going to do all this siloing, layers, complexity. If your first read's not fast, you're at a disadvantage, particularly in cost. And nobody says I want less data, but everyone has to, whether they say we're going to shorten the window, we're going to use AI to choose, but in a security moment, when you don't have that answer, you're in trouble. And that's why we are this service, this Supercloud service, if you will, providing access, well-known search, well-known SQL type access, that if you just have one access point, you're at a disadvantage. >> We actually talked about Snowflake and BigQuery, and a different platform, Data Bricks. That's kind of where we see the phase two of ecosystem. One is easy, the low-hanging fruit is observability and security firms. But the next one is, what we do, our super power is dealing with this messy data that schema is changing like night and day. Pipelines are tough, and it's changing all the time, but you want these things fast, and it's big data around the world. That's the next point, just use us alongside, or inside, one of their platforms, and now we get the best of both worlds. Our superpower is keeping this messy data as a streaming, okay, not a batch thing, allow you to do that. So, that's the second one. And then to be honest, the third one, which plays you to Supercloud, it also plays perfectly in the data mesh, is if you really go to the ultimate thing, what we have done is made object storage, S3, GCS, and blob storage, we made it a database. Put, get, complex query with big joins. You know, so back to your original thing, and Muglia teed it up perfectly, we've done that. Now imagine if that's an ecosystem, who would want that? If it's, again, it's uniform available across all the regions, across all the clouds, and it's right next to where you are building a service, or a client's trying, that's where the ecosystem, I think people are going to use Superclouds for their superpowers. We're really good at this, allows that short term. I think the Snowflakes and the Data Bricks are the medium term, you know? And then I think eventually gets to, hey, listen if you can make object storage fast, you can just go after it with simple SQL queries, or elastic. Who would want that? I think that's where people are going to leverage it. It's not going to be one Supercloud, and we leverage the super clouds. >> Our viewpoint is smart object storage can be programmable, and so we agree with Bob, but we're not saying do it here, do it here. This core, fundamental layer across regions, across clouds, that everyone has? Simple in. Right now, it's hard to get data in for access for analysis. So we said, simply, we'll automate the entire process, give you API access across regions, across clouds. And again, how do you do a distributed join that's fast? How do you do a distributed join that doesn't cost you an arm or a leg? And how do you do it at scale? And that's where we've been focused. >> So prior, the cloud object store was a niche. >> Yeah. >> S3 obviously changed that. How standard is, essentially, object store across the different cloud platforms? Is that a problem for you? Is that an easy thing to solve? >> Well, let's talk about it. I mean we've fundamentally, yeah we've extracted it, but fundamentally, cloud object storage, put, get, and list. That's why it's so scalable, 'cause it doesn't have all these other components. That complexity is where we have moved up, and provide direct analytical API access. So because of its simplicity, and costs, and security, and reliability, it can scale naturally. I mean, really, distributed object storage is easy, it's put-get anywhere, now what we've done is we put a layer of intelligence, you know, call it smart object storage, where access is simple. So whether it's multi-region, do a query across, or multicloud, do a query across, or hunting, searching. >> We've had clients doing Amazon and Google, we have some Azure, but we see Amazon and Google more, and it's a consistent service across all of them. Just literally put your data in the bucket of choice, or folder of choice, click a couple buttons, literally click that to say "that's hot," and after that, it's hot, you can see it. But we're not moving data, the data gravity issue, that's the other. That it's already natively flowing to these pools of object storage across different regions and clouds. We don't move it, we index it right there, we're spinning up stateless compute, back to the Supercloud concept. But now that allows us to do all these other things, right? >> And it's no longer just cheap and deep object storage. Right? >> Yeah, we make it the same, like you have an analytic platform regardless of where you're at, you don't have to worry about that. Yeah, we deal with that, we deal with a stateless compute coming up -- >> And make it programmable. Be able to say, "I want this bucket to provide these answers." Right, that's really the hope, the vision. And the complexity to build the entire stack, and then connect them together, we said, the fabric is cloud storage, we just provide the intelligence on top. >> Let's bring it back to the customers, and one of the things we're exploring in Supercloud too is, you know, is Supercloud a solution looking for a problem? Is a multicloud really a problem? I mean, you hear, you know, a lot of the vendor marketing says, "Oh, it's a disaster, because it's all different across the clouds." And I talked to a lot of customers even as part of Supercloud too, they're like, "Well, I solved that problem by just going mono cloud." Well, but then you're not able to take advantage of a lot of the capabilities and the primitives that, you know, like Google's data, or you like Microsoft's simplicity, their RPA, whatever it is. So what are customers telling you, what are their near term problems that they're trying to solve today, and how are they thinking about the future? >> Listen, it's a real problem. I think it started, I think this is a a mega trend, just like cloud. Just, cloud data, and I always add, analytics, are the mega trends. If you're looking at those, if you're not considering using the Supercloud principles, in other words, leveraging what I have, abstracting it out, and getting the most out of that, and then build value on top, I think you're not going to be able to keep up, In fact, no way you're going to keep up with this data volume. It's a geometric challenge, and you're trying to do linear things. So clients aren't necessarily asking, hey, for Supercloud, but they're really saying, I need to have a better mechanism to simplify this and get value across it, and how do you abstract that out to do that? And that's where they're obviously, our conversations are more amazed what we're able to do, and what they're able to do with our platform, because if you think of what we've done, the S3, or GCS, or object storage, is they can't imagine the ingest, they can't imagine how easy, time to glass, one minute, no matter where it lands in the world, querying this in seconds for hundreds of terabytes squared. People are amazed, but that's kind of, so they're not asking for that, but they are amazed. And then when you start talking on it, if you're an enterprise person, you're building a big cloud data platform, or doing data or analytics, if you're not trying to leverage the public clouds, and somehow leverage all of them, and then build on top, then I think you're missing it. So they might not be asking for it, but they're doing it. >> And they're looking for a lens, you mentioned all these different services, how do I bring those together quickly? You know, our viewpoint, our service, is I have all these streams of data, create a lens where they want to go after it via search, go after via SQL, bring them together instantly, no e-tailing out, no define this table, put into this database. We said, let's have a service that creates a lens across all these streams, and then make those connections. I want to take my CRM with my Google AdWords, and maybe my Salesforce, how do I do analysis? Maybe I want to hunt first, maybe I want to join, maybe I want to add another stream to it. And so our viewpoint is, it's so natural to get into these lake platforms and then provide lenses to get that access. >> And they don't want it separate, they don't want something different here, and different there. They want it basically -- >> So this is our industry, right? If something new comes out, remember virtualization came out, "Oh my God, this is so great, it's going to solve all these problems." And all of a sudden it just got to be this big, more complex thing. Same thing with cloud, you know? It started out with S3, and then EC2, and now hundreds and hundreds of different services. So, it's a complex matter for a lot of people, and this creates problems for customers, especially when you got divisions that are using different clouds, and you're saying that the solution, or a solution for the part of the problem, is to really allow the data to stay in place on S3, use that standard, super simple, but then give it what, Ed, you've called superpower a couple of times, to make it fast, make it inexpensive, and allow you to do that across clouds. >> Yeah, yeah. >> I'll give you guys the last word on that. >> No, listen, I think, we think Supercloud allows you to do a lot more. And for us, data, everyone says more data, more problems, more budget issue, everyone knows more data is better, and we show you how to do it cost effectively at scale. And we couldn't have done it without the design principles of we're leveraging the Supercloud to get capabilities, and because we use super, just the object storage, we're able to get these capabilities of ingest, scale, cost effectiveness, and then we built on top of this. In the end, a database is a data platform that allows you to go after everything distributed, and to get one platform for analytics, no matter where it lands, that's where we think the Supercloud concepts are perfect, that's where our clients are seeing it, and we're kind of excited about it. >> Yeah a third generation database, Supercloud database, however we want to phrase it, and make it simple, but provide the value, and make it instant. >> Guys, thanks so much for coming into the studio today, I really thank you for your support of theCUBE, and theCUBE community, it allows us to provide events like this and free content. I really appreciate it. >> Oh, thank you. >> Thank you. >> All right, this is Dave Vellante for John Furrier in theCUBE community, thanks for being with us today. You're watching Supercloud 2, keep it right there for more thought provoking discussions around the future of cloud and data. (bright music)

(bright upbeat music) >> Welcome back, everybody, to the Supercloud 2. My name is Dave Vellante. And I'm pleased to welcome Nir Zuk. He's the founder and CTO of Palo Alto Networks. Nir, good to see you again. Welcome. >> Same here. Good to see you. >> So let's start with the right security architecture in the context of today's fragmented market. You've got a lot of different tools, you've got different locations, on-prem, you've got hardware and software. Tell us about the right security architecture from your standpoint. What's that look like? >> You know, the funny thing is using the word security in architecture rarely works together. (Dave chuckles) If you ask a typical information security person to step up to a whiteboard and draw their security architecture, they will look at you as if you fell from the moon. I mean, haven't you been here in the last 25 years? There's no security architecture. The architecture today is just buying a bunch of products and dropping them into the infrastructure at some relatively random way without really any guiding architecture. And that's a huge challenge in cybersecurity. It's always been, we've always tried to find ways to put an architecture into writing blueprints, whatever you want to call it, and it's always been difficult. Luckily, two things. First, there's something called zero trust, which we can talk a little bit about more, if you want, and zero trust among other things is really a way to create a security architecture, and second, because in the cloud, in the supercloud, we're starting from scratch, we can do things differently. We don't have to follow the way we've always done cybersecurity, again, buying random products, okay, maybe not random, maybe there is some thinking going into it by buying products, one of the other, dropping them in, and doing it over 20 years and ending up with a mess in the cloud, we have an opportunity to do it differently and really have an architecture. >> You know, I love talking to founders and particularly technical founders from StartupNation. I think I saw an article, I think it was Erie Levine, one of the founders or co-founders of Waze, and he had a t-shirt on, it said, "Fall in love with the problem, not the solution." Is that how you approached architecture? You talk about zero trust, it's a relatively new term, but was that in your head when you thought about forming the company? >> Yeah, so when I started Palo Alto Networks, exactly, by the way, 17 years ago, we got funded January, 2006, January 18th, 2006. The idea behind Palo Alto Networks was to create a security platform and over time take more and more cybersecurity functions and deliver them on top of that platform, by the way, as a service, SaaS. Everybody thought we were crazy trying to combine many functions into one platform, best of breed and defense in death and putting all your eggs in the same basket and a bunch of other slogans were flying around, and also everybody thought we were crazy asking customers to send information to the cloud in order to secure themselves. Of course, step forward 17 years, everything is now different. We changed the market. Almost all of cybersecurity today is delivered as SaaS and platforms are ruling more and more the world. And so again, the idea behind the platform was to over time take more and more cybersecurity functions and deliver them together, one brain, one decision being made for each and every packet or system call or file or whatever it is that you're making the decision about and it works really, really well. As a side effect, when you combine that with zero trust and you end up with, let's not call it an architecture yet. You end up with with something where any user, any location, both geographically as well as any location in terms of branch office, headquarters, home, coffee shop, hotel, whatever, so any user, any geographical location, any location, any connectivity method, whether it is SD1 or IPsec or Client VPN or Client SVPN or proxy or browser isolation or whatever and any application deployed anywhere, public cloud, private cloud, traditional data center, SaaS, you secure the same way. That's really zero trust, right? You secure everything, no matter who the user is, no matter where they are, no matter where they go, you secure them exactly the same way. You don't make any assumptions about the user or the application or the location or whatever, just because you trust nothing. And as a side effect, when you do that, you end up with a security architecture, the security architecture I just described. The same thing is true for securing applications. If you try to really think and not just act instinctively the way we usually do in cybersecurity and you say, I'm going to secure my traditional data center applications or private cloud applications and public cloud applications and my SaaS applications the same way, I'm not going to trust something just because it's deployed in the private data center. I'm not going to trust two components of an application or two applications talking to each other just because they're deployed in the same place versus if one component is deployed in one public cloud and the other component is deployed in another public cloud or private cloud or whatever. I'm going to secure all of them the same way without making any trust assumptions. You end up with an architecture for securing your applications, which is applicable for the supercloud. >> It was very interesting. There's a debate I want to pick up on what you said because you said don't call it an architecture yet. So Bob Muglia, I dunno if you know Bob, but he sort of started the debate, said, "Supercloud, think of it as a platform, not an architecture." And there are others that are saying, "No, no, if we do that, then we're going to have a bunch of more stove pipes. So there needs to be standard, almost a purist view. There needs to be a supercloud architecture." So how do you think about it? And it's a bit academic, I know, but do you think of this idea of a supercloud, this layer of value on top of the hyperscalers, do you think of that as a platform approach that each of the individual vendors are responsible for the architecture? Or is there some kind of overriding architecture of standards that needs to emerge to enable the supercloud? >> So we can talk academically or we can talk practically. >> Yeah, let's talk practically. That's who you are. (Dave laughs) >> Practically, this world is ruled by financial interests and none of the public cloud providers, especially the bigger they are has any interest of making it easy for anyone to go multi-cloud, okay? Also, on top of that, if we want to be even more practical, each of those large cloud providers, cloud scale providers have engineers and all these engineers think they're the best in the world, which they are and they all like to do things differently. So you can't expect things in AWS and in Azure and GCP and in the other clouds like Oracle and Ali and so on to be the same. They're not going to be the same. And some things can be abstracted. Maybe cloud storage or bucket storage can be abstracted with the layer that makes them look the same no matter where you're running. And some things cannot be abstracted and unfortunately will not be abstracted because the economical interest and the way engineers work won't let it happen. We as a third party provider, cybersecurity provider, and I'm sure other providers in other areas as well are trying or we're doing our best. We're not trying, we are doing our best, and it's pretty close to being the way you describe the top of your supercloud. We're building something that abstracts the underlying cloud such that securing each of these clouds, and by the way, I would add private cloud to it as well, looks exactly the same. So we use, almost always, whenever possible, the same terminology, no matter which cloud we're securing and the same policy and the same alerts and the same information and so on. And that's also very important because when you look at the people that actually end up using the product, security engineers and more importantly, SOC, security operations center analysts, they're not going to study the details of each and every cloud. It's just going to be too much. So we need to abstract it for them. >> Yeah, we agree by the way that the supercloud definition is inclusive of on-prem, you know, what you call private cloud. And I want to pick up on something else you said. I think you're right that abstracting and making consistent across clouds something like object storage, get put, you know, whether it's an S3 bucket or an Azure Blob, relatively speaking trivial. When you now bring that supercloud concept to something more complex like security, first of all, as a technically feasible and inferring the answer there is yes, and if so, what do you see as the main technical challenges of doing so? >> So it is feasible to the extent that the different cloud provide the same functionality. Then you step into a territory where different cloud providers have different paths services and different cloud providers do things a little bit differently and they have different sets of permissions and different logging that sometimes provides all the information and sometimes it doesn't. So you end up with some differences. And then the question is, do you abstract the lowest common dominator and that's all you support? Or do you find a way to be smarter than that? And yeah, whatever can be abstracted is abstracted and whatever cannot be abstracted, you find an easy way to represent that to your users, security engineers, security analysts, and so on, which is what I believe we do. >> And you do that by what? Inventing or developing technology that presents that experience to users? Could you be more specific there? >> Yeah, so different cloud providers call their storage in different names and you use different ways to configure them and the logs come out the same. So we normalize it. I mean, the keyword is probably normalization. Normalize it. And we try to, you know, then you have to pick a winner here and to use someone's terminology or you need to invent new terminology. So we try to use the terminology of the largest cloud provider so that we have a better chance of doing that but we can't always do that because they don't support everything that other cloud providers provide, but the important thing is, with or thanks to that normalization, our customers both on the engineering side and on the user side, operations side end up having to learn one terminology in order to set policies and understand attacks and investigate incidents. >> I wonder if I could pick your brain on what you see as the ideal deployment model to achieve this supercloud experience. For example, do you think instantiating your stack in multiple regions and multiple clouds is the right way to do it? Or is building a single global instance on top of the clouds a more preferable way? Are maybe other models we should consider? What do you see as the trade off of these different deployment models and which one is ideal in your view? >> Yeah, so first, when you deploy cloud security, you have to decide whether you're going to use agents or not. By agents, I mean something working, something running inside the workload. Inside a virtual machine on the container host attached to function, serverless function and so on and I, of course, recommend using agents because that enables prevention, it enables functionality you cannot get without agents but you have to choose that. Now, of course, if you choose agent, you need to deploy AWS agents in AWS and GCP agents in GCP and Azure agents in Azure and so on. Of course, you don't do it manually. You do it through the CICD pipeline. And then the second thing that you need to do is you need to connect with the consoles. Of course, that can be done over the internet no matter where your security instances is running. You can run it on premise, you can run it in one of the other different clouds. Of course, we don't run it on premise. We prefer not to run it on premise because if you're secured in cloud, you might as well run in the cloud. And then the question is, for example, do you run a separate instance for AWS for GCP or for Azure, or you want to run one instance for all of them in one of these clouds? And there are advantages and disadvantages. I think that from a security perspective, it's always better to run in one place because then when you collect the information, you get information from all the clouds and you can start looking for cross-cloud issues, incidents, attacks, and so on. The downside of that is that you need to send all the information to one of the clouds and you probably know that sending data out of the cloud costs a lot of money versus keeping it in the cloud. So theoretically, you can build an architecture where you keep the data for AWS in AWS, Azure in Azure, GCP in GCP, and then you try to run distributed queries. When you do that, you find out you'd end up paying more for the compute to do that than you would've paid for sending all the data to a central location. So we prefer the approach of running in one place, bringing all the data there, and running all the security, the machine learning or whatever, the rules or whatever it is that you're running in one place versus trying to create a distributed deployment in order to try to save some money on the data, the network data transfers. >> Yeah, thank you for that. That makes a lot of sense. And so basically, should we think about the next layer building security data lake, if you will, and then running machine learning on top of that if I can use that term of a data lake or a lake house? Is that sort of where you're headed? >> Yeah, look, the world is headed in that direction, not just the cybersecurity world. The world is headed from being rule-based to being data-based. So cybersecurity is not different and what we used to do with rules in the past, we're now doing with machine learning. So in the past, you would define rules saying, if you see this, this, and this, it's an attack. Now you just throw the data at the machine, I mean, I'm simplifying it, but you throw data at a machine. You'll tell the machine, find the attack in the data. It's not that simple. You need to build the right machine learning models. It needs to be done by people that are both cybersecurity experts and machine learning experts. We do it mostly with ex-military offensive people that take their offensive knowledge and translate it into machine learning models. But look, the world is moving in that direction and cybersecurity is moving in that direction as well. You need to collect a lot of data. Like I said, I prefer to see all the data in one place so that the machine learning can be much more efficient, pay for transferring the data, save money on the compute. >> I think the drop the mic quote it ignite that you had was within five years, your security operation is going to be AI-powered. And so you could probably apply that to virtually any job over the next five years. >> I don't know if any job. Certainly writing essays for school is automated already as we've seen with ChatGPT and potentially other things. By the way, we need to talk at some point about ChatGPT security. I don't want to think what happens when someone spends a lot of money on creating a lot of fake content and teaches ChatGPT the wrong answer to a question. We start seeing ChatGPT as the oracle of everything. We need to figure out what to do with the security of that. But yeah, things have to be automated in cybersecurity. They have to be automated. They're just too much data to deal with and it's just not even close to being good enough to wait for an incident to happen and then going investigate the incident based on the data that we have. It's better to look at all the data all the time, millions of events per second, and find those incidents before they happen. There's no way to do that without machine learning. >> I'd love to have you back and talk about ChatGPT. I know they're trying to put in some guardrails but there are a lot of unintended consequences, aren't there? >> Look, if they're not going to have a person filtering the data, then with enough money, you can create thousands or tens of thousands of pieces of articles or whatever that look real and teach the machine something that is totally wrong. >> We were talking about the hyper skills before and I agree with you. It's very unlikely they're going to get together, band together, and create these standards. But it's not a static market. It's a moving train, if you will. So assuming you're building this cross cloud experience which you are, what do you want from the hyperscalers? What do you want them to bring to the table? What is a technology supplier like Palo Alto Networks bring? In other words, where do you see ongoing as your unique value add and that moat that you're building and how will that evolve over time vis-a-vis the hyperscaler evolution? >> Yeah, look, we need APIs. The more data we have, the more access we have to more data, the less restricted the access is and the cheaper the access is to the data because someone has to pay today for some reason for accessing that data, the more secure their customers are going to be. So we need help and are helping by the way a lot, all of them in finding easy ways for customers to deploy things in the cloud, access data, and again, a lot of data, very diversified data and do it in a cost-effective way. >> And when we talk about the edge, I presume you look at the edge as just another data center or maybe it's the reverse. Maybe the data center is just another edge location, but you're seeing specific edge security solutions come out. I'm guessing that you would say, that's not what we want. Edge should be part of that architecture that we talked about earlier. Do you agree? >> Correct, it should be part of the architecture. I would also say that the edge provides an opportunity specifically for network security, whereas traditional network security would be deployed on premise. I'm talking about internet security but half network security market, and not just network security but also the other network intelligent functions like routing and QS. We're seeing a trend of pushing those to the edge of the cloud. So what you deploy on premise is technology for bringing packets to the edge of the cloud and then you run your security at the edge, whatever that edge is, whether it's a private edge or public edge, you run it in the edge. It's called SASE, Secure Access Services Edge, pronounced SASE. >> Nir, I got to thank you so much. You're such a clear thinker. I really appreciate you participating in Supercloud 2. >> Thank you. >> All right, keep it right there for more content covering the future of cloud and data. This is Dave Vellante for John Furrier. I'll be right back. (bright upbeat music)

(upbeat music) >> Welcome back everyone to Supercloud 2, live here in Palo Alto, our studio, where we're doing a live stage performance and virtually syndicating out around the world. I'm John Furrier with Dave Vellante, my co-host with the The Cube here. We've got Kit Colbert, the CTO of VM. We're doing a keynote on Cloud Chaos, the evolution of SuperCloud Architecture Kit. Great to see you, thanks for coming on. >> Yeah, thanks for having me back. It's great to be here for Supercloud 2. >> And so we're going to dig into it. We're going to do a Q&A. We're going to let you present. You got some slides. I really want to get this out there, it's really compelling story. Do the presentation and then we'll come back and discuss. Take it away. >> Yeah, well thank you. So, we had a great time at the original Supercloud event, since then, been talking to a lot of customers, and started to better formulate some of the thinking that we talked about last time So, let's jump into it. Just a few quick slides to sort of set the tone here. So, if we go to the the next slide, what that shows is the journey that we see customers on today, going from what we call Cloud First into this phase that many customers are stuck in, called Cloud Chaos, and where they want to get to, and this is the term customers actually use, we didn't make this up, we heard it from customers. This notion of Cloud Smart, right? How do they use cloud more effectively, more intelligently? Now, if you walk through this journey, customers start with Cloud First. They usually select a single cloud that they're going to standardize on, and when they do that, they have to build out a whole bunch of functionality around that cloud. Things you can see there on the screen, disaster recovery, security, how do they monitor it or govern it? Like, these are things that are non-negotiable, you've got to figure it out, and typically what they do is, they leverage solutions that are specific for that cloud, and that's fine when you have just one cloud. But if we build out here, what we see is that most customers are using more than just one, they're actually using multiple, not necessarily 10 or however many on the screen, but this is just as an example. And so what happens is, they have to essentially duplicate or replicate that stack they've built for each different cloud, and they do so in a kind of a siloed manner. This results in the Cloud Chaos term that that we talked about before. And this is where most businesses out there are, they're using two, maybe three public clouds. They've got some stuff on-prem and they've also got some stuff out at the edge. This is apps, data, et cetera. So, this is the situation, this is sort of that Cloud Chaos. So, the question is, how do we move from this phase to Cloud Smart? And this is where the architecture comes in. This is why architecture, I think, is so important. It's really about moving away from these single cloud services that just solve a problem for one cloud, to something we call a Cross-Cloud service. Something that can support a set of functionality across all clouds, and that means not just public clouds, but also private clouds, edge, et cetera, and when you evolve that across the board, what you get is this sort of Supercloud. This notion that we're talking about here, where you combine these cross-cloud services in many different categories. You can see some examples there on the screen. This is not meant to be a complete set of things, but just examples of what can be done. So, this is sort of the transition and transformation that we're talking about here, and I think the architecture piece comes in both for the individual cloud services as well as that Supercloud concept of how all those services come together. >> Great presentation., thanks for sharing. If you could pop back to that slide, on the Cloud Chaos one. I just want to get your thoughts on something there. This is like the layout of the stack. So, this slide here that I'm showing on the screen, that you presented, okay, take us through that complexity. This is the one where I wanted though, that looks like a spaghetti code mix. >> Yes. >> So, do you turn this into a Supercloud stack, right? Is that? >> well, I think it's, it's an evolving state that like, let's take one of these examples, like security. So, instead of implementing security individually in different ways, using different technologies, different tooling for each cloud, what you would do is say, "Hey, I want a single security solution that works across all clouds", right? A concrete example of this would be secure software supply chain. This is probably one of the top ones that I hear when I talk to customers. How do I know that the software I'm building is truly what I expect it to be, and not something that some hacker has gotten into, and polluted with malicious code? And what they do is that, typically today, their teams have gone off and created individual secure software supply chain solutions for each cloud. So, now they could say, "Hey, I can take a single implementation and just have different endpoints." It could go to Google, or AWS, or on-prem, or wherever have you, right? So, that's the sort of architectural evolution that we're talking about. >> You know, one of the things we hear, Dave, you've been on theCUBE all the time, and we, when we talk privately with customers who are asking us like, what's, what's going on? They have the same complaint, "I don't want to build a team, a dev team, for that stack." So, if you go back to that slide again, you'll see that, that illustrates the tech stack for the clouds and the clouds at the bottom. So, the number one complaint we hear, and I want to get your reaction to that, "I don't want to have a team to have to work on that. So, I'm going to pick one and then have a hedge secondary one, as a backup." Here, that's one, that's four, five, eight, ten, ten environments. >> Yeah, I got a lot. >> That's going to be the reality, so, what's the technical answer to that? >> Yeah, well first of all, let me just say, this picture is again not totally representative of reality oftentimes, because while that picture shows a solution for every cloud, oftentimes that's not the case. Oftentimes it's a line of business going off, starting to use a new cloud. They might solve one or two things, but usually not security, usually not some of these other things, right? So, I think from a technical standpoint, where you want to get to is, yes, that sort of common service, with a common operational team behind it, that is trained on that, that can work across clouds. And that's really I think the important evolution here, is that you don't need to replicate these operational teams, one for each cloud. You can actually have them more focused across all those clouds. >> Yeah, in fact, we were commenting on the opening today. Dave and I were talking about the benefits of the cloud. It's heterogeneous, which is a good thing, but it's complex. There's skill gaps and skill required, but at the end of the day, self-service of the cloud, and the elastic nature of it makes it the benefit. So, if you try to create too many common services, you lose the value of the cloud. So, what's the trade off, in your mind right now as customers start to look at okay, identity, maybe I'll have one single sign on, that's an obvious one. Other ones? What are the areas people are looking at from a combination, common set of services? Where do they start? What's the choices? What are some of the trade offs? 'Cause you can't do it everything. >> No, it's a great question. So, that's actually a really good point and as I answer your question, before I answer your question, the important point about that, as you saw here, you know, across cloud services or these set of Cross-Cloud services, the things that comprise the Supercloud, at least in my view, the point is not necessarily to completely abstract the underlying cloud. The point is to give a business optionality and choice, in terms of what it wants to abstract, and I think that gets to your question, is how much do you actually want to abstract from the underlying cloud? Now, what I find, is that typically speaking, cloud choice is driven at least from a developer or app team perspective, by the best of breed services. What higher level application type services do you need? A database or AI, you know, ML systems, for your application, and that's going to drive your choice of the cloud. So oftentimes, businesses I talk to, want to allow those services to shine through, but for other things that are not necessarily highly differentiated and yet are absolutely critical to creating a successful application, those are things that you want to standardize. Again, like things like security, the supply chain piece, cost management, like these things you need to, and you know, things like cogs become really, really important when you start operating at scale. So, those are the things in it that I see people wanting to focus on. >> So, there's a majority model. >> Yes. >> All right, and we heard of earlier from Walmart, who's fairly, you know, advanced, but at the same time their supercloud is pretty immature. So, what are you seeing in terms of supercloud momentum, crosscloud momentum? What's the starting point for customers? >> Yeah, so it's interesting, right, on that that three-tiered journey that I talked about, this Cloud Smart notion is, that is adoption of what you might call a supercloud or architecture, and most folks aren't there yet. Even the really advanced ones, even the really large ones, and I think it's because of the fact that, we as an industry are still figuring this out. We as an industry did not realize this sort of Cloud Chaos state could happen, right? We didn't, I think most folks thought they could standardize on one cloud and that'd be it, but as time has shown, that's simply not the case. As much as one might try to do that, that's not where you end up. So, I think there's two, there's two things here. Number one, for folks that are early in to the cloud, and are in this Cloud Chaos phase, we see the path out through standardization of these cross-cloud services through adoption of this sort of supercloud architecture, but the other thing I think is particularly exciting, 'cause I talked to a number of of businesses who are not yet in the Cloud Chaos phase. They're earlier on in the cloud journey, and I think the opportunity there is that they don't have to go through Cloud Chaos. They can actually skip that whole phase if they adopt this supercloud architecture from the beginning, and I think being thoughtful around that is really the key here. >> It's interesting, 'cause we're going to hear from Ionis Pharmaceuticals later, and they, yes there are multiple clouds, but the multiple clouds are largely separate, and so it's a business unit using that. So, they're not in Cloud Chaos, but they're not tapping the advantages that you could get for best of breed across those business units. So, to your point, they have an opportunity to actually build that architecture or take advantage of those cross-cloud services, prior to reaching cloud chaos. >> Well, I, actually, you know, I'd love to hear from them if, 'cause you say they're not in Cloud Chaos, but are they, I mean oftentimes I find that each BU, each line of business may feel like they're fine, in of themselves. >> Yes, exactly right, yes. >> But when you look at it from an overall company perspective, they're like, okay, things are pretty chaotic here. We don't have standardization, I don't, you know, like, again, security compliance, these things, especially in many regulated industries, become huge problems when you're trying to run applications across multiple clouds, but you don't have any of those company-wide standardizations. >> Well, this is a point. So, they have a big deal with AstraZeneca, who's got this huge ecosystem, they want to start sharing data across those ecosystem, and that's when they will, you know, that Cloud Chaos will, you know, come, come to fore, you would think. I want to get your take on something that Bob Muglia said earlier, which is, he kind of said, "Hey Dave, you guys got to tighten up your definition a little bit." So, he said a supercloud is a platform that provides programmatically consistent services hosted on heterogeneous cloud providers. So, you know, thank you, that was nice and simple. However others in the community, we're going to hear from Dr. Nelu Mihai later, says, no, no, wait a minute, it's got to be an architecture, not a platform. Where do you land on this architecture v. platform thing? >> I look at it as, I dunno if it's, you call it maturity or just kind of a time horizon thing, but for me when I hear the word platform, I typically think of a single vendor. A single vendor provides this platform. That's kind of the beauty of a platform, is that there is a simplicity usually consistency to it. >> They did the architecture. (laughing) >> Yeah, exactly but I mean, well, there's obviously architecture behind it, has to be, but you as a customer don't necessarily need to deal with that. Now, I think one of the opportunities with Supercloud is that it's not going to be, or there is no single vendor that can solve all these problems. It's got to be the industry coming together as a community, inter-operating, working together, and so, that's why, for me, I think about it as an architecture, that there's got to be these sort of, well-defined categories of functionality. There's got to be well-defined interfaces between those categories of functionality to enable modularity, to enable businesses to be able to pick and choose the right sorts of services, and then weave those together into an overall supercloud. >> Okay, so you're not pitching, necessarily the platform, you're saying, hey, we have an architecture that's open. I go back to something that Vittorio said on August 9th, with the first Supercloud, because as well, remember we talked about abstracting, but at the same time giving developers access to those primitives. So he said, and this, I think your answer sort of confirms this. "I want to have my cake eat it too and not gain weight." >> (laughing) Right. Well and I think that's where the platform aspect can eventually come, after we've gotten aligned architecture, you're going to start to naturally see some vendors step up to take on some of the remaining complexity there. So, I do see platforms eventually emerging here, but I think where we have to start as an industry is around aligning, okay, what does this definition mean? What does that architecture look like? How do we enable interoperability? And then we can take the next step. >> Because it depends too, 'cause I would say Snowflake has a platform, and they've just defined the architecture, but we're not talking about infrastructure here, obviously, we're talking about something else. >> Well, I think that the Snowflake talks about, what he talks about, security and data, you're going to start to see the early movement around areas that are very spanning oriented, and I think that's the beginning of the trend and I think there's going to be a lot more, I think on the infrastructure side. And to your point about the platform architecture, that's actually a really good thought exercise because it actually makes you think about what you're designing in the first place, and that's why I want to get your reaction. >> Quote from- >> Well I just have to interrupt since, later on, you're going to hear from near Nir Zuk of Palo Alto Network. He says architecture and security historically, they don't go hand in hand, 'cause it's a big mess. >> It depends if you're whacking the mole or you actually proactively building something. Well Kit, I want to get your reaction from a quote from someone in our community who said about Supercloud, you know, "The Supercloud's great, there are issues around computer science rigors, and customer requirements." So, there's some issues around the science itself as well as not just listen to the customer, 'cause if that's the case, we'd have a better database, a better Oracle, right, so, but there's other, this tech involved, new tech. We need an open architecture with universal data modeling interconnecting among them, connectivity is a part of security, and then, once we get through that gate, figuring out the technical, the data, and the customer requirements, they say "Supercloud should be a loosely coupled platform with open architecture, plug and play, specialized services, ready for optimization, automation that can stand the test of time." What's your reaction to that sentiment? You like it, is that, does that sound good? >> Yeah, no, broadly aligns with my thinking, I think, and what I see from talking with customers as well. I mean, I like the, again, the, you know, listening to customer needs, prioritizing those things, focusing on some of the connective tissue networking, and data and some of these aspects talking about the open architecture, the interoperability, those are all things I think are absolutely critical. And then, yeah, like I think at the end. >> On the computer science side, do you see some science and engineering things that need to be engineered differently? We heard databases are radically going to change and that are inadequate for the new architecture. What are some of the things like that, from a science standpoint? >> Yeah, yeah, yeah. Some of the more academic research type things. >> More tech, or more better tech or is it? >> Yeah, look, absolutely. I mean I think that there's a bunch around, certainly around the data piece, around, you know, there's issues of data gravity, data mobility. How do you want to do that in a way that's performant? There's definitely issues around security as well. Like how do you enable like trust in these environments, there's got to be some sort of hardware rooted trusts, and you know, a whole bunch of various types of aspects there. >> So, a lot of work still be done. >> Yes, I think so. And that's why I look at this as, this is not a one year thing, or you know, it's going to be multi-years, and I think again, it's about all of us in the industry working together to come to an aligned picture of what that looks like. >> So, as the world's moved from private cloud to public cloud and now Cross-cloud services, supercloud, metacloud, whatever you want to call it, how have you sort of changed the way engineering's organized, developers sort of approached the problem? Has it changed and how? >> Yeah, absolutely. So, you know, it's funny, we at VMware, going through the same challenges as our customers and you know, any business, right? We use multiple clouds, we got a big, of course, on-prem footprint. You know, what we're doing is similar to what I see in many other customers, which, you see the evolution of a platform team, and so the platform team is really in charge of trying to develop a lot of these underlying services to allow our lines of business, our product teams, to be able to move as quickly as possible, to focus on the building, while we help with a lot of the operational overheads, right? We maintain security, compliance, all these other things. We also deal with, yeah, just making the developer's life as simple as possible. So, they do need to know some stuff about, you know, each public cloud they're using, those public cloud services, but at the same, time we can abstract a lot of the details they don't need to be in. So, I think this sort of delineation or separation, I should say, between the underlying platform team and the product teams is a very, very common pattern. >> You know, I noticed the four layers you talked about were observability, infrastructure, security and developers, on that slide, the last slide you had at the top, that was kind of the abstraction key areas that you guys at VMware are working? >> Those were just some groupings that we've come up with, but we like to debate them. >> I noticed data's in every one of them. >> Yeah, yep, data is key. >> It's not like, so, back to the data questions that security is called out as a pillar. Observability is just kind of watching everything, but it's all pretty much data driven. Of the four layers that you see, I take that as areas that you can. >> Standardize. >> Consistently rely on to have standard services. >> Yes. >> Which one do you start with? What's the, is there order of operations? >> Well, that's, I mean. >> 'Cause I think infrastructure's number one, but you had observability, you need to know what's going on. >> Yeah, well it really, it's highly dependent. Again, it depends on the business that we talk to and what, I mean, it really goes back to, what are your business priorities, right? And we have some customers who may want to get out of a data center, they want to evacuate the data center, and so what they want is then, consistent infrastructure, so they can just move those applications up to the cloud. They don't want to have to refactor them and we'll do it later, but there's an immediate and sort of urgent problem that they have. Other customers I talk to, you know, security becomes top of mind, or maybe compliance, because they're in a regulated industry. So, those are the sort of services they want to prioritize. So, I would say there is no single right answer, no one size fits all. The point about this architecture is really around the optionality of it, as it allows you as a business to decide what's most important and where you want to prioritize. >> How about the deployment models kit? Do, does a customer have that flexibility from a deployment model standpoint or do I have to, you know, approach it a specific way? Can you address that? >> Yeah, I mean deployment models, you're talking about how they how they consume? >> So, for instance, yeah, running a control plane in the cloud. >> Got it, got it. >> And communicating elsewhere or having a single global instance or instantiating that instance, and? >> So, that's a good point actually, and you know, the white paper that we released back in August, around this sort of concept, the Cross-cloud service. This is some of the stuff we need to figure out as an industry. So, you know when we talk about a Cross-cloud service, we can mean actually any of the things you just talked about. It could be a single instance that runs, let's say in one public cloud, but it supports all of 'em. Or it could be one that's multi-instance and that runs in each of the clouds, and that customers can take dependencies on whichever one, depending on what their use cases are or the, even going further than that, there's a type of Cross-cloud service that could actually be instantiated even in an air gapped or offline environment, and we have many, many businesses, especially heavily regulated ones that have that requirement, so I think, you know. >> Global don't forget global, regions, locales. >> Yeah, there's all sorts of performance latency issues that can be concerned about. So, most services today are the former, there are single sort of instance or set of instances within a single cloud that support multiple clouds, but I think what we're doing and where we're going with, you know, things like what we see with Kubernetes and service meshes and all these things, will better enable folks to hit these different types of cross-cloud service architectures. So, today, you as a customer probably wouldn't have too much choice, but where we're going, you'll see a lot more choice in the future. >> If you had to summarize for folks watching the importance of Supercloud movement, multi-cloud, cross-cloud services, as an industry in flexible, 'cause I'm always riffing on the whole old school network protocol stacks that got disrupted by TCP/IP, that's a little bit dated, we got people on the chat that are like, you know, 20 years old that weren't even born then. So, but this is a, one of those inflection points that's once in a generation inflection point, I'm sure you agree. What scoped the order of magnitude of the change and the opportunity around the marketplace, the business models, the technology, and ultimately benefits the society. >> Yeah. Wow. Getting bigger. >> You have 10 seconds, go. >> I know. Yeah. (laughing) No, look, so I think it is what we're seeing is really the next phase of what you might call cloud, right? This notion of delivering services, the way they've been packaged together, traditionally by the hyperscalers is now being challenged. and what we're seeing is really opening that up to new levels of innovation, and I think that will be huge for businesses because it'll help meet them where they are. Instead of needing to contort the businesses to, you know, make it work with the technology, the technology will support the business and where it's going. Give people more optionality, more flexibility in order to get there, and I think in the end, for us as individuals, it will just make for better experiences, right? You can get better performance, better interactivity, given that devices are so much of what we do, and so much of what we interact with all the time. This sort of flexibility and optionality will fundamentally better for us as individuals in our experiences. >> And we're seeing that with ChatGPT, everyone's talking about, just early days. There'll be more and more of things like that, that are next gen, like obviously like, wow, that's a fall out of your chair moment. >> It'll be the next wave of innovation that's unleashed. >> All right, Kit Colbert, thanks for coming on and sharing and exploring the Supercloud architecture, Cloud Chaos, the Cloud Smart, there's a transition progression happening and it's happening fast. This is the supercloud wave. If you're not on this wave, you'll be driftwood. That's a Pat Gelsinger quote on theCUBE. This is theCUBE Be right back with more Supercloud coverage, here in Palo Alto after this break. (upbeat music) (upbeat music continues)

(electronic music) >> Hi everybody, welcome back to Supercloud 2. I'm Dave Vellante with my co-host John Furrier. We're here at our tricked out Palo Alto studio. We're going live wall to wall all day. We're inserting a number of pre-recorded interviews, folks like Walmart. We just heard from Nir Zuk of Palo Alto Networks, and I'm really pleased to welcome in David Flynn. David Flynn, you may know as one of the people behind Fusion-io, completely changed the way in which people think about storing data, accessing data. David Flynn now the founder and CEO of a company called Hammerspace. David, good to see you, thanks for coming on. >> David: Good to see you too. >> And Dr. Nelu Mihai is the CEO and founder of Cloud of Clouds. He's actually built a Supercloud. We're going to get into that. Nelu, thanks for coming on. >> Thank you, Happy New Year. >> Yeah, Happy New Year. So I'm going to start right off with a little debate that's going on in the community if you guys would bring out this slide. So Bob Muglia early today, he gave a definition of Supercloud. He felt like we had to tighten ours up a little bit. He said a Supercloud is a platform, underscoring platform, that provides programmatically consistent services hosted on heterogeneous cloud providers. Now, Nelu, we have this shared doc, and you've been in there. You responded, you said, well, hold on. Supercloud really needs to be an architecture, or else we're going to have this stove pipe of stove pipes, really. And then you went on with more detail, what's the information model? What's the execution model? How are users going to interact with Supercloud? So I start with you, why architecture? The inference is that a platform, the platform provider's responsible for the architecture? Why does that not work in your view? >> No, the, it's a very interesting question. So whenever I think about platform, what's the connotation, you think about monolithic system? Yeah, I mean, I don't know whether it's true or or not, but there is this connotation of of monolithic. On the other hand, if you look at what's a problem right now with HyperClouds, from the customer perspective, they're very complex. There is a heterogeneous world where actually every single one of this HyperClouds has their own architecture. You need rocket scientists to build a cloud applications. Always there is this contradiction between cost and performance. They fight each other. And I'm quoting here a former friend of mine from Bell Labs who work at AWS who used to say "Cloud is cheap as long as you don't use it too much." (group chuckles) So clearly we need something that kind of plays from the principle point of view the role of an operating system, that seats on top of this heterogeneous HyperCloud, and there's nothing wrong by having these proprietary HyperClouds, think about processors, think about operating system and so on, so forth. But in order to build a system that is simple enough, I think we need to go deeper and understand. >> So the argument, the counterargument to that, David, is you'll never get there. You need a proprietary system to get to market sooner, to solve today's problem. Now I don't know where you stand on this platform versus architecture. I haven't asked you, but. >> I think there are aspects of both for sure. I mean it needs to be an architecture in the sense that it's broad based and open and so forth. But you know, platform, you could say as long as people can instantiate it themselves, on their own infrastructure, as long as it's something that can be deployed as, you know, software defined, you don't want the concept of platform being the monolith, you know, combined hardware and software. So it really depends on what you're focused on when you're saying platform, you know, I'd say as long as they software defined thing, to where it can literally run anywhere. I mean, because I really think what we're talking about here is the original concept of cloud computing. The ability to run anything anywhere, without having to care about the physical infrastructure. And what we have today is not that, the cloud today is a big mainframe in the sky, that just happens to be large enough that once you select which region, generally you have enough resources. But, you know, nowadays you don't even necessarily have enough resources in one region. and then you're kind of stuck. So we haven't really gotten to that utility model of computing. And you're also asked to rewrite your application, you know, to abandon the conveniences of high performance file access. You got to rewrite it to use object storage stuff. We have to get away from that. >> Okay, I want to just drill on that, 'cause I think I like that point about, there's not enough availability, but on the developer cloud, the original AWS premise was targeting developers, 'cause at that time, you have to provision a Sun box get a Cisco DSU/CSU, now you get on the cloud. But I think you're giving up the scale question, 'cause I think right now, scale is huge, enterprise grade versus cloud for developers. >> That's Right. >> Because I mean look at, Amazon, Azure, they got compute, they got storage, they got queuing, and some stuff. If you're doing a startup, you throw your app up there, localhost to cloud, no big deal. It's the scale thing that gets me- >> And you can tell by the fact that, in regions that are under high demand, right, like in London or LA, at least with the clients we work with in the median entertainment space, it costs twice as much for the exact same cloud instances that do the exact same amount of work, as somewhere out in rural Canada. So why is it you have such a cost differential, it has to do with that supply and demand, and the fact that the clouds aren't really the ability to run anything anywhere. Even within the same cloud vendor, you're stuck in a specific region. >> And that was never the original promise, right? I mean it was, we turned it into that. But the original promise was get rid of the heavy lifting of IT. >> Not have to run your own, yeah, exactly. >> And then it became, wow, okay I can run anywhere. And then you know, it's like web 2.0. You know people say why Supercloud, you and I talked about this, why do you need a name for Supercloud? It's like web 2.0. >> It's what Cloud was supposed to be. >> It's what cloud was supposed to be, (group laughing and talking) exactly, right. >> Cloud was supposed to be run anything anywhere, or at least that's what we took it as. But you're right, originally it was just, oh don't have to run your own infrastructure, and you can choose somebody else's infrastructure. >> And you did that >> But you're still bound to that. >> Dave: And People said I want more, right? >> But how do we go from here? >> That's, that's actually, that's a very good point, because indeed when the first HyperClouds were designed, were designed really focus on customers. I think Supercloud is an opportunity to design in the right way. Also having in mind the computer science rigor. And we should take advantage of that, because in fact actually, if cloud would've been designed properly from the beginning, probably wouldn't have needed Supercloud. >> David: You wouldn't have to have been asked to rewrite your application. >> That's correct. (group laughs) >> To use REST interfaces to your storage. >> Revisist history is always a good one. But look, cloud is great. I mean your point is cloud is a good thing. Don't hold it back. >> It is a very good thing. >> Let it continue. >> Let it go as as it is. >> Yeah, let that thing continue to grow. Don't impose restrictions on the cloud. Just refactor what you need to for scale or enterprise grade or availability. >> And you would agree with that, is that true or is it problem you're solving? >> Well yeah, I mean it, what the cloud is doing is absolutely necessary. What the public cloud vendors are doing is absolutely necessary. But what's been missing is how to provide a consistent interface, especially to persistent data. And have it be available across different regions, and across different clouds. 'cause data is a highly localized thing in current architecture. It only exists as rendered by the storage system that you put it in. Whether that's a legacy thing like a NetApp or an Isilon or even a cloud data service. It's localized to a specific region of the cloud in which you put that. We have to delocalize data, and provide a consistent interface to it across all sites. That's high performance, local access, but to global data. >> And so Walmart earlier today described their, what we call Supercloud, they call it the Walmart cloud native platform. And they use this triplet model. They have AWS and Azure, no, oh sorry, no AWS. They have Azure and GCP and then on-prem, where all the VMs live. When you, you know, probe, it turns out that it's only stateless in the cloud. (John laughs) So, the state stuff- >> Well let's just admit it, there is no such thing as stateless, because even the application binaries and libraries are state. >> Well I'm happy that I'm hearing that. >> Yeah, okay. >> Because actually I have a lot of debate (indistinct). If you think about no software running on a (indistinct) machine is stateless. >> David: Exactly. >> This is something that was- >> David: And that's data that needs to be distributed and provided consistently >> (indistinct) >> Across all the clouds, >> And actually, it's a nonsense, but- >> Dave: So it's an illusion, okay. (group talks over each other) >> (indistinct) you guys talk about stateless. >> Well, see, people make the confusion between state and persistent state, okay. Persistent state it's a different thing. State is a different thing. So, but anyway, I want to go back to your point, because there's a lot of debate here. People are talking about data, some people are talking about logic, some people are talking about networking. In my opinion is this triplet, which is data logic and connectivity, that has equal importance. And actually depending on the application, can have the center of gravity moving towards data, moving towards what I call execution units or workloads. And connectivity is actually the most important part of it. >> David: (indistinct). >> Some people are saying move the logic towards the data, some other people, and you are saying actually, that no, you have to build a distributed data mesh. What I'm saying is actually, you have to consider all these three variables, all these vector in order to decide, based on application, what's the most important. Because sometimes- >> John: So the application chooses >> That's correct. >> Well it it's what operating systems were in the past, was principally the thing that runs and manages the jobs, the job scheduler, and the thing that provides your persistent data (indistinct). >> Okay. So we finally got operating system into the equation, thank you. (group laughs) >> Nelu: I actually have a PhD in operating system. >> Cause what we're talking about is an operating system. So forget platform or architecture, it's an operating environment. Let's use it as a general term. >> All right. I think that's about it for me. >> All right, let's take (indistinct). Nelu, I want ask you quick, 'cause I want to give a, 'cause I believe it's an operating system. I think it's going to be a reset, refactored. You wrote to me, "The model of Supercloud has to be open theoretical, has to satisfy the rigors of computer science, and customer requirements." So unique to today, if the OS is going to be refactored, it's not going to be, may or may not be Red Hat or somebody else. This new OS, obviously requirements are for customers too but is what's the computer science that is needed? Where are we, what's the missing? Where's the science in this shift? It's not your standard OS it's not like an- (group talks over each other) >> I would beg to differ. >> (indistinct) truly an operation environment. But the, if you think about, and make analogies, what you need when you design a distributed system, well you need an information model, yeah. You need to figure out how the data is located and distributed. You need a model for the execution units, and you need a way to describe the interactions between all these objects. And it is my opinion that we need to go deeper and formalize these operations in order to make a step forward. And when we design Supercloud, and design something that is better than the current HyperClouds. And actually that is when we design something better, you make a system more efficient and it's going to be better from the cost point of view, from the performance point of view. But we need to add some math into all this customer focus centering and I really admire AWS and their executive team focusing on the customer. But now it's time to go back and see, if we apply some computer science, if you try to formalize to build a theoretical model of cloud, can we build a system that is better than existing ones? >> So David, how do you- >> this is what I'm saying. >> That's a good question >> How do You see the operating system of a, or operating environment of a decentralized cloud? >> Well I think it's layered. I mean we have operating systems that can run systems quite efficiently. Linux has sort of one in the data center, but we're talking about a layer on top of that. And I think we're seeing the emergence of that. For example, on the job scheduling side of things, Kubernetes makes a really good example. You know, you break the workload into the most granular units of compute, the containerized microservice, and then you use a declarative model to state what is needed and give the system the degrees of freedom that it can choose how to instantiate it. Because the thing about these distributed systems, is that the complexity explodes, right? Running a piece of hardware, running a single server is not a problem, even with all the many cores and everything like that. It's when you start adding in the networking, and making it so that you have many of them. And then when it's going across whole different data centers, you know, so, at that level the way you solve this is not manually (group laughs) and not procedurally. You have to change the language so it's intent based, it's a declarative model, and what you're stating is what is intended, and you're leaving it to more advanced techniques, like machine learning to decide how to instantiate that service across the cluster, which is what Kubernetes does, or how to instantiate the data across the diverse storage infrastructure. And that's what we do. >> So that's a very good point because actually what has been neglected with HyperClouds is really optimization and automation. But in order to be able to do both of these things, you need, I'm going back and I'm stubborn, you need to have a mathematical model, a theoretical model because what does automation mean? It means that we have to put machines to do the work instead of us, and machines work with what? Formula, with algorithms, they don't work with services. So I think Supercloud is an opportunity to underscore the importance of optimization and automation- >> Totally agree. >> In HyperCloud, and actually by doing that, we can also have an interesting connotation. We are also contributing to save our planet, because if you think right now. we're consuming a lot of energy on this HyperClouds and also all this AI applications, and I think we can do better and build the same kind of application using less energy. >> So yeah, great point, love that call out, the- you know, Dave and I always joke about the old, 'cause we're old, we talk about, you know, (Nelu Laughs) old history, OS/2 versus DOS, okay, OS's, OS/2 is silly better, first threaded OS, DOS never went away. So how does legacy play into this conversation? Because I buy the theoretical, I love the conversation. Okay, I think it's an OS, totally see it that way myself. What's the blocker? Is there a legacy that drags it back? Is the anchor dragging from legacy? Is there a DOS OS/2 moment? Is there an opportunity to flip the script? This is- >> I think that's a perfect example of why we need to support the existing interfaces, Operating Systems, real operating systems like Linux, understands how to present data, it's called a file system, block devices, things that that plumb in there. And by, you know, going to a REST interface and S3 and telling people they have to rewrite their applications, you can't even consume your application binaries that way, the OS doesn't know how to pull that sort of thing. So we, to get to cloud, to get to the ability to host massive numbers of tenants within a centralized infrastructure, you know, we abandoned these lower level interfaces to the OS and we have to go back to that. It's the reason why DOS ultimately won, is it had the momentum of the install base. We're seeing the same thing here. Whatever it is, it has to be a real file system and not a come down file system >> Nelu, what's your reaction, 'cause you're in the theoretical bandwagon. Let's get your reaction. >> No, I think it's a good, I'll give, you made a good analogy between OS/2 and DOS, but I'll go even farther saying, if you think about the evolution operating system didn't stop the evolution of underlying microprocessors, hardware, and so on and so forth. On the contrary, it was a catalyst for that. So because everybody could develop their own hardware, without worrying that the applications on top of operating system are going to modify. The same thing is going to happen with Supercloud. You're going to have the AWSs, you're going to have the Azure and the the GCP continue to evolve in their own way proprietary. But if we create on top of it the right interface >> The open, this is why open is important. >> That's correct, because actually you're going to see sometime ago, everybody was saying, remember venture capitals were saying, "AWS killed the world, nobody's going to come." Now you see what Oracle is doing, and then you're going to see other players. >> It's funny, Amazon's trying to be more like Microsoft. Microsoft's trying to be more like Amazon and Google- Oracle's just trying to say they have cloud. >> That's, that's correct, (group laughs) so, my point is, you're going to see a multiplication of this HyperClouds and cloud technology. So, the system has to be open in order to accommodate what it is and what is going to come. Okay, so it's open. >> So the the legacy- so legacy is an opportunity, not a blocker in your mind. And you see- >> That's correct, I think we should allow them to continue to to to be their own actually. But maybe you're going to find a way to connect with it. >> Amazon's the processor, and they're on the 80 80 80 right? >> That's correct. >> You're saying you love people trying to get put to work. >> That's a good analogy. >> But, performance levels you say good luck, right? >> Well yeah, we have to be able to take traditional applications, high performance applications, those that consume file system and persistent data. Those things have to be able to run anywhere. You need to be able to put, put them onto, you know, more elastic infrastructure. So, we have to actually get cloud to where it lives up to its billing. >> And that's what you're solving for, with Hammerspace, >> That's what we're solving for, making it possible- >> Give me the bumper sticker. >> Solving for how do you have massive quantities of unstructured file data? At the end of the day, all data ultimately is unstructured data. Have that persistent data available, across any data center, within any cloud, within any region on-prem, at the edge. And have not just the same APIs, but have the exact same data sets, and not sucked over a straw remote, but at extreme high performance, local access. So how do you have local access to globally shared distributed data? And that's what we're doing. We are orchestrating data globally across all different forms of storage infrastructure, so you have a consistent access at the highest performance levels, at the lowest level innate built into the OS, how to consume it as (indistinct) >> So are you going into the- all the clouds and natively building in there, or are you off cloud? >> So This is software that can run on cloud instances and provide high performance file within the cloud. It can take file data that's on-prem. Again, it's software, it can run in virtual or on physical servers. And it abstracts the data from the existing storage infrastructure, and makes the data visible and consumable and orchestratable across any of it. >> And what's the elevator pitch for Cloud of Cloud, give that too. >> Well, Cloud of Clouds creates a theoretical model of cloud, and it describes every single object in the cloud. Where is data, execution units, and connectivity, with one single class of very simple object. And I can, I can give you (indistinct) >> And the problem that solves is what? >> The problem that solves is, it creates this mathematical model that is necessary in order to do other interesting things, such as optimization, using sata engines, using automation, applying ML for instance. Or deep learning to automate all this clouds, if you think about in the industrial field, we know how to manage and automate huge plants. Why wouldn't it do the same thing in cloud? It's the same thing you- >> That's what you mean by theoretical model. >> Nelu: That's correct. >> Lay out the architecture, almost the bones of skeleton or something, or, and then- >> That's correct, and then on top of it you can actually build a platform, You can create your services, >> when you say math, you mean you put numbers to it, you kind of index it. >> You quantify this thing and you apply mathematical- It's really about, I can disclose this thing. It's really about describing the cloud as a knowledge graph for every single object in the graph for node, an edge is a vector. And then once you have this model, then you can apply the field theory, and linear algebra to do operation with these vectors. And it's, this creates a very interesting opportunity to let the math do this thing for us. >> Okay, so what happens with hyperscale, or it's like AWS in your model. >> So in, in my model actually, >> Are they happy with this, or they >> I'm very happy with that. >> Will they be happy with you? >> We create an interface to every single HyperCloud. We actually, we don't need to interface with the thousands of APIs, but you know, if we have the 80 20 rule, and we map these APIs into this graph, and then every single operation that is done in this graph is done from the beginning, in an optimized manner and also automation ready. >> That's going to be great. David, I want us to go back to you before we close real quick. You've had a lot of experience, multiple ventures on the front end. You talked to a lot of customers who've been innovating. Where are the classic (indistinct)? Cause you, you used to sell and invent product around the old school enterprises with storage, you know that that trajectory storage is still critical to store the data. Where's the classic enterprise grade mindset right now? Those customers that were buying, that are buying storage, they're in the cloud, they're lifting and shifting. They not yet put the throttle on DevOps. When they look at this Supercloud thing, Are they like a deer in the headlights, or are they like getting it? What's the, what's the classic enterprise look like? >> You're seeing people at different stages of adoption. Some folks are trying to get to the cloud, some folks are trying to repatriate from the cloud, because they've realized it's better to own than to rent when you use a lot of it. And so people are at very different stages of the journey. But the one thing that's constant is that there's always change. And the change here has to do with being able to change the location where you're doing your computing. So being able to support traditional workloads in the cloud, being able to run things at the edge, and being able to rationalize where the data ought to exist, and with a declarative model, intent-based, business objective-based, be able to swipe a mouse and have the data get redistributed and positioned across different vendors, across different clouds, that, we're seeing that as really top of mind right now, because everybody's at some point on this journey, trying to go somewhere, and it involves taking their data with them. (John laughs) >> Guys, great conversation. Thanks so much for coming on, for John, Dave. Stay tuned, we got a great analyst power panel coming right up. More from Palo Alto, Supercloud 2. Be right back. (bouncy music)

(bright upbeat music) >> In 2011, early Facebook employee and Cloudera co-founder Jeff Hammerbacher famously said, "The best minds of my generation are thinking about how to get people to click on ads, and that sucks!" Let's face it. More than a decade later, organizations continue to be frustrated with how difficult it is to get value from data and build a truly agile and data-driven enterprise. What does that even mean, you ask? Well, it means that everyone in the organization has the data they need when they need it in a context that's relevant to advance the mission of an organization. Now, that could mean cutting costs, could mean increasing profits, driving productivity, saving lives, accelerating drug discovery, making better diagnoses, solving supply chain problems, predicting weather disasters, simplifying processes, and thousands of other examples where data can completely transform people's lives beyond manipulating internet users to behave a certain way. We've heard the prognostications about the possibilities of data before and in fairness we've made progress, but the hard truth is the original promises of master data management, enterprise data warehouses, data marts, data hubs, and yes even data lakes were broken and left us wanting for more. Welcome to The Data Doesn't Lie... Or Does It? A series of conversations produced by theCUBE and made possible by Starburst Data. I'm your host, Dave Vellante, and joining me today are three industry experts. Justin Borgman is the co-founder and CEO of Starburst, Richard Jarvis is the CTO at EMIS Health, and Teresa Tung is cloud first technologist at Accenture. Today, we're going to have a candid discussion that will expose the unfulfilled, and yes, broken promises of a data past. We'll expose data lies: big lies, little lies, white lies, and hidden truths. And we'll challenge, age old data conventions and bust some data myths. We're debating questions like is the demise of a single source of truth inevitable? Will the data warehouse ever have feature parity with the data lake or vice versa? Is the so-called modern data stack simply centralization in the cloud, AKA the old guards model in new cloud close? How can organizations rethink their data architectures and regimes to realize the true promises of data? Can and will an open ecosystem deliver on these promises in our lifetimes? We're spanning much of the Western world today. Richard is in the UK, Teresa is on the West Coast, and Justin is in Massachusetts with me. I'm in theCUBE studios, about 30 miles outside of Boston. Folks, welcome to the program. Thanks for coming on. >> Thanks for having us. >> Okay, let's get right into it. You're very welcome. Now, here's the first lie. The most effective data architecture is one that is centralized with a team of data specialists serving various lines of business. What do you think Justin? >> Yeah, definitely a lie. My first startup was a company called Hadapt, which was an early SQL engine for IDU that was acquired by Teradata. And when I got to Teradata, of course, Teradata is the pioneer of that central enterprise data warehouse model. One of the things that I found fascinating was that not one of their customers had actually lived up to that vision of centralizing all of their data into one place. They all had data silos. They all had data in different systems. They had data on prem, data in the cloud. Those companies were acquiring other companies and inheriting their data architecture. So despite being the industry leader for 40 years, not one of their customers truly had everything in one place. So I think definitely history has proven that to be a lie. >> So Richard, from a practitioner's point of view, what are your thoughts? I mean, there's a lot of pressure to cut cost, keep things centralized, serve the business as best as possible from that standpoint. What does your experience show? >> Yeah, I mean, I think I would echo Justin's experience really that we as a business have grown up through acquisition, through storing data in different places sometimes to do information governance in different ways to store data in a platform that's close to data experts people who really understand healthcare data from pharmacies or from doctors. And so, although if you were starting from a greenfield site and you were building something brand new, you might be able to centralize all the data and all of the tooling and teams in one place. The reality is that businesses just don't grow up like that. And it's just really impossible to get that academic perfection of storing everything in one place. >> Teresa, I feel like Sarbanes-Oxley have kind of saved the data warehouse, right? (laughs) You actually did have to have a single version of the truth for certain financial data, but really for some of those other use cases I mentioned, I do feel like the industry has kind of let us down. What's your take on this? Where does it make sense to have that sort of centralized approach versus where does it make sense to maybe decentralize? >> I think you got to have centralized governance, right? So from the central team, for things like Sarbanes-Oxley, for things like security, for certain very core data sets having a centralized set of roles, responsibilities to really QA, right? To serve as a design authority for your entire data estate, just like you might with security, but how it's implemented has to be distributed. Otherwise, you're not going to be able to scale, right? So being able to have different parts of the business really make the right data investments for their needs. And then ultimately, you're going to collaborate with your partners. So partners that are not within the company, right? External partners. We're going to see a lot more data sharing and model creation. And so you're definitely going to be decentralized. >> So Justin, you guys last, jeez, I think it was about a year ago, had a session on data mesh. It was a great program. You invited Zhamak Dehghani. Of course, she's the creator of the data mesh. One of our fundamental premises is that you've got this hyper specialized team that you've got to go through if you want anything. But at the same time, these individuals actually become a bottleneck, even though they're some of the most talented people in the organization. So I guess, a question for you Richard. How do you deal with that? Do you organize so that there are a few sort of rock stars that build cubes and the like or have you had any success in sort of decentralizing with your constituencies that data model? >> Yeah. So we absolutely have got rockstar data scientists and data guardians, if you like. People who understand what it means to use this data, particularly the data that we use at EMIS is very private, it's healthcare information. And some of the rules and regulations around using the data are very complex and strict. So we have to have people who understand the usage of the data, then people who understand how to build models, how to process the data effectively. And you can think of them like consultants to the wider business because a pharmacist might not understand how to structure a SQL query, but they do understand how they want to process medication information to improve patient lives. And so that becomes a consulting type experience from a set of rock stars to help a more decentralized business who needs to understand the data and to generate some valuable output. >> Justin, what do you say to a customer or prospect that says, "Look, Justin. I got a centralized team and that's the most cost effective way to serve the business. Otherwise, I got duplication." What do you say to that? >> Well, I would argue it's probably not the most cost effective, and the reason being really twofold. I think, first of all, when you are deploying a enterprise data warehouse model, the data warehouse itself is very expensive, generally speaking. And so you're putting all of your most valuable data in the hands of one vendor who now has tremendous leverage over you for many, many years to come. I think that's the story at Oracle or Teradata or other proprietary database systems. But the other aspect I think is that the reality is those central data warehouse teams, as much as they are experts in the technology, they don't necessarily understand the data itself. And this is one of the core tenets of data mesh that Zhamak writes about is this idea of the domain owners actually know the data the best. And so by not only acknowledging that data is generally decentralized, and to your earlier point about Sarbanes-Oxley, maybe saving the data warehouse, I would argue maybe GDPR and data sovereignty will destroy it because data has to be decentralized for those laws to be compliant. But I think the reality is the data mesh model basically says data's decentralized and we're going to turn that into an asset rather than a liability. And we're going to turn that into an asset by empowering the people that know the data the best to participate in the process of curating and creating data products for consumption. So I think when you think about it that way, you're going to get higher quality data and faster time to insight, which is ultimately going to drive more revenue for your business and reduce costs. So I think that that's the way I see the two models comparing and contrasting. >> So do you think the demise of the data warehouse is inevitable? Teresa, you work with a lot of clients. They're not just going to rip and replace their existing infrastructure. Maybe they're going to build on top of it, but what does that mean? Does that mean the EDW just becomes less and less valuable over time or it's maybe just isolated to specific use cases? What's your take on that? >> Listen, I still would love all my data within a data warehouse. I would love it mastered, would love it owned by a central team, right? I think that's still what I would love to have. That's just not the reality, right? The investment to actually migrate and keep that up to date, I would say it's a losing battle. Like we've been trying to do it for a long time. Nobody has the budgets and then data changes, right? There's going to be a new technology that's going to emerge that we're going to want to tap into. There's going to be not enough investment to bring all the legacy, but still very useful systems into that centralized view. So you keep the data warehouse. I think it's a very, very valuable, very high performance tool for what it's there for, but you could have this new mesh layer that still takes advantage of the things I mentioned: the data products in the systems that are meaningful today, and the data products that actually might span a number of systems. Maybe either those that either source systems with the domains that know it best, or the consumer-based systems or products that need to be packaged in a way that'd be really meaningful for that end user, right? Each of those are useful for a different part of the business and making sure that the mesh actually allows you to use all of them. >> So, Richard, let me ask you. Take Zhamak's principles back to those. You got the domain ownership and data as product. Okay, great. Sounds good. But it creates what I would argue are two challenges: self-serve infrastructure, let's park that for a second, and then in your industry, one of the most regulated, most sensitive, computational governance. How do you automate and ensure federated governance in that mesh model that Teresa was just talking about? >> Well, it absolutely depends on some of the tooling and processes that you put in place around those tools to centralize the security and the governance of the data. And I think although a data warehouse makes that very simple 'cause it's a single tool, it's not impossible with some of the data mesh technologies that are available. And so what we've done at EMIS is we have a single security layer that sits on top of our data mesh, which means that no matter which user is accessing which data source, we go through a well audited, well understood security layer. That means that we know exactly who's got access to which data field, which data tables. And then everything that they do is audited in a very kind of standard way regardless of the underlying data storage technology. So for me, although storing the data in one place might not be possible, understanding where your source of truth is and securing that in a common way is still a valuable approach, and you can do it without having to bring all that data into a single bucket so that it's all in one place. And so having done that and investing quite heavily in making that possible has paid dividends in terms of giving wider access to the platform, and ensuring that only data that's available under GDPR and other regulations is being used by the data users. >> Yeah. So Justin, we always talk about data democratization, and up until recently, they really haven't been line of sight as to how to get there, but do you have anything to add to this because you're essentially doing analytic queries with data that's all dispersed all over. How are you seeing your customers handle this challenge? >> Yeah, I mean, I think data products is a really interesting aspect of the answer to that. It allows you to, again, leverage the data domain owners, the people who know the data the best, to create data as a product ultimately to be consumed. And we try to represent that in our product as effectively, almost eCommerce like experience where you go and discover and look for the data products that have been created in your organization, and then you can start to consume them as you'd like. And so really trying to build on that notion of data democratization and self-service, and making it very easy to discover and start to use with whatever BI tool you may like or even just running SQL queries yourself. >> Okay guys, grab a sip of water. After the short break, we'll be back to debate whether proprietary or open platforms are the best path to the future of data excellence. Keep it right there. (bright upbeat music)

>> From theCUBE studios in Palo Alto and Boston, bringing you data-driven insights from theCUBE and ETR. This is braking analysis with Dave Vellante. >> A new era of data is upon us, and we're in a state of transition. You know, even our language reflects that. We rarely use the phrase big data anymore, rather we talk about digital transformation or digital business, or data-driven companies. Many have come to the realization that data is a not the new oil, because unlike oil, the same data can be used over and over for different purposes. We still use terms like data as an asset. However, that same narrative, when it's put forth by the vendor and practitioner communities, includes further discussions about democratizing and sharing data. Let me ask you this, when was the last time you wanted to share your financial assets with your coworkers or your partners or your customers? Hello everyone, and welcome to this week's Wikibon Cube Insights powered by ETR. In this breaking analysis, we want to share our assessment of the state of the data business. We'll do so by looking at the data mesh concept and how a leading financial institution, JP Morgan Chase is practically applying these relatively new ideas to transform its data architecture. Let's start by looking at what is the data mesh. As we've previously reported many times, data mesh is a concept and set of principles that was introduced in 2018 by Zhamak Deghani who's director of technology at ThoughtWorks, it's a global consultancy and software development company. And she created this movement because her clients, who were some of the leading firms in the world had invested heavily in predominantly monolithic data architectures that had failed to deliver desired outcomes in ROI. So her work went deep into trying to understand that problem. And her main conclusion that came out of this effort was the world of data is distributed and shoving all the data into a single monolithic architecture is an approach that fundamentally limits agility and scale. Now a profound concept of data mesh is the idea that data architectures should be organized around business lines with domain context. That the highly technical and hyper specialized roles of a centralized cross functional team are a key blocker to achieving our data aspirations. This is the first of four high level principles of data mesh. So first again, that the business domain should own the data end-to-end, rather than have it go through a centralized big data technical team. Second, a self-service platform is fundamental to a successful architectural approach where data is discoverable and shareable across an organization and an ecosystem. Third, product thinking is central to the idea of data mesh. In other words, data products will power the next era of data success. And fourth data products must be built with governance and compliance that is automated and federated. Now there's lot more to this concept and there are tons of resources on the web to learn more, including an entire community that is formed around data mesh. But this should give you a basic idea. Now, the other point is that, in observing Zhamak Deghani's work, she is deliberately avoided discussions around specific tooling, which I think has frustrated some folks because we all like to have references that tie to products and tools and companies. So this has been a two-edged sword in that, on the one hand it's good, because data mesh is designed to be tool agnostic and technology agnostic. On the other hand, it's led some folks to take liberties with the term data mesh and claim mission accomplished when their solution, you know, maybe more marketing than reality. So let's look at JP Morgan Chase in their data mesh journey. Is why I got really excited when I saw this past week, a team from JPMC held a meet up to discuss what they called, data lake strategy via data mesh architecture. I saw that title, I thought, well, that's a weird title. And I wondered, are they just taking their legacy data lakes and claiming they're now transformed into a data mesh? But in listening to the presentation, which was over an hour long, the answer is a definitive no, not at all in my opinion. A gentleman named Scott Hollerman organized the session that comprised these three speakers here, James Reid, who's a divisional CIO at JPMC, Arup Nanda who is a technologist and architect and Serita Bakst who is an information architect, again, all from JPMC. This was the most detailed and practical discussion that I've seen to date about implementing a data mesh. And this is JP Morgan's their approach, and we know they're extremely savvy and technically sound. And they've invested, it has to be billions in the past decade on data architecture across their massive company. And rather than dwell on the downsides of their big data past, I was really pleased to see how they're evolving their approach and embracing new thinking around data mesh. So today, we're going to share some of the slides that they use and comment on how it dovetails into the concept of data mesh that Zhamak Deghani has been promoting, and at least as we understand it. And dig a bit into some of the tooling that is being used by JP Morgan, particularly around it's AWS cloud. So the first point is it's all about business value, JPMC, they're in the money business, and in that world, business value is everything. So Jr Reid, the CIO showed this slide and talked about their overall goals, which centered on a cloud first strategy to modernize the JPMC platform. I think it's simple and sensible, but there's three factors on which he focused, cut costs always short, you got to do that. Number two was about unlocking new opportunities, or accelerating time to value. But I was really happy to see number three, data reuse. That's a fundamental value ingredient in the slide that he's presenting here. And his commentary was all about aligning with the domains and maximizing data reuse, i.e. data is not like oil and making sure there's appropriate governance around that. Now don't get caught up in the term data lake, I think it's just how JP Morgan communicates internally. It's invested in the data lake concept, so they use water analogies. They use things like data puddles, for example, which are single project data marts or data ponds, which comprise multiple data puddles. And these can feed in to data lakes. And as we'll see, JPMC doesn't strive to have a single version of the truth from a data standpoint that resides in a monolithic data lake, rather it enables the business lines to create and own their own data lakes that comprise fit for purpose data products. And they do have a single truth of metadata. Okay, we'll get to that. But generally speaking, each of the domains will own end-to-end their own data and be responsible for those data products, we'll talk about that more. Now the genesis of this was sort of a cloud first platform, JPMC is leaning into public cloud, which is ironic since the early days, in the early days of cloud, all the financial institutions were like never. Anyway, JPMC is going hard after it, they're adopting agile methods and microservices architectures, and it sees cloud as a fundamental enabler, but it recognizes that on-prem data must be part of the data mesh equation. Here's a slide that starts to get into some of that generic tooling, and then we'll go deeper. And I want to make a couple of points here that tie back to Zhamak Deghani's original concept. The first is that unlike many data architectures, this puts data as products right in the fat middle of the chart. The data products live in the business domains and are at the heart of the architecture. The databases, the Hadoop clusters, the files and APIs on the left-hand side, they serve the data product builders. The specialized roles on the right hand side, the DBA's, the data engineers, the data scientists, the data analysts, we could have put in quality engineers, et cetera, they serve the data products. Because the data products are owned by the business, they inherently have the context that is the middle of this diagram. And you can see at the bottom of the slide, the key principles include domain thinking, an end-to-end ownership of the data products. They build it, they own it, they run it, they manage it. At the same time, the goal is to democratize data with a self-service as a platform. One of the biggest points of contention of data mesh is governance. And as Serita Bakst said on the Meetup, metadata is your friend, and she kind of made a joke, she said, "This sounds kind of geeky, but it's important to have a metadata catalog to understand where data resides and the data lineage in overall change management. So to me, this really past the data mesh stink test pretty well. Let's look at data as products. CIO Reid said the most difficult thing for JPMC was getting their heads around data product, and they spent a lot of time getting this concept to work. Here's the slide they use to describe their data products as it related to their specific industry. They set a common language and taxonomy is very important, and you can imagine how difficult that was. He said, for example, it took a lot of discussion and debate to define what a transaction was. But you can see at a high level, these three product groups around wholesale, credit risk, party, and trade and position data as products, and each of these can have sub products, like, party, we'll have to know your customer, KYC for example. So a key for JPMC was to start at a high level and iterate to get more granular over time. So lots of decisions had to be made around who owns the products and the sub-products. The product owners interestingly had to defend why that product should even exist, what boundaries should be in place and what data sets do and don't belong in the various products. And this was a collaborative discussion, I'm sure there was contention around that between the lines of business. And which sub products should be part of these circles? They didn't say this, but tying it back to data mesh, each of these products, whether in a data lake or a data hub or a data pond or data warehouse, data puddle, each of these is a node in the global data mesh that is discoverable and governed. And supporting this notion, Serita said that, "This should not be infrastructure-bound, logically, any of these data products, whether on-prem or in the cloud can connect via the data mesh." So again, I felt like this really stayed true to the data mesh concept. Well, let's look at some of the key technical considerations that JPM discussed in quite some detail. This chart here shows a diagram of how JP Morgan thinks about the problem, and some of the challenges they had to consider were how to write to various data stores, can you and how can you move data from one data store to another? How can data be transformed? Where's the data located? Can the data be trusted? How can it be easily accessed? Who has the right to access that data? These are all problems that technology can help solve. And to address these issues, Arup Nanda explained that the heart of this slide is the data in ingestor instead of ETL. All data producers and contributors, they send their data to the ingestor and the ingestor then registers the data so it's in the data catalog. It does a data quality check and it tracks the lineage. Then, data is sent to the router, which persists the data in the data store based on the best destination as informed by the registration. This is designed to be a flexible system. In other words, the data store for a data product is not fixed, it's determined at the point of inventory, and that allows changes to be easily made in one place. The router simply reads that optimal location and sends it to the appropriate data store. Nowadays you see the schema infer there is used when there is no clear schema on right. In this case, the data product is not allowed to be consumed until the schema is inferred, and then the data goes into a raw area, and the inferer determines the schema and then updates the inventory system so that the data can be routed to the proper location and properly tracked. So that's some of the detail of how the sausage factory works in this particular use case, it was very interesting and informative. Now let's take a look at the specific implementation on AWS and dig into some of the tooling. As described in some detail by Arup Nanda, this diagram shows the reference architecture used by this group within JP Morgan, and it shows all the various AWS services and components that support their data mesh approach. So start with the authorization block right there underneath Kinesis. The lake formation is the single point of entitlement and has a number of buckets including, you can see there the raw area that we just talked about, a trusted bucket, a refined bucket, et cetera. Depending on the data characteristics at the data catalog registration block where you see the glue catalog, that determines in which bucket the router puts the data. And you can see the many AWS services in use here, identity, the EMR, the elastic MapReduce cluster from the legacy Hadoop work done over the years, the Redshift Spectrum and Athena, JPMC uses Athena for single threaded workloads and Redshift Spectrum for nested types so they can be queried independent of each other. Now remember very importantly, in this use case, there is not a single lake formation, rather than multiple lines of business will be authorized to create their own lakes, and that creates a challenge. So how can that be done in a flexible and automated manner? And that's where the data mesh comes into play. So JPMC came up with this federated lake formation accounts idea, and each line of business can create as many data producer or consumer accounts as they desire and roll them up into their master line of business lake formation account. And they cross-connect these data products in a federated model. And these all roll up into a master glue catalog so that any authorized user can find out where a specific data element is located. So this is like a super set catalog that comprises multiple sources and syncs up across the data mesh. So again to me, this was a very well thought out and practical application of database. Yes, it includes some notion of centralized management, but much of that responsibility has been passed down to the lines of business. It does roll up to a master catalog, but that's a metadata management effort that seems compulsory to ensure federated and automated governance. As well at JPMC, the office of the chief data officer is responsible for ensuring governance and compliance throughout the federation. All right, so let's take a look at some of the suspects in this world of data mesh and bring in the ETR data. Now, of course, ETR doesn't have a data mesh category, there's no such thing as that data mesh vendor, you build a data mesh, you don't buy it. So, what we did is we use the ETR dataset to select and filter on some of the culprits that we thought might contribute to the data mesh to see how they're performing. This chart depicts a popular view that we often like to share. It's a two dimensional graphic with net score or spending momentum on the vertical axis and market share or pervasiveness in the data set on the horizontal axis. And we filtered the data on sectors such as analytics, data warehouse, and the adjacencies to things that might fit into data mesh. And we think that these pretty well reflect participation that data mesh is certainly not all compassing. And it's a subset obviously, of all the vendors who could play in the space. Let's make a few observations. Now as is often the case, Azure and AWS, they're almost literally off the charts with very high spending velocity and large presence in the market. Oracle you can see also stands out because much of the world's data lives inside of Oracle databases. It doesn't have the spending momentum or growth, but the company remains prominent. And you can see Google Cloud doesn't have nearly the presence in the dataset, but it's momentum is highly elevated. Remember that red dotted line there, that 40% line, anything over that indicates elevated spending momentum. Let's go to Snowflake. Snowflake is consistently shown to be the gold standard in net score in the ETR dataset. It continues to maintain highly elevated spending velocity in the data. And in many ways, Snowflake with its data marketplace and its data cloud vision and data sharing approach, fit nicely into the data mesh concept. Now, a caution, Snowflake has used the term data mesh in it's marketing, but in our view, it lacks clarity, and we feel like they're still trying to figure out how to communicate what that really is. But is really, we think a lot of potential there to that vision. Databricks is also interesting because the firm has momentum and we expect further elevated levels in the vertical axis in upcoming surveys, especially as it readies for its IPO. The firm has a strong product and managed service, and is really one to watch. Now we included a number of other database companies for obvious reasons like Redis and Mongo, MariaDB, Couchbase and Terradata. SAP as well is in there, but that's not all database, but SAP is prominent so we included them. As is IBM more of a database, traditional database player also with the big presence. Cloudera includes Hortonworks and HPE Ezmeral comprises the MapR business that HPE acquired. So these guys got the big data movement started, between Cloudera, Hortonworks which is born out of Yahoo, which was the early big data, sorry early Hadoop innovator, kind of MapR when it's kind of owned course, and now that's all kind of come together in various forms. And of course, we've got Talend and Informatica are there, they are two data integration companies that are worth noting. We also included some of the AI and ML specialists and data science players in the mix like DataRobot who just did a monster $250 million round. Dataiku, H2O.ai and ThoughtSpot, which is all about democratizing data and injecting AI, and I think fits well into the data mesh concept. And you know we put VMware Cloud in there for reference because it really is the predominant on-prem infrastructure platform. All right, let's wrap with some final thoughts here, first, thanks a lot to the JP Morgan team for sharing this data. I really want to encourage practitioners and technologists, go to watch the YouTube of that meetup, we'll include it in the link of this session. And thank you to Zhamak Deghani and the entire data mesh community for the outstanding work that you're doing, challenging the established conventions of monolithic data architectures. The JPM presentation, it gives you real credibility, it takes Data Mesh well beyond concept, it demonstrates how it can be and is being done. And you know, this is not a perfect world, you're going to start somewhere and there's going to be some failures, the key is to recognize that shoving everything into a monolithic data architecture won't support massive scale and agility that you're after. It's maybe fine for smaller use cases in smaller firms, but if you're building a global platform in a data business, it's time to rethink data architecture. Now much of this is enabled by the cloud, but cloud first doesn't mean cloud only, doesn't mean you'll leave your on-prem data behind, on the contrary, you have to include non-public cloud data in your Data Mesh vision just as JPMC has done. You've got to get some quick wins, that's crucial so you can gain credibility within the organization and grow. And one of the key takeaways from the JP Morgan team is, there is a place for dogma, like organizing around data products and domains and getting that right. On the other hand, you have to remain flexible because technologies is going to come, technology is going to go, so you got to be flexible in that regard. And look, if you're going to embrace the metaphor of water like puddles and ponds and lakes, we suggest maybe a little tongue in cheek, but still we believe in this, that you expand your scope to include data ocean, something John Furry and I have talked about and laughed about extensively in theCUBE. Data oceans, it's huge. It's the new data lake, go transcend data lake, think oceans. And think about this, just as we're evolving our language, we should be evolving our metrics. Much the last the decade of big data was around just getting the stuff to work, getting it up and running, standing up infrastructure and managing massive, how much data you got? Massive amounts of data. And there were many KPIs built around, again, standing up that infrastructure, ingesting data, a lot of technical KPIs. This decade is not just about enabling better insights, it's a more than that. Data mesh points us to a new era of data value, and that requires the new metrics around monetizing data products, like how long does it take to go from data product conception to monetization? And how does that compare to what it is today? And what is the time to quality if the business owns the data, and the business has the context? the quality that comes out of them, out of the shoot should be at a basic level, pretty good, and at a higher mark than out of a big data team with no business context. Automation, AI, and very importantly, organizational restructuring of our data teams will heavily contribute to success in the coming years. So we encourage you, learn, lean in and create your data future. Okay, that's it for now, remember these episodes, they're all available as podcasts wherever you listen, all you got to do is search, breaking analysis podcast, and please subscribe. Check out ETR's website at etr.plus for all the data and all the survey information. We publish a full report every week on wikibon.com and siliconangle.com. And you can get in touch with us, email me david.vellante@siliconangle.com, you can DM me @dvellante, or you can comment on my LinkedIn posts. This is Dave Vellante for theCUBE insights powered by ETR. Have a great week everybody, stay safe, be well, and we'll see you next time. (upbeat music)

from the cube studios in palo alto in boston bringing you data-driven insights from the cube and etr this is breaking analysis with dave vellante aws is pointing the way to a revolution in system architecture much in the same way that aws defined the cloud operating model last decade we believe it is once again leading in future systems design the secret sauce underpinning these innovations is specialized designs that break the stranglehold of inefficient and bloated centralized processing and allows aws to accommodate a diversity of workloads that span cloud data center as well as the near and far edge hello and welcome to this week's wikibon cube insights powered by etr in this breaking analysis we'll dig into the moves that aws has been making which we believe define the future of computing we'll also project what this means for customers partners and aws many competitors now let's take a look at aws's architectural journey the is revolution it started by giving easy access as we all know to virtual machines that could be deployed and decommissioned on demand amazon at the time used a highly customized version of zen that allowed multiple vms to run on one physical machine the hypervisor functions were controlled by x86 now according to werner vogels as much as 30 of the processing was wasted meaning it was supporting hypervisor functions and managing other parts of the system including the storage and networking these overheads led to aws developing custom asics that help to accelerate workloads now in 2013 aws began shipping custom chips and partnered with amd to announce ec2 c3 instances but as the as the aws cloud started to scale they really weren't satisfied with the performance gains that they were getting and they were hitting architectural barriers that prompted aws to start a partnership with anaperta labs this was back in 2014 and they launched then ec2 c4 instances in 2015. the asic in c4 optimized offload functions for storage and networking but still relied on intel xeon as the control point aws aws shelled out a reported 350 million dollars to acquire annapurna in 2015 which is a meager sum to acquire the secret sauce of its future system design this acquisition led to a modern version of project nitro in 2017 nitro nitro offload cards were first introduced in 2013 at this time aws introduced c5 instances and replaced zen with kvm and more tightly coupled the hypervisor with the asic vogels shared last year that this milestone offloaded the remaining components including the control plane the rest of the i o and enabled nearly a hundred percent of the processing to support customer workloads it also enabled a bare metal version of the compute that spawned the partnership the famous partnership with vmware to launch vmware cloud on aws then in 2018 aws took the next step and introduced graviton its custom designed arm-based chip this broke the dependency on x86 and launched a new era of architecture which now supports a wide variety of configurations to support data intensive workloads now these moves preceded other aws innovations including new chips optimized for machine learning and training and inferencing and all kinds of ai the bottom line is aws has architected an approach that offloaded the work currently done by the central processing unit in most general purpose workloads like in the data center it has set the stage in our view for the future allowing shared memory memory disaggregation and independent resources that can be configured to support workloads from the cloud all the way to the edge and nitro is the key to this architecture and to summarize aws nitro think of it as a set of custom hardware and software that runs on an arm-based platform from annapurna aws has moved the hypervisor the network the storage virtualization to dedicated hardware that frees up the cpu to run more efficiently this in our opinion is where the entire industry is headed so let's take a look at that this chart pulls data from the etr data set and lays out key players competing for the future of cloud data center and the edge now we've superimposed nvidia up top and intel they don't show up directly in the etr survey but they clearly are platform players in the mix we covered nvidia extensively in previous breaking analysis and won't go too deep there today but the data shows net scores on the vertical axis that's a measure of spending velocity and then it shows market share in the horizontal axis which is a measure of pervasiveness within the etr data set we're not going to dwell on the relative positions here rather let's comment on the players and start with aws we've laid out aws how they got here and we believe they are setting the direction for the future of the industry and aws is really pushing migration to its arm-based platforms pat morehead at the 6-5 summit spoke to dave brown who heads ec2 at aws and he talked extensively about migrating from x86 to aws's arm-based graviton 2. and he announced a new developer challenge to accelerate that migration to arm instances graviton instances and the end game for customers is a 40 better price performance so a customer running 100 server instances can do the same work with 60 servers now there's some work involved but for the by the customers to actually get there but the payoff if they can get 40 improvement in price performance is quite large imagine this aws currently offers 400 different ec2 instances last year as we reported sorry last year as we reported earlier this year nearly 50 percent of the new ec2 instances so nearly 50 percent of the new ec2 instances shipped in 2020 were arm based and aws is working hard to accelerate this pace it's very clear now let's talk about intel i'll just say it intel is finally responding in earnest and basically it's taking a page out of arm's playbook we're going to dig into that a bit today in 2015 intel paid 16.7 billion dollars for altera a maker of fpgas now also at the 6.5 summit nevin shenoy of intel presented details of what intel is calling an ipu it's infrastructure processing unit this is a departure from intel norms where everything is controlled by a central processing unit ipu's are essentially smart knicks as our dpus so don't get caught up in all the acronym soup as we've reported it's all about offloading work and disaggregating memory and evolving socs system-on-chip and sops system on package but just let this sink in a bit a bit for a moment intel's moves this past week it seems to us anyway are designed to create a platform that is nitro like and the basis of that platform is a 16.7 billion dollar acquisition just compare that to aws's 350 million dollar tuck-in of annapurna that is incredible now chenoy said in his presentation rough quote we've already deployed ipu's using fpgas in a in very high volume at microsoft azure and we've recently announced partnerships with baidu jd cloud and vmware so let's look at vmware vmware is the other you know really big platform player in this race in 2020 vmware announced project monterrey you might recall that it's based on the aforementioned fpgas from intel so vmware is in the mix and it chose to work with intel most likely for a variety of reasons one of the obvious ones is all the software that's running on on on vmware it's been built for x86 and there's a huge install base there the other is pat was heading vmware at the time and and you know when project monterey was conceived so i'll let you connect the dots if you like regardless vmware has a nitro like offering in our view its optionality however is limited by intel but at least it's in the game and appears to be ahead of the competition in this space aws notwithstanding because aws is clearly in the lead now what about microsoft and google suffice it to say that we strongly believe that despite the comments that intel made about shipping fpgas and volume to microsoft that both microsoft and google as well as alibaba will follow aws's lead and develop an arm-based platform like nitro we think they have to in order to keep pace with aws now what about the rest of the data center pack well dell has vmware so despite the split we don't expect any real changes there dell is going to leverage whatever vmware does and do it better than anyone else cisco is interesting in that it just revamped its ucs but we don't see any evidence that it has a nitro like plans in its roadmap same with hpe now both of these companies have history and capabilities around silicon cisco designs its own chips today for carrier class use cases and and hpe as we've reported probably has some remnants of the machine hanging around but both companies are very likely in our view to follow vmware's lead and go with an intel based design what about ibm well we really don't know we think the best thing ibm could do would be to move the ibm cloud of course to an arm-based nitro-like platform we think even the mainframe should move to arm as well i mean it's just too expensive to build a specialized mainframe cpu these days now oracle they're interesting if we were running oracle we would build an arm-based nitro-like database cloud where oracle the database runs cheaper faster and consumes less energy than any other platform that would would dare to run oracle and we'd go one step further and we would optimize for competitive databases in the oracle cloud so we would make oci run the table on all databases and be essentially the database cloud but you know back to sort of fpgas we're not overly excited about about the market amd is acquiring xi links for 35 billion dollars so i guess that's something to get excited about i guess but at least amd is using its inflated stock price to do the deal but we honestly we think that the arm ecosystem will will obliterate the fpga market by making it simpler and faster to move to soc with far better performance flexibility integration and mobility so again we're not too sanguine about intel's acquisition of altera and the moves that amd is making in in the long term now let's take a deeper look at intel's vision of the data center of the future here's a chart that intel showed depicting its vision of the future of the data center what you see is the ipu's which are intelligent nixed and they're embedded in the four blocks shown and they're communicating across a fabric now you have general purpose compute in the upper left and machine intelligent on the bottom left machine intelligence apps and up in the top right you see storage services and then the bottom right variation of alternative processors and this is intel's view of how to share resources and go from a world where everything is controlled by a central processing unit to a more independent set of resources that can work in parallel now gelsinger has talked about all the cool tech that this will allow intel to incorporate including pci and gen 5 and cxl memory interfaces and or cxl memory which are interfaces that enable memory sharing and disaggregation and 5g and 6g connectivity and so forth so that's intel's view of the future of the data center let's look at arm's vision of the future and compare them now there are definite similarities as you can see especially on the right hand side of this chart you've got the blocks of different process processor types these of course are programmable and you notice the high bandwidth memory the hbm3 plus the ddrs on the two sides kind of bookending the blocks that's shared across the entire system and it's connected by pcie gen 5 cxl or ccix multi-die socket so you know you may be looking to say okay two sets of block diagrams big deal well while there are similarities around disaggregation and i guess implied shared memory in the intel diagram and of course the use of advanced standards there are also some notable differences in particular arm is really already at the soc level whereas intel is talking about fpgas neoverse arms architecture is shipping in test mode and we'll have end market product by year end 2022 intel is talking about maybe 2024 we think that's aspirational or 2025 at best arm's road map is much more clear now intel said it will release more details in october so we'll pay attention then maybe we'll recalibrate at that point but it's clear to us that arm is way further along now the other major difference is volume intel is coming at this from a high data center perspective and you know presumably plans to push down market or out to the edge arm is coming at this from the edge low cost low power superior price performance arm is winning at the edge and based on the data that we shared earlier from aws it's clearly gaining ground in the enterprise history strongly suggests that the volume approach will win not only at the low end but eventually at the high end so we want to wrap by looking at what this means for customers and the partner ecosystem the first point we'd like to make is follow the consumer apps this capability the capabilities that we see in consumer apps like image processing and natural language processing and facial recognition and voice translation these inference capabilities that are going on today in mobile will find their way into the enterprise ecosystem ninety percent of the cost associated with machine learning in the cloud is around inference in the future most ai in the enterprise and most certainly at the edge will be inference it's not today because it's too expensive this is why aws is building custom chips for inferencing to drive costs down so it can increase adoption now the second point is we think that customers should start experimenting and see what you can do with arm-based platforms moore's law is accelerating at least the outcome of moore's law the doubling of performance every of the 18 to 24 months it's it's actually much higher than that now when you add up all the different components in these alternative processors just take a look at apple's a5 a15 chip and arm is in the lead in terms of performance price performance cost and energy consumption by moving some workloads onto graviton for example you'll see what types of cost savings you can drive for which applications and possibly generate new applications that you can deliver to your business put a couple engineers in the task and see what they can do in two or three weeks you might be surprised or you might say hey it's too early for us but you'll find out and you may strike gold we would suggest that you talk to your hybrid cloud provider as well and find out if they have a nitro we shared that vmware they've got a clear path as does dell because they're you know vmware cousins what about your other strategic suppliers what's their roadmap what's the time frame to move from where they are today to something that resembles nitro do they even think about that how do they think about that do they think it's important to get there so if if so or if not how are they thinking about reducing your costs and supporting your new workloads at scale now for isvs these consumer capabilities that we discussed earlier all these mobile and and automated systems and cars and and things like that biometrics another example they're going to find their way into your software and your competitors are porting to arm they're embedding these consumer-like capabilities into their apps are you we would strongly recommend that you take a look at that talk to your cloud suppliers and see what they can do to help you innovate run faster and cut costs okay that's it for now thanks to my collaborator david floyer who's been on this topic since early last decade thanks to the community for your comments and insights and hey thanks to patrick morehead and daniel newman for some timely interviews from your event nice job fellas remember i published each week on wikibon.com and siliconangle.com these episodes are all available as podcasts just search for breaking analysis podcasts you can always connect with me on twitter at d vallante or email me at david.velante at siliconangle.com i appreciate the comments on linkedin and clubhouse so follow us if you see us in a room jump in and let's riff on these topics and don't forget to check out etr.plus for all the survey data this is dave vellante for the cube insights powered by etr be well and we'll see you next time

>> Paige: Hello, everybody, and thank you for joining us today for the virtual Vertica BDC 2020. Today's breakout session is entitled, Vertica next generation architecture. I'm Paige Roberts, open social relationship Manager at Vertica, I'll be your host for this session. And joining me is Vertica Chief Architect, Chuck Bear, before we begin, I encourage you to submit questions or comments during the virtual session. You don't have to wait, just type your question or comment, in the question box that's below the slides and click submit. So as you think about it, go ahead and type it in, there'll be a Q&A session at the end of the presentation, where we'll answer as many questions, as we're able to during the time. Any questions that we don't get a chance to address, we'll do our best to answer offline. Or alternatively, you can visit the Vertica forums to post your questions there, after the session. Our engineering team is planning to join the forum and keep the conversation going, so you can, it's just sort of like the developers lounge would be in delight conference. It gives you a chance to talk to our engineering team. Also, as a reminder, you can maximize your screen by clicking the double arrow button in the lower right corner of the slide. And before you ask, yes, this virtual session is being recorded, and it will be available to view on demand this week, we'll send you a notification, as soon as it's ready. Okay, now, let's get started, over to you, Chuck. >> Chuck: Thanks for the introduction, Paige, Vertica vision is to help customers, get value from structured data. This vision is simple, it doesn't matter what vertical the customer is in. They're all analytics companies, it doesn't matter what the customers environment is, as data is generated everywhere. We also can't do this alone, we know that you need other tools and people to build a complete solution. You know our database is key to delivering on the vision because we need a database that scales. When you start a new database company, you aren't going to win against 30 year old products on features. But from day one, we had something else, an architecture built for analytics performance. This architecture was inspired by the C-store project, combining the best design ideas from academics and industry veterans like Dr. Mike Stonebreaker. Our storage is optimized for performance, we use many computers in parallel. After over 10 years of refinements against various customer workloads, much of the design held up and serendipitously, the fact that we don't store in place updates set Vertica up for success in the cloud as well. These days, there are other tools that embody some of these design ideas. But we have other strengths that are more important than the storage format, where the only good analytics database that runs both on premise and in the cloud, giving customers the option to migrate their workloads, in most convenient and economical environment, or a full data management solution, not just the query tool. Unlike some other choices, ours comes with integration with a sequel ecosystem and full professional support. We organize our product roadmap into four key pillars, plus the cross cutting concerns of open integration and performance and scale. We have big plans to strengthen Vertica, while staying true to our core. This presentation is primarily about the separation pillar, and performance and scale, I'll cover our plans for Eon, our data management architecture, Mart analytic clusters, or fifth generation query executer, and our data storage layer. Let's start with how Vertica manages data, one of the central design points for Vertica was shared nothing, a design that didn't utilize a dedicated hardware shared disk technology. This quote here is how Mike put it politely, but around the Vertica office, shared disk with an LMTB over Mike's dead body. And we did get some early field experience with shared disk, customers, well, in fact will learn on anything if you let them. There were misconfigurations that required certified experts, obscure bugs extent. Another thing about the shared nothing designed for commodity hardware though, and this was in the papers, is that all the data management features like fault tolerance, backup and elasticity have to be done in software. And no matter how much you do, procuring, configuring and maintaining the machines with disks is harder. The software configuration process to add more service may be simple, but capacity planning, racking and stacking is not. The original allure of shared storage returned, this time though, the complexity and economics are different. It's cheaper, even provision storage with a few clicks and only pay for what you need. It expands, contracts and brings the maintenance of the storage close to a team is good at it. But there's a key difference, it's an object store, an object stores don't support the API's and access patterns used by most database software. So another Vertica visionary Ben, set out to exploit Vertica storage organization, which turns out to be a natural fit for modern cloud shared storage. Because Vertica data files are written once and not updated, they match the object storage model perfectly. And so today we have Eon, Eon uses shared storage to hold Vertica data with local disk depot's that act as caches, ensuring that we can get the performance that our customers have come to expect. Essentially Eon in enterprise behave similarly, but we have the benefit of flexible storage. Today Eon has the features our customers expect, it's been developed in tune for years, we have successful customers such as Redpharma, and if you'd like to know more about Eon has helped them succeed in Amazon cloud, I highly suggest reading their case study, which you can find on vertica.com. Eon provides high availability and flexible scaling, sometimes on premise customers with local disks get a little jealous of how recovery and sub-clusters work in Eon. Though we operate on premise, particularly on pure storage, but enterprise also had strengths, the most obvious being that you don't need and short shared storage to run it. So naturally, our vision is to converge the two modes, back into a single Vertica. A Vertica that runs any combination of local disks and shared storage, with full flexibility and portability. This is easy to say, but over the next releases, here's what we'll do. First, we realize that the query executer, optimizer and client drivers and so on, are already the same. Just the transaction handling and data management is different. But there's already more going on, we have peer-to-peer depot operations and other internode transfers. And enterprise also has a network, we could just get files from remote nodes over that network, essentially mimicking the behavior and benefits of shared storage with the layer of software. The only difference at the end of it, will be which storage hold the master copy. In enterprise, the nodes can't drop the files because they're the master copy. Whereas in Eon they can be evicted because it's just the cache, the masters, then shared storage. And in keeping with versus current support for multiple storage locations, we can intermix these approaches at the table level. Getting there as a journey, and we've already taken the first steps. One of the interesting design ideas of the C-store paper is the idea that redundant copies, don't have to have the same physical organization. Different copies can be optimized for different queries, sorted in different ways. Of course, Mike also said to keep the recovery system simple, because it's hard to debug, whenever the recovery system is being used, it's always in a high pressure situation. This turns out to be a contradiction, and the latter idea was better. No down performing stuff, if you don't keep the storage the same. Recovery hardware if you have, to reorganize data in the process. Even query optimization is more complicated. So over the past couple releases, we got rid of non identical buddies. But the storage files can still diverge at the fifth level, because tuple mover operations are synchronized. The same record can end up in different files than different nodes. The next step in our journey, is to make sure both copies are identical. This will help with backup and restore as well, because the second copy doesn't need backed up, or if it is backed up, it appears identical to the deduplication that is going to look present in both backup systems. Simultaneously, we're improving the Vertica networking service to support this new access pattern. In conjunction with identical storage files, we will converge to a recovery system that instantaneous nodes can process queries immediately, by retrieving data they need over the network from the redundant copies as they do in Eon day with even higher performance. The final step then is to unify the catalog and transaction model. Related concepts such as segment and shard, local catalog and shard catalog will be coalesced, as they're really represented the same concepts all along, just in different modes. In the catalog, we'll make slight changes to the definition of a projection, which represents the physical storage organization. The new definition simplifies segmentation and introduces valuable granularities of sharding to support evolution over time, and offers a straightforward migration path for both Eon and enterprise. There's a lot more to our Eon story than just the architectural roadmap. If you missed yesterday's Vertica, in Eon mode presentation about supported cloud, on premise storage option, replays are available. Be sure to catch the upcoming presentation on sizing and configuring vertica and in beyond doors. As we've seen with Eon, Vertica can separate data storage from the compute nodes, allowing machines to quickly fill in for each other, to rebuild fault tolerance. But separating compute and storage is used for much, much more. We now offer powerful, flexible ways for Vertica to add servers and increase access to the data. Vertica nine, this feature is called sub-clusters. It allows computing capacity to be added quickly and incrementally, and isolates workloads from each other. If your exploratory analytics team needs direct access to the source data, they need a lot of machines and not the same number all the time, and you don't 100% trust the kind of queries and user defined functions, they might be using sub-clusters as the solution. While there's much more expensive information available in our other presentation. I'd like to point out the highlights of our latest sub-cluster best practices. We suggest having a primary sub-cluster, this is the one that runs all the time, if you're loading data around the clock. It should be sized for the ETL workloads and also determines the natural shard count. Additional read oriented secondary sub-clusters can be added for real time dashboards, reports and analytics. That way, subclusters can be added or deep provisioned, without disruption to other users. The sub-cluster features of Vertica 9.3 are working well for customers. Yesterday, the Trade Desk presented their use case for Vertica over 300,000 in 5 sub clusters running in the cloud. If you missed a presentation, check out the replay. But we have plans beyond sub-clusters, we're extending sub-clusters to real clusters. For the Vertica savvy, this means the clusters bump, share the same spread ring network. This will provide further isolation, allowing clusters to control their own independent data sets. While replicating all are part of the data from other clusters using a publish subscribe mechanism. Synchronizing data between clusters is a feature customers want to understand the real business for themselves. This vision effects are designed for ancillary aspects, how we should assign resource pools, security policies and balance client connection. We will be simplifying our data segmentation strategy, so that when data that originate in the different clusters meet, they'll still get fully optimized joins, even if those clusters weren't positioned with the same number of nodes per shard. Having a broad vision for data management is a key component to political success. But we also take pride in our execution strategy, when you start a new database from scratch as we did 15 years ago, you won't compete on features. Our key competitive points where speed and scale of analytics, we set a target of 100 x better query performance in traditional databases with path loads. Our storage architecture provides a solid foundation on which to build toward these goals. Every query starts with data retrieval, keeping data sorted, organized by column and compressed by using adaptive caching, to keep the data retrieval time in IO to the bare minimum theoretically required. We also keep the data close to where it will be processed, and you clusters the machines to increase throughput. We have partition pruning a robust optimizer evaluate active use segmentation as part of the physical database designed to keep records close to the other relevant records. So the solid foundation, but we also need optimal execution strategies and tactics. One execution strategy which we built for a long time, but it's still a source of pride, it's how we process expressions. Databases and other systems with general purpose expression evaluators, write a compound expression into a tree. Here I'm using A plus one times B as an example, during execution, if your CPU traverses the tree and compute sub-parts from the whole. Tree traversal often takes more compute cycles than the actual work to be done. Especially in evaluation is a very common operation, so something worth optimizing. One instinct that engineers have is to use what we call, just-in-time or JIT compilation, which means generating code form the CPU into the specific activity expression, and add them. This replaces the tree of boxes that are custom made box for the query. This approach has complexity bugs, but it can be made to work. It has other drawbacks though, it adds a lot to query setup time, especially for short queries. And it pretty much eliminate the ability of mere models, mere mortals to develop user defined functions. If you go back to the problem we're trying to solve, the source of the overhead is the tree traversal. If you increase the batch of records processed in each traversal step, this overhead is amortized until it becomes negligible. It's a perfect match for a columnar storage engine. This also sets the CPU up for efficiency. The CPUs look particularly good, at following the same small sequence of instructions in a tight loop. In some cases, the CPU may even be able to vectorize, and apply the same processing to multiple records to the same instruction. This approach is easy to implement and debug, user defined functions are possible, then generally aligned with the other complexities of implementing and improving a large system. More importantly, the performance, both in terms of query setup and record throughput is dramatically improved. You'll hear me say that we look at research and industry for inspiration. In this case, our findings in line with academic binding. If you'd like to read papers, I recommend everything you always wanted to know about compiled and vectorized queries, don't afraid to ask, so we did have this idea before we read that paper. However, not every decision we made in the Vertica executer that the test of time as well as the expression evaluator. For example, sorting and grouping aren't susceptible to vectorization because sort decisions interrupt the flow. We have used JIT compiling on that for years, and Vertica 401, and it provides modest setups, but we know we can do even better. But who we've embarked on a new design for execution engine, which I call EE five, because it's our best. It's really designed especially for the cloud, now I know what you're thinking, you're thinking, I just put up a slide with an old engine, a new engine, and a sleek play headed up into the clouds. But this isn't just marketing hype, here's what I mean, when I say we've learned lessons over the years, and then we're redesigning the executer for the cloud. And of course, you'll see that the new design works well on premises as well. These changes are just more important for the cloud. Starting with the network layer in the cloud, we can't count on all nodes being connected to the same switch. Multicast doesn't work like it does in a custom data center, so as I mentioned earlier, we're redesigning the network transfer layer for the cloud. Storage in the cloud is different, and I'm not referring here to the storage of persistent data, but to the storage of temporary data used only once during the course of query execution. Our new pattern is designed to take into account the strengths and weaknesses of cloud object storage, where we can't easily do a path. Moving on to memory, many of our access patterns are reasonably effective on bare metal machines, that aren't the best choice on cloud hyperbug that have overheads, page faults or big gap. Here again, we found we can improve performance, a bit on dedicated hardware, and even more in the cloud. Finally, and this is true in all environments, core counts have gone up. And not all of our algorithms take full advantage, there's a lot of ground to cover here. But I think sorting in the perfect example to illustrate these points, I mentioned that we use JIT in sorting. We're getting rid of JIT in favor of a data format that can be treated efficiently, independent of what the data types are. We've drawn on the best, most modern technology from academia and industry. We've got our own analysis and testing, you know what we chose, we chose parallel merge sort, anyone wants to take a guess when merge sort was invented. It was invented in 1948, or at least documented that way, like computing context. If you've heard me talk before, you know that I'm fascinated by how all the things I worked with as an engineer, were invented before I was born. And in Vertica , we don't use the newest technologies, we use the best ones. And what is noble about Vertica is the way we've combined the best ideas together into a cohesive package. So all kidding about the 1940s aside, or he redesigned is actually state of the art. How do we know the sort routine is state of the art? It turns out, there's a pretty credible benchmark or at the appropriately named historic sortbenchmark.org. Anyone with resources looking for fame for their product or academic paper can try to set the record. Record is last set in 2016 with Tencent Sort, 100 terabytes in 99 seconds. Setting the records it's hard, you have to come up with hundreds of machines on a dedicated high speed switching fabric. There's a lot to a distributed sort, there all have core sorting algorithms. The authors of the paper conveniently broke out of the time spent in their sort, 67 out of 99 seconds want to know local sorting. If we break this out, divided by two CPUs and each of 512 nodes, we find that each CPU so there's almost a gig and a half per second. This is for what's called an indy sort, like an Indy race car, is in general purpose. It only handles fixed hundred five records with 10 byte key. There is a record length can vary, then it's called daytona sort, a 10 set daytona sort, is a little slower. One point is 10 gigabytes per second per CPU, now for Verrtica, We have a wide variety ability in record sizes, and more interesting data types, but still no harm in setting us like phone numbers, comfortable to the world record. On my 2017 era AMD desktop CPU, the Vertica EE5 sort to store about two and a half gigabytes per second. Obviously, this test isn't apply to apples because they use their own open power chip. But the number of DRM channels is the same, so it's pretty close the number that says we've hit on the right approach. And it performs this way on premise, in the cloud, and we can adapt it to cloud temp space. So what's our roadmap for integrating EE5 into the product and compare replacing the query executed the database to replacing the crankshaft and other parts of the engine of a car while it's been driven. We've actually done it before, between Vertica three and a half and five, and then we never really stopped changing it, now we'll do it again. The first part in replacing with algorithm called storage merge, which combines sorted data from disk. The first time has was two that are in vertical in incoming 10.0 patch that will be EE5 or resegmented storage merge, and then convert sorting and grouping into do out. There the performance results so far, in cases where the Vertica execute is doing well today, simple environments with simple data patterns, such as this simple capitalistic query, there's a lot of speed up, when we ship the segmentation code, which didn't quite make the freeze as much like to bump longer term, what we do is grouping into the storage of large operations, we'll get to where we think we ought to be, given a theoretical minimum work the CPUs need to do. Now if we look at a case where the current execution isn't doing as well, we see there's a much stronger benefit to the code shipping in Vertica 10. In fact, it turns a chart bar sideways to try to help you see the difference better. This case also benefit from the improvements in 10 product point releases and beyond. They will not happening to the vertical query executer, That was just the taste. But now I'd like to switch to the roadmap first for our adapters layer. I'll start with a story about, how our storage access layer evolved. If you go back to the academic ideas, if you start paper that persuaded investors to fund Vertica, read optimized store was the part that had substantiation in the form of performance data. Much of the paper was speculative, but we tried to follow it anyway. That paper talked about the WS with RS, The rights are in the read store, and how they work together for transaction processing and how there was a supernova. In all honesty, Vertica engineers couldn't figure out from the paper what to do next, incase you want to try, and we asked them they would like, We never got enough clarification to build it that way. But here's what we built, instead. We built the ROS, read optimized store, introduction on steep major revision. It's sorted, ordered columnar and compressed that follows a table partitioning that worked even better than the we are as described in the paper. We also built the last byte optimized store, we built four versions of this over the years actually. But this was the best one, it's not a set of interrelated V tree. It's just an append only, insertion order remember your way here, am sorry, no compression, no base, no partitioning. There is, however, a tuple over which does what we call move out. Move the data from WOS to ROS, sorting and compressing. Let's take a moment to compare how they behave, when you load data directly to the ROS, there's a data parsing operation. Then we finished the sorting, and then compressing right out the columnar data files to stay storage. The next query through executes against the ROS and it runs as it should because the ROS is read optimized. Let's repeat the exercise for WOS, the load operation response before the sorting and compressing, and before the data is written to persistent storage. Now it's possible for a query to come along, and the query could be responsible for sorting the lost data in addition to its other processes. Effect on query isn't predictable until the TM comes along and writes the data to the ROS. Over the years, we've done a lot of comparisons between ROS and WOS. ROS has always been better for sustained load throughput, it achieves much higher records per second without pushing back against the client and hasn't Vertica for when we developed the first usable merge out algorithm. ROS has always been better for predictable query performance, the ROS has never had the same management complexity and limitations as WOS. You don't have to pick a memory size and figure out which transactions get to use the pool. A non persistent nature of ROS always cause headaches when there are unexpected cluster shutdowns. We also looked at field usage data, we found that few customers were using a lot, especially among those that studied the issue carefully. So how we set out on a mission to improve the ROS to the point where it was always better than both the WOS and the profit of the past. And now it's true, ROS is better than the WOS and the loss of a couple of years ago. We implemented storage bundling, better catalog object storage and better tuple mover merge outs. And now, after extensive Q&A and customer testing, we've now succeeded, and in Vertica 10, we've removed the whys. Let's talk for a moment about simplicity, one of the best things Mike Stonebreaker said is no knobs. Anyone want to guess how many knobs we got rid of, and we took the WOS out of the product. 22 were five knobs to control whether it didn't went to ROS as well. Six controlling the ROS itself, Six more to set policies for the typical remove out and so on. In my honest opinion is still wasn't enough control over to achieve excess in a multi tenant environment, the big reason to get rid of the WOS for simplicity. Make the lives of DBAs and users better, we have a long way to go, but we're doing it. On my desk, I keep a jar with the knob in it for each knob in Vertica. When developers add a knob to the product, they have to add a knob to the jar. When they remove a knob, they get to choose one to take out, We have a lot of work to do, but I'm thrilled to report that in 15 years 10 is the first release with a number of knobs ticked downward. Get back to the WOS, I've said the most important thing get rid of it for last. We're getting rid of it so we can deliver our vision of the future to our customer. Remember how he said an Eon and sub-clusters we got all these benefits from shared storage? Guess what can't live in shared storage, the WOS. Remember how it's been a big part of the future was keeping the copies that identical to the primary copy? Independent actions of the WOS took a little at the root of the divergence between copies of the data. You have to admit it when you're wrong. That was in the original design and held up to the a selling point of time, without onto the idea of a separate ROS and WOS for too long. In Vertica, 10, we can finally bid, good reagents. I've covered a lot of ground, so let's put all the pieces together. I've talked a lot about our vision and how we're achieving it. But we also still pay attention to tactical detail. We've been fine tuning our memory management model to enhance performance. That involves revisiting tens of thousands of satellite of code, much like painting the inside of a large building with small paintbrushes. We're getting results as shown in the chart in Vertica nine, concurrent monitoring queries use memory from the global catalog tool, and Vertica 10, they don't. This is only one example of an important detail we're improving. We've also reworked the monitoring tables without network messages into two parts. The increased data we're collecting and analyzing and our quality assurance processes, we're improving on everything. As the story goes, I still have my grandfather's axe, of course, my father had to replace the handle, and I had to replace the head. Along the same lines, we still have Mike Stonebreaker Vertica. We didn't replace the query optimizer twice the debate database designer and storage layer four times each. The query executed is and it's a free design, like charted out how our code has changed over the years. I found that we don't have much from a long time ago, I did some digging, and you know what we have left in 2007. We have the original curly braces, and a little bit of percent code for handling dates and times. To deliver on our mission to help customers get value from their structured data, with high performance of scale, and in diverse deployment environments. We have the sound architecture roadmap, reviews the best execution strategy and solid tactics. On the architectural front, we're converging in an enterprise, we're extending smart analytic clusters. In query processing, we're redesigning the execution engine for the cloud, as I've told you. There's a lot more than just the fast engine. that you want to learn about our new data support for complex data types, improvements to the query optimizer statistics, or extension to live aggregate projections and flatten tables. You should check out some of the other engineering talk that the big data conference. We continue to stay on top of the details from low level CPU and memory too, to the monitoring management, developing tighter feedback cycles between development, Q&A and customers. And don't forget to check out the rest of the pillars of our roadmap. We have new easier ways to get started with Vertica in the cloud. Engineers have been hard at work on machine learning and security. It's easier than ever to use Vertica with third Party product, as a variety of tools integrations continues to increase. Finally, the most important thing we can do, is to help people get value from structured data to help people learn more about Vertica. So hopefully I left plenty of time for Q&A at the end of this presentation. I hope to hear your questions soon.

>> Paige: Hello, everybody and thank you for joining us today on the Virtual Vertica BDC 2020. Today's breakout session is entitled A Technical Overview of the Vertica Architecture. I'm Paige Roberts, Open Source Relations Manager at Vertica and I'll be your host for this webinar. Now joining me is Ryan Role-kuh? Did I say that right? (laughs) He's a Vertica Senior Software Engineer. >> Ryan: So it's Roelke. (laughs) >> Paige: Roelke, okay, I got it, all right. Ryan Roelke. And before we begin, I want to be sure and encourage you guys to submit your questions or your comments during the virtual session while Ryan is talking as you think of them as you go along. You don't have to wait to the end, just type in your question or your comment in the question box below the slides and click submit. There'll be a Q and A at the end of the presentation and we'll answer as many questions as we're able to during that time. Any questions that we don't address, we'll do our best to get back to you offline. Now, alternatively, you can visit the Vertica forums to post your question there after the session as well. Our engineering team is planning to join the forums to keep the conversation going, so you can have a chat afterwards with the engineer, just like any other conference. Now also, you can maximize your screen by clicking the double arrow button in the lower right corner of the slides and before you ask, yes, this virtual session is being recorded and it will be available to view on demand this week. We'll send you a notification as soon as it's ready. Now, let's get started. Over to you, Ryan. >> Ryan: Thanks, Paige. Good afternoon, everybody. My name is Ryan and I'm a Senior Software Engineer on Vertica's Development Team. I primarily work on improving Vertica's query execution engine, so usually in the space of making things faster. Today, I'm here to talk about something that's more general than that, so we're going to go through a technical overview of the Vertica architecture. So the intent of this talk, essentially, is to just explain some of the basic aspects of how Vertica works and what makes it such a great database software and to explain what makes a query execute so fast in Vertica, we'll provide some background to explain why other databases don't keep up. And we'll use that as a starting point to discuss an academic database that paved the way for Vertica. And then we'll explain how Vertica design builds upon that academic database to be the great software that it is today. I want to start by sharing somebody's approximation of an internet minute at some point in 2019. All of the data on this slide is generated by thousands or even millions of users and that's a huge amount of activity. Most of the applications depicted here are backed by one or more databases. Most of this activity will eventually result in changes to those databases. For the most part, we can categorize the way these databases are used into one of two paradigms. First up, we have online transaction processing or OLTP. OLTP workloads usually operate on single entries in a database, so an update to a retail inventory or a change in a bank account balance are both great examples of OLTP operations. Updates to these data sets must be visible immediately and there could be many transactions occurring concurrently from many different users. OLTP queries are usually key value queries. The key uniquely identifies the single entry in a database for reading or writing. Early databases and applications were probably designed for OLTP workloads. This example on the slide is typical of an OLTP workload. We have a table, accounts, such as for a bank, which tracks information for each of the bank's clients. An update query, like the one depicted here, might be run whenever a user deposits $10 into their bank account. Our second category is online analytical processing or OLAP which is more about using your data for decision making. If you have a hardware device which periodically records how it's doing, you could analyze trends of all your devices over time to observe what data patterns are likely to lead to failure or if you're Google, you might log user search activity to identify which links helped your users find the answer. Analytical processing has always been around but with the advent of the internet, it happened at scales that were unimaginable, even just 20 years ago. This SQL example is something you might see in an OLAP workload. We have a table, searches, logging user activity. We will eventually see one row in this table for each query submitted by users. If we want to find out what time of day our users are most active, then we could write a query like this one on the slide which counts the number of unique users running searches for each hour of the day. So now let's rewind to 2005. We don't have a picture of an internet minute in 2005, we don't have the data for that. We also don't have the data for a lot of other things. The term Big Data is not quite yet on anyone's radar and The Cloud is also not quite there or it's just starting to be. So if you have a database serving your application, it's probably optimized for OLTP workloads. OLAP workloads just aren't mainstream yet and database engineers probably don't have them in mind. So let's innovate. It's still 2005 and we want to try something new with our database. Let's take a look at what happens when we do run an analytic workload in 2005. Let's use as a motivating example a table of stock prices over time. In our table, the symbol column identifies the stock that was traded, the price column identifies the new price and the timestamp column indicates when the price changed. We have several other columns which, we should know that they're there, but we're not going to use them in any example queries. This table is designed for analytic queries. We're probably not going to make any updates or look at individual rows since we're logging historical data and want to analyze changes in stock price over time. Our database system is built to serve OLTP use cases, so it's probably going to store the table on disk in a single file like this one. Notice that each row contains all of the columns of our data in row major order. There's probably an index somewhere in the memory of the system which will help us to point lookups. Maybe our system expects that we will use the stock symbol and the trade time as lookup keys. So an index will provide quick lookups for those columns to the position of the whole row in the file. If we did have an update to a single row, then this representation would work great. We would seek to the row that we're interested in, finding it would probably be very fast using the in-memory index. And then we would update the file in place with our new value. On the other hand, if we ran an analytic query like we want to, the data access pattern is very different. The index is not helpful because we're looking up a whole range of rows, not just a single row. As a result, the only way to find the rows that we actually need for this query is to scan the entire file. We're going to end up scanning a lot of data that we don't need and that won't just be the rows that we don't need, there's many other columns in this table. Many information about who made the transaction, and we'll also be scanning through those columns for every single row in this table. That could be a very serious problem once we consider the scale of this file. Stocks change a lot, we probably have thousands or millions or maybe even billions of rows that are going to be stored in this file and we're going to scan all of these extra columns for every single row. If we tried out our stocks use case behind the desk for the Fortune 500 company, then we're probably going to be pretty disappointed. Our queries will eventually finish, but it might take so long that we don't even care about the answer anymore by the time that they do. Our database is not built for the task we want to use it for. Around the same time, a team of researchers in the North East have become aware of this problem and they decided to dedicate their time and research to it. These researchers weren't just anybody. The fruits of their labor, which we now like to call the C-Store Paper, was published by eventual Turing Award winner, Mike Stonebraker, along with several other researchers from elite universities. This paper presents the design of a read-optimized relational DBMS that contrasts sharply with most current systems, which are write-optimized. That sounds exactly like what we want for our stocks use case. Reasoning about what makes our queries executions so slow brought our researchers to the Memory Hierarchy, which essentially is a visualization of the relative speeds of different parts of a computer. At the top of the hierarchy, we have the fastest data units, which are, of course, also the most expensive to produce. As we move down the hierarchy, components get slower but also much cheaper and thus you can have more of them. Our OLTP databases data is stored in a file on the hard disk. We scanned the entirety of this file, even though we didn't need most of the data and now it turns out, that is just about the slowest thing that our query could possibly be doing by over two orders of magnitude. It should be clear, based on that, that the best thing we can do to optimize our query's execution is to avoid reading unnecessary data from the disk and that's what the C-Store researchers decided to look at. The key innovation of the C-Store paper does exactly that. Instead of storing data in a row major order, in a large file on disk, they transposed the data and stored each column in its own file. Now, if we run the same select query, we read only the relevant columns. The unnamed columns don't factor into the table scan at all since we don't even open the files. Zooming out to an internet scale sized data set, we can appreciate the savings here a lot more. But we still have to read a lot of data that we don't need to answer this particular query. Remember, we had two predicates, one on the symbol column and one on the timestamp column. Our query is only interested in AAPL stock, but we're still reading rows for all of the other stocks. So what can we do to optimize our disk read even more? Let's first partition our data set into different files based on the timestamp date. This means that we will keep separate files for each date. When we query the stocks table, the database knows all of the files we have to open. If we have a simple predicate on the timestamp column, as our sample query does, then the database can use it to figure out which files we don't have to look at at all. So now all of our disk reads that we have to do to answer our query will produce rows that pass the timestamp predicate. This eliminates a lot of wasteful disk reads. But not all of them. We do have another predicate on the symbol column where symbol equals AAPL. We'd like to avoid disk reads of rows that don't satisfy that predicate either. And we can avoid those disk reads by clustering all the rows that match the symbol predicate together. If all of the AAPL rows are adjacent, then as soon as we see something different, we can stop reading the file. We won't see any more rows that can pass the predicate. Then we can use the positions of the rows we did find to identify which pieces of the other columns we need to read. One technique that we can use to cluster the rows is sorting. So we'll use the symbol column as a sort key for all of the columns. And that way we can reconstruct a whole row by seeking to the same row position in each file. It turns out, having sorted all of the rows, we can do a bit more. We don't have any more wasted disk reads but we can still be more efficient with how we're using the disk. We've clustered all of the rows with the same symbol together so we don't really need to bother repeating the symbol so many times in the same file. Let's just write the value once and say how many rows we have. This one length encoding technique can compress large numbers of rows into a small amount of space. In this example, we do de-duplicate just a few rows but you can imagine de-duplicating many thousands of rows instead. This encoding is great for reducing the amounts of disk we need to read at query time, but it also has the additional benefit of reducing the total size of our stored data. Now our query requires substantially fewer disk reads than it did when we started. Let's recap what the C-Store paper did to achieve that. First, we transposed our data to store each column in its own file. Now, queries only have to read the columns used in the query. Second, we partitioned the data into multiple file sets so that all rows in a file have the same value for the partition column. Now, a predicate on the partition column can skip non-matching file sets entirely. Third, we selected a column of our data to use as a sort key. Now rows with the same value for that column are clustered together, which allows our query to stop reading data once it finds non-matching rows. Finally, sorting the data this way enables high compression ratios, using one length encoding which minimizes the size of the data stored on the disk. The C-Store system combined each of these innovative ideas to produce an academically significant result. And if you used it behind the desk of a Fortune 500 company in 2005, you probably would've been pretty pleased. But it's not 2005 anymore and the requirements of a modern database system are much stricter. So let's take a look at how C-Store fairs in 2020. First of all, we have designed the storage layer of our database to optimize a single query in a single application. Our design optimizes the heck out of that query and probably some similar ones but if we want to do anything else with our data, we might be in a bit of trouble. What if we just decide we want to ask a different question? For example, in our stock example, what if we want to plot all the trade made by a single user over a large window of time? How do our optimizations for the previous query measure up here? Well, our data's partitioned on the trade date, that could still be useful, depending on our new query. If we want to look at a trader's activity over a long period of time, we would have to open a lot of files. But if we're still interested in just a day's worth of data, then this optimization is still an optimization. Within each file, our data is ordered on the stock symbol. That's probably not too useful anymore, the rows for a single trader aren't going to be clustered together so we will have to scan all of the rows in order to figure out which ones match. You could imagine a worse design but as it becomes crucial to optimize this new type of query, then we might have to go as far as reconfiguring the whole database. The next problem of one of scale. One server is probably not good enough to serve a database in 2020. C-Store, as described, runs on a single server and stores lots of files. What if the data overwhelms this small system? We could imagine exhausting the file system's inodes limit with lots of small files due to our partitioning scheme. Or we could imagine something simpler, just filling up the disk with huge volumes of data. But there's an even simpler problem than that. What if something goes wrong and C-Store crashes? Then our data is no longer available to us until the single server is brought back up. A third concern, another one of scalability, is that one deployment does not really suit all possible things and use cases we could imagine. We haven't really said anything about being flexible. A contemporary database system has to integrate with many other applications, which might themselves have pretty restricted deployment options. Or the demands imposed by our workloads have changed and the setup you had before doesn't suit what you need now. C-Store doesn't do anything to address these concerns. What the C-Store paper did do was lead very quickly to the founding of Vertica. Vertica's architecture and design are essentially all about bringing the C-Store designs into an enterprise software system. The C-Store paper was just an academic exercise so it didn't really need to address any of the hard problems that we just talked about. But Vertica, the first commercial database built upon the ideas of the C-Store paper would definitely have to. This brings us back to the present to look at how an analytic query runs in 2020 on the Vertica Analytic Database. Vertica takes the key idea from the paper, can we significantly improve query performance by changing the way our data is stored and give its users the tools to customize their storage layer in order to heavily optimize really important or commonly wrong queries. On top of that, Vertica is a distributed system which allows it to scale up to internet-sized data sets, as well as have better reliability and uptime. We'll now take a brief look at what Vertica does to address the three inadequacies of the C-Store system that we mentioned. To avoid locking into a single database design, Vertica provides tools for the database user to customize the way their data is stored. To address the shortcomings of a single node system, Vertica coordinates processing among multiple nodes. To acknowledge the large variety of desirable deployments, Vertica does not require any specialized hardware and has many features which smoothly integrate it with a Cloud computing environment. First, we'll look at the database design problem. We're a SQL database, so our users are writing SQL and describing their data in SQL way, the Create Table statement. Create Table is a logical description of what your data looks like but it doesn't specify the way that it has to be stored, For a single Create Table, we could imagine a lot of different storage layouts. Vertica adds some extensions to SQL so that users can go even further than Create Table and describe the way that they want the data to be stored. Using terminology from the C-Store paper, we provide the Create Projection statement. Create Projection specifies how table data should be laid out, including column encoding and sort order. A table can have multiple projections, each of which could be ordered on different columns. When you query a table, Vertica will answer the query using the projection which it determines to be the best match. Referring back to our stock example, here's a sample Create Table and Create Projection statement. Let's focus on our heavily optimized example query, which had predicates on the stock symbol and date. We specify that the table data is to be partitioned by date. The Create Projection Statement here is excellent for this query. We specify using the order by clause that the data should be ordered according to our predicates. We'll use the timestamp as a secondary sort key. Each projection stores a copy of the table data. If you don't expect to need a particular column in a projection, then you can leave it out. Our average price query didn't care about who did the trading, so maybe our projection design for this query can leave the trader column out entirely. If the question we want to ask ever does change, maybe we already have a suitable projection, but if we don't, then we can create another one. This example shows another projection which would be much better at identifying trends of traders, rather than identifying trends for a particular stock. Next, let's take a look at our second problem, that one, or excuse me, so how should you decide what design is best for your queries? Well, you could spend a lot of time figuring it out on your own, or you could use Vertica's Database Designer tool which will help you by automatically analyzing your queries and spitting out a design which it thinks is going to work really well. If you want to learn more about the Database Designer Tool, then you should attend the session Vertica Database Designer- Today and Tomorrow which will tell you a lot about what the Database Designer does and some recent improvements that we have made. Okay, now we'll move to our next problem. (laughs) The challenge that one server does not fit all. In 2020, we have several orders of magnitude more data than we had in 2005. And you need a lot more hardware to crunch it. It's not tractable to keep multiple petabytes of data in a system with a single server. So Vertica doesn't try. Vertica is a distributed system so will deploy multiple severs which work together to maintain such a high data volume. In a traditional Vertica deployment, each node keeps some of the data in its own locally-attached storage. Data is replicated so that there is a redundant copy somewhere else in the system. If any one node goes down, then the data that it served is still available on a different node. We'll also have it so that in the system, there's no special node with extra duties. All nodes are created equal. This ensures that there is no single point of failure. Rather than replicate all of your data, Vertica divvies it up amongst all of the nodes in your system. We call this segmentation. The way data is segmented is another parameter of storage customization and it can definitely have an impact upon query performance. A common way to segment data is by using a hash expression, which essentially randomizes the node that a row of data belongs to. But with a guarantee that the same data will always end up in the same place. Describing the way data is segmented is another part of the Create Projection Statement, as seen in this example. Here we segment on the hash of the symbol column so all rows with the same symbol will end up on the same node. For each row that we load into the system, we'll apply our segmentation expression. The result determines which segment the row belongs to and then we'll send the row to each node which holds the copy of that segment. In this example, our projection is marked KSAFE 1, so we will keep one redundant copy of each segment. When we load a row, we might find that its segment had copied on Node One and Node Three, so we'll send a copy of the row to each of those nodes. If Node One is temporarily disconnected from the network, then Node Three can serve the other copy of the segment so that the whole system remains available. The last challenge we brought up from the C-Store design was that one deployment does not fit all. Vertica's cluster design neatly addressed many of our concerns here. Our use of segmentation to distribute data means that a Vertica system can scale to any size of deployment. And since we lack any special hardware or nodes with special purposes, Vertica servers can run anywhere, on premise or in the Cloud. But let's suppose you need to scale out your cluster to rise to the demands of a higher workload. Suppose you want to add another node. This changes the division of the segmentation space. We'll have to re-segment every row in the database to find its new home and then we'll have to move around any data that belongs to a different segment. This is a very expensive operation, not something you want to be doing all that often. Traditional Vertica doesn't solve that problem especially well, but Vertica Eon Mode definitely does. Vertica's Eon Mode is a large set of features which are designed with a Cloud computing environment in mind. One feature of this design is elastic throughput scaling, which is the idea that you can smoothly change your cluster size without having to pay the expenses of shuffling your entire database. Vertica Eon Mode had an entire session dedicated to it this morning. I won't say any more about it here, but maybe you already attended that session or if you haven't, then I definitely encourage you to listen to the recording. If you'd like to learn more about the Vertica architecture, then you'll find on this slide links to several of the academic conference publications. These four papers here, as well as Vertica Seven Years Later paper which describes some of the Vertica designs seven years after the founding and also a paper about the innovations of Eon Mode and of course, the Vertica documentation is an excellent resource for learning more about what's going on in a Vertica system. I hope you enjoyed learning about the Vertica architecture. I would be very happy to take all of your questions now. Thank you for attending this session.

hello my name is Brian Grace Lee analysts with wiki Bond and on today's wiki bond whiteboards we're gonna begin to understand container architectures containers are really the big technology talked about these days especially for infrastructure teams there's a component of it that's both application and infrastructure but in this whiteboard we're really going to understand the basics of how it applies to the infrastructure and we're going to try and put it in the context of things that most infrastructure teams understand today which is virtualization so let's go ahead and begin what we've done and again this is for context we've tried to take a standard environment that people are used to seeing for virtualization and in this case we're going to use VMware as the example because obviously broadest market share and a lot of people understand what they do so let's talk about the basics of what happens here people understand what happens at the host level I've got servers within each server I've got a hypervisor so in VMware's case ESX or ESXi within that hypervisor I'm going to go ahead and create virtual machines so every single virtual machine has a copy of the full operating system and then within that virtual machine I've got a an operating an application itself for multiple applications so everybody understands that pretty well now how I manage those hype with those hypervisors and virtual machines is through a centralized control plane and that's called V Center and V Center may be a single instance it may be a clustered instance but think of it as the thing that's going to manage the scheduling of the resources and the management of those resources and it's really only focused on virtual machines okay now above that we're going to have if we're deploying applications I can either deploy them by hand or I may begin to deploy them through application templates so I may deploy the same type of application over and over again a web server a sequel database something else do that consistently I'm going to use some sort of typically a templating function and a lot of that can come in the management flame framework from something like V realize VMware via realized and then on top of that I'm going to have my applications whatever those might be sequel databases s AP Oracle Microsoft applications whatever those things might be so the key things I want you to understand is at the host level its hypervisor virtual machine full operating system and application and at the control plane it's this sort of structured format of V Center cluster V Center is going to make sure that virtual machines get deployed on to those hosts and it's going to keep track of where they are and make sure that they stay alive using things like VMware H a VM or V motion and VMware fault tolerance okay so now that we have that basic context in place let's take a look at how the container ecosystem is beginning to evolve and in this example we're gonna use docker because similar to VMware right now docker is the most frequently used container technology there are other ones in the marketplace but we're going to use docker just as an example the rest of what we talked about will be applicable whether it's docker core OS rocket or a number of the other container technologies that are out there so let's begin down at the host level just like we did over here in the simplest form I'm gonna have a host I'm gonna have a server we're not going to have a hypervisor we're just going to have the operating system today in most container environments that operating system is going to be Linux now there's a lot going on in the marketplace where this will eventually be Linux and Windows Microsoft is is working quite a bit on this but for right now let's just say that operating system is Linux ok I'm going to have my container runtime which in this case is his docker and you can think about that as sort of being like a hypervisor but it's almost a lightweight hypervisor and then that container runtime is going to create my containers themselves and each one of those containers now what's unique about this that's different from this environment is each one of those containers only uses they all share the same operating system so again all of your containers within a single host have to run the same operating system either all Linux or eventually would be all Windows they're going to use the bits that they need from that operating system so the net-net of it is it's a lighter-weight footprint I should be able to boot them quicker and the reason people get very very fixated on I can boot a container fast is because in this container environment the types of applications that I'm building tend to be more what they call ephemeral pieces of them are going to go away they're going to come back I'm gonna want to spin them up quickly if I have a scalable application spin them up or spin them down and so what you're looking for is a operating environment that will come up very very quickly so just to put that in context to spin up a virtual machine it may take three four minutes because of the operating system coming up to spin up a container usually is on the order of a second or a couple of seconds so big you know order of difference between there now the second piece that's really important and this is where a lot of people kind of get confused about what's going on in the container ecosystem is what happens at that control plane and the first thing to understand is when we talked about you know virtualized applications we tend to talk about very stateful sometimes they're called platform two sometimes they're called legacy applications but they're more or less stateful so the expectation is once you deploy them other than maybe Vee motioning them around for availability you're not scaling them up and down you don't expect them to fail frequently and so the scalability needed at the control plane is fairly well-defined maybe it's a thousand hosts or 10,000 hosts when we start dealing with containers the types of applications we deploy tend to be more what they call 12 factor applications sometimes you hear them call modular applications cloud native applications the idea being they're much more modular they tend to be more state less so the idea of maintaining state tends to get pushed somewhere else but they're designed for scale they're designed for mobile applications for real-time data applications and so the control plane unlike here which tends to be somewhat stateful and more confined in terms of scale has to be designed to be a distributed control plane it has to be designed to scale much much larger and so as part of that what we see is we're seeing technologies come out that sort of break up the things that were functions inside of a vCenter control plane into sort of distinct technologies that number one tend to scale more because they're written in distributed manner and number two they've got a certain amount of sort of mix-and-match that you can have with them depending on what your applications gonna do so let's talk through the basic things that are in here the first layer that you'll often hear about is clustering how do I cluster together sets of container hosts an example of this is docker swarm technology another example of this is something like Etsy D from core OS it's a technology to sort of figure out where my clusters of hosts are going to be the next layer is what's called service discovery if I'm deploying hundreds and hundreds or thousands of devices I want to you know containers I want to be able to figure out what services are available queuing services database services you know notification services the things that are out there I need to do that dynamically and automatically the next piece is going to be scheduling those containers just like vCenter is going to put it on the right host to make sure that it's load balanced properly there's a scheduling function to make sure that containers get deployed to the right container and then the next piece is what they call application scheduling so in these environments I don't tend to schedule my applications in these environments they could be a mix of batch applications Hadoop applications long running applications short running applications I need a more advanced intelligent scheduler to make sure that I'm getting the containers and the applications deployed on the right place and as efficient as possible and then on top of that I have my actual applications so the takeaway from this is at the host level some difference between how heavy a virtualized environment is going to be versus a container environment and that you want that to match how your application requirements are and if the control plane a more structured model for doing the functions that you need to manage the environment in a container model a more distributed model so with that I'm gonna go ahead and wrap that up we're going to get into some more depth in other videos we hope you enjoy these once again this has been a wiki bound whiteboard video you can find more information about all of our research and all the information about these technologies at wiki bond com and again if you want to follow me again my name is brian grace lee i'm at be grace lee on twitter or you can follow at wiki bon on twitter as well thank you and have a great day

(intro music) >> Narrator: "theCUBE's" live coverage is made possible by funding from Dell Technologies, creating technologies that drive human progress. (gentle music) >> Hey everyone, welcome back to "theCUBE," the leader in live and emerging tech coverage. As you well know, we are live at MWC23 in Barcelona, Spain. Lisa Martin with Dave Nicholson. Day three of our coverage, as you know, 'cause you've been watching the first two days. A lot of conversations about ecosystem, a lot about disruption in the telco industry. We're going to be talking about Open RAN. You've heard some of those great conversations, the complexities, the opportunities. Two guests join Dave and me. Abdullah Abuzaid, Technical Product Manager at Dell, and Gil Hellmann, VP Telecom Solutions Engineering and Architecture at Wind River. Welcome to the program guys. >> Thank you. >> Nice to be here. >> Let's talk a little bit about Dell and Wind River. We'll each ask you both the same question, and talk to us about how you're working together to really address the complexities that organizations are having when they're considering moving from a closed environment to an open environment. >> Definitely. Thank you for hosting us. By end of the day, the relationship between Dell and Wind River is not a new. We've been collaborating in the open ecosystem for long a time enough. And that's one of the, our partnership is a result of this collaboration where we've been trying to make more efficient operation in the ecosystem. The open environment ecosystem, it has the plus and a concern. The plus of simplicity, choice of multiple vendors, and then the concern of complexity managing these vendors. Especially if we look at examples for the Open RAN ecosystem, dealing with multiple vendors, trying to align them. It bring a lot of operational complexity and TCO challenges for our customers, from this outcome where we build our partnership with Wind River in order to help our customer to simplify, or run deployment, operation, and lifecycle management and sustain it. >> And who are the customers, by the way? >> Mainly the CSP customers who are targeting Open RAN and Virtual RAN deployments. That digital transformation moving towards unified cloud environment, or a seamless cloud experience from Core to RAN, these are the customers we are working with them. >> You'll give us your perspective, your thoughts on the partnership, and the capabilities that you're enabling, the CSPs with that. >> Sure. It's actually started last year here in Barcelona, when we set together, and started to look at the, you know, the industry, the adoption of Open RAN, and the challenges. And Open RAN brings a lot of possibilities and benefit, but it does bring a lot of challenges of reintegrating what you desegregate. In the past, you purchase everything from one vendor, they provide the whole solution. Now you open it, you have different layers. So if you're looking at Open RAN, you have, I like to look at it as three major layers, the management, application, and the infrastructure. And we're starting to look what are the challenges. And the challenges of integration, of complexity, knowledge that operator has with cloud infrastructure. And this is where we basically, Dell and Winder River set together and say, "How can we ease this? "How we can make it simpler?" And we decided to partner and bring a joint infrastructure solution to market, that's not only integrated at a lab at the factory level, but it basically comes with complete lifecycle management from the day zero deployment, through the day two operation, everything done through location, through Dell supported, working out of the box. So basically taking this whole infrastructure layer integration pain out, de-risking everything, and then continuing from there to work with the ecosystem vendor to reintegrate, validate the application, on top of this infrastructure. >> So what is the, what is the Wind River secret sauce in this, in this mix, for folks who aren't familiar with what Wind River does? >> Yes, absolutely. So Wind River, for many, many don't know, we're in business since 1981. So over 40 years. We specialize high performance, high reliability infrastructure. We touch every aspect of your day and your life. From the airplane that you fly, the cars, the medical equipment. And if we go into the telco, most of the telco equipment that it's not virtualized, not throughout the fight today, using our operating system. So from all the leading equipment manufacturers and even the smaller one. And as the world started to go into desegregation in cloud, Wind River started to look at this and say, "Okay, everything is evolving. Instead of a device that included the application, the hardware, everything fused together, it's now being decomposed. So instead of providing the operating environment to develop and deploy the application to the device manufacturer, now we're providing it basically to build the cloud. So to oversimplify, I call it a cloud OS, okay. It's a lot more than OS, it's an operating environment. But we took basically our experience, the same experience that, you know, we used in all those years with the telco equipment manufacturer, and brought it into the cloud. So we're basically providing solution to build an on-premises scalable cloud from the core all the way to the far edge, that doesn't compromise reliability, doesn't compromise performance, and address all the telco needs. >> So I, Abdullah, maybe you can a answer this. >> Yeah. >> What is the, what does the go-to-market motion look like, considering that you have two separate companies that can address customers directly, separately. What does that, what does that look like if you're approaching a possible customer who is, who's knocking on the door? >> How does that work? >> Exactly. And this effort is a Dell turnkey sales service offering, or solution offering to our customers. Where Dell, in collaboration with Wind River, we proactively validate, integrate, and productize the solution as engineered system, knock door on our customer who are trying to transform to Open RAN or open ecosystem. We can help you to go through that seamless experience, by pre-validating with whatever workload you want to introduce, enable zero touch provisioning, and during the day one deployment, and ensure we have sustainable lifecycle management throughout the lifecycle of the product in, in operate, in operational network, as well as having a unified single call of support from Dell side. >> Okay. So I was just going to ask you about support. So I'm a CSP, I have the solution, I go to Dell for support. >> Exactly. >> Okay. So start with Dell, and level one, level two. And if there are complex issues related to the cloud core itself, then Wind River will be on our back supporting us. >> Talk a little bit about a cust, a CSP example that is, is using the technology, and some of the outcomes that they're able to achieve. I'd love to get both of your perspectives on that. >> Vodafone is a great example. We're here in Barcelona. Vodafone is the first ora network in Europe, and it's using our joint solution. >> What are some of the, the outcomes that it's helping them to achieve? >> Faster time to market. As you see, they already started to deploy the ORAN in commercial network, and very successful in the trials that they did last year. We're also not stopping there. We're evolving, working with them together to improve like stuff around energy efficiency. So continue to optimize. So the outcome, it's just simplifying it, and you know, ready to go. Using experience that we have, Wind River is powering the first basically virtualized RAN 5G network in the world. This is with Verizon. We're at the very large scale. We started this deployment in late '20 and '19, the first site. And then through 2020 to 2022, we basically rolled in large scale. We have a lot of experience learning from it, which what we brought into the table when we partnered with Dell. A lot of experience from how you deploy at scale. Many sites from a central location, updates, upgrade. So the whole day two operation, and this is coming to bearing the solution that basically Vodafone is deploying now, and which allowed them... If I, if I look at my engagement with Verizon, started years before we started. And it took quite some time until we got stuff running. And if you look at the Vodafone time schedule, was significantly compressed compared to the Verizon first deployment. And I can tell you that there are other service providers that were announced here by KDI, for example. It's another one moving even faster. So it's accelerating the whole movement to Ora. >> We've heard a lot of acceleration talk this week. I'd love to get your perspective, Abdullah, talking about, you know, you, you just mentioned two huge names in Telco, Vodafone and Verizon. >> Yep. >> Talk a little bit about Dell's commitment to helping telecommunications companies really advance, accelerate innovation so that all of us on the other end have this thing that just works wherever we are 24 by 7. >> Not exactly. And this, we go back to the challenges in Open ecosystem. Managing multiple vendors at the same time, is a challenge for our customers. And that's why we are trying to simplify their life cycle by have, by being a trusted partner, working with our customer through all the journey. We started with Dish in their 5G deployment. Also with Vodafone. We're finding the right partners working with them proactively before getting into, in front of the customer to, we've done our homework, we are ready to simplify the process for you to go for it. If you look at the RAN in particular, we are talking with the 5g. We have ran the simplification, but they still have on the other side, limited resources and skillset can support it. So, bringing a pro, ahead of time engineer system, with a zero touch of provisioning enablement, and sustainable life cycle management, it lead to the faster time to market deployment, TCO savings, improved margins for our customers, and faster business revenue for their end users. >> Solid outcomes. >> And, and what you just just described, justifies the pain associated with disaggregating and reintegrating, which is the way that Gill referenced it, which I think is great because you're not, you're not, you're not re-aggregating, (laughs) you're reintegrating, and you're creating something that's better. >> Exactly. >> Moving forward. Otherwise, why would you do it? >> Exactly. And if you look at it, the player in the ecosystem, you have the vendors, you have the service integrators, you have the automation enablers, but kind of they are talking in silos. Everyone, this is my raci, this is what I'm responsible for. I, I'm not able, I don't want to get into something else while we are going the extra mile by working proactively in that ecosystem to... Let's bring brains together, find out what's one plus one can bring three for our customers, so we make it end-to-end seamless experience, not only on the technical part, but also on the business aspect side of it. >> So, so the partnership, it's about reducing the pen. I will say eliminating it. So this is the, the core of it. And you mentioned getting better coverage for your phone. I do want to point out that the phones are great, but if you look at the premises of a 5G network, it's to enable a lot more things that will touch your life that are beyond the consumer and the phone. Stuff like connected vehicles. So for example, something as simple as collision avoidance, the ability for the car that goes in front of you to be able to see what's happening and broadcast this information to the car behind that have no ability to see it. And basically affect our life in a way that makes our driving safer. And for this, you need a ultra low, reliable low latency communication. You need a 5G network. >> I'm glad you brought that up, because you know, we think about, "Well we just have to be connected all the time." But those are some of the emerging technologies that are going to be potentially lifesaving, and, and really life transforming that you guys are helping to enable. So, really great stuff there, but so much promise coming down the road. What's next for Dell and Wind River? And, and when you're in conversations with prospective CSP's, what is the superpower that you deliver together? I'd love to get both of your perspectives. >> So, if you look at it, number one, customers look at it, last savings and their day-to-day operation. In 5G nature, we are talking the introduction of ORAN. This is still picking up. But there is a mutualization and densification of ORAN. And this is where we're talking on monetizing my deployment. Then the third phase, we're talking sustainability and advanced service introduction. Where I want to move not only ORAN, I want to bring the edge at the same side, I want to define the advanced use cases of edge, where it enables me with this pre-work being done to deliver more services and better SLA services. By end of the day, 5G as a girl mentioned earlier, is not about a good better phone coverage, or a better speed robot, but what customized SLA's I can deliver. So it enables me to deliver different business streams to my end users. >> Yeah. >> So yeah. I will say there are two pens. One, it's the technology side. So for an example, energy efficiency. It's a very big pin point. And sustainability. So we work a lot around this, and basically to advance this. So if you look at the integrated solution today, it's very highly optimized for resource consumption. But to be able to more dynamically be able to change your power profile without compromising the SLA. So this is one side. The other side, it's about all those applications that will come to the 5G network to make our life better. It's about integrating, validating, certifying those applications. So, it's not just easy to deploy an ORAN network, but it's easy to deploy those applications. >> I'd be curious to get your perspective on the question of ROI in this, in this space. Specifically with the sort of the macro headwinds (clears throat) the economies of the world are facing right now, if you accept that. What does the ROI timeline look like when you're talking about moving towards ORAN, adopting VRAN, an amazing, you know, a plethora of new services that can be delivered, but will these operators have the appetite to take that, make that investment and take on that risk based upon the ROI time horizon? Any thoughts on that? >> Yeah. So if you look at the early days or ORAN introduction in particular, most of the entrepreneurs of ORAN and Virtual RAN ran into the challenges of not only the complexity of open ecosystem, but the integration, is like the redos of the work. And that's where we are trying to address it via pre-engineered system or building an engineer system proactively before getting it to the customers. Per our result or outcomes we get, we are talking about 30 to 50% savings on the optics. We are talking 110 ROI for our customers, simply because we are reducing the redos, the time spent to discover and explore. Because we've done that rework ahead of time, we found the optimization issues. Just for example, any customer can buy the same components from any multiple vendors, but how I can bring them together and give, deliver for me the best performance that I can fully utilize, that's, that's where it brings the value for our customer, and accelerate the deployment and the operation of the network. >> Do you have anything to add before we close in the next 30 seconds? >> Yeah. Yeah. (laughs) >> Absolutely. I would say, we start to see the data coming from two years of operation at scale. And the data supports performance. It's the same or better than traditional system. And the cost of operation, it's as good or better than traditional. Unfortunately, I can't provide more specific data. But the point is, when something is unknown in the beginning, of course you're more afraid, you take more conservative approach. Now the data starts to flow. And from here, the intention needs to go even better. So more efficiency, so cost less than traditional system, both to operate as well as to build up. But it's definitely the data that we have today says, the, ORAN system is at part, at the minimum. >> So, definite ROI there. Guys, thank you so much for joining Dave and me talking about how you're helping organizations not just address the complexities of moving from close to open, but to your point, eliminating them. We appreciate your time and, and your insights. >> Thank you. >> All right. For our guests and for Dave Nicholson, I'm Lisa Martin. You're watching "theCUBE," the leader in live and emerging tech coverage. Live from MWC23. We'll be back after a short break. (outro music)

>> Welcome back to SuperCloud2. This is Dave Vellante, and we're here with Jack Greenfield. He's the Vice President of Enterprise Architecture and the Chief Architect for the global technology platform at Walmart. Jack, I want to thank you for coming on the program. Really appreciate your time. >> Glad to be here, Dave. Thanks for inviting me and appreciate the opportunity to chat with you. >> Yeah, it's our pleasure. Now we call what you've built a SuperCloud. That's our term, not yours, but how would you describe the Walmart Cloud Native Platform? >> So WCNP, as the acronym goes, is essentially an implementation of Kubernetes for the Walmart ecosystem. And what that means is that we've taken Kubernetes off the shelf as open source, and we have integrated it with a number of foundational services that provide other aspects of our computational environment. So Kubernetes off the shelf doesn't do everything. It does a lot. In particular the orchestration of containers, but it delegates through API a lot of key functions. So for example, secret management, traffic management, there's a need for telemetry and observability at a scale beyond what you get from raw Kubernetes. That is to say, harvesting the metrics that are coming out of Kubernetes and processing them, storing them in time series databases, dashboarding them, and so on. There's also an angle to Kubernetes that gets a lot of attention in the daily DevOps routine, that's not really part of the open source deliverable itself, and that is the DevOps sort of CICD pipeline-oriented lifecycle. And that is something else that we've added and integrated nicely. And then one more piece of this picture is that within a Kubernetes cluster, there's a function that is critical to allowing services to discover each other and integrate with each other securely and with proper configuration provided by the concept of a service mesh. So Istio, Linkerd, these are examples of service mesh technologies. And we have gone ahead and integrated actually those two. There's more than those two, but we've integrated those two with Kubernetes. So the net effect is that when a developer within Walmart is going to build an application, they don't have to think about all those other capabilities where they come from or how they're provided. Those are already present, and the way the CICD pipelines are set up, it's already sort of in the picture, and there are configuration points that they can take advantage of in the primary YAML and a couple of other pieces of config that we supply where they can tune it. But at the end of the day, it offloads an awful lot of work for them, having to stand up and operate those services, fail them over properly, and make them robust. All of that's provided for. >> Yeah, you know, developers often complain they spend too much time wrangling and doing things that aren't productive. So I wonder if you could talk about the high level business goals of the initiative in terms of the hardcore benefits. Was the real impetus to tap into best of breed cloud services? Were you trying to cut costs? Maybe gain negotiating leverage with the cloud guys? Resiliency, you know, I know was a major theme. Maybe you could give us a sense of kind of the anatomy of the decision making process that went in. >> Sure, and in the course of answering your question, I think I'm going to introduce the concept of our triplet architecture which we haven't yet touched on in the interview here. First off, just to sort of wrap up the motivation for WCNP itself which is kind of orthogonal to the triplet architecture. It can exist with or without it. Currently does exist with it, which is key, and I'll get to that in a moment. The key drivers, business drivers for WCNP were developer productivity by offloading the kinds of concerns that we've just discussed. Number two, improving resiliency, that is to say reducing opportunity for human error. One of the challenges you tend to run into in a large enterprise is what we call snowflakes, lots of gratuitously different workloads, projects, configurations to the extent that by developing and using WCNP and continuing to evolve it as we have, we end up with cookie cutter like consistency across our workloads which is super valuable when it comes to building tools or building services to automate operations that would otherwise be manual. When everything is pretty much done the same way, that becomes much simpler. Another key motivation for WCNP was the ability to abstract from the underlying cloud provider. And this is going to lead to a discussion of our triplet architecture. At the end of the day, when one works directly with an underlying cloud provider, one ends up taking a lot of dependencies on that particular cloud provider. Those dependencies can be valuable. For example, there are best of breed services like say Cloud Spanner offered by Google or say Cosmos DB offered by Microsoft that one wants to use and one is willing to take the dependency on the cloud provider to get that functionality because it's unique and valuable. On the other hand, one doesn't want to take dependencies on a cloud provider that don't add a lot of value. And with Kubernetes, we have the opportunity, and this is a large part of how Kubernetes was designed and why it is the way it is, we have the opportunity to sort of abstract from the underlying cloud provider for stateless workloads on compute. And so what this lets us do is build container-based applications that can run without change on different cloud provider infrastructure. So the same applications can run on WCNP over Azure, WCNP over GCP, or WCNP over the Walmart private cloud. And we have a private cloud. Our private cloud is OpenStack based and it gives us some significant cost advantages as well as control advantages. So to your point, in terms of business motivation, there's a key cost driver here, which is that we can use our own private cloud when it's advantageous and then use the public cloud provider capabilities when we need to. A key place with this comes into play is with elasticity. So while the private cloud is much more cost effective for us to run and use, it isn't as elastic as what the cloud providers offer, right? We don't have essentially unlimited scale. We have large scale, but the public cloud providers are elastic in the extreme which is a very powerful capability. So what we're able to do is burst, and we use this term bursting workloads into the public cloud from the private cloud to take advantage of the elasticity they offer and then fall back into the private cloud when the traffic load diminishes to the point where we don't need that elastic capability, elastic capacity at low cost. And this is a very important paradigm that I think is going to be very commonplace ultimately as the industry evolves. Private cloud is easier to operate and less expensive, and yet the public cloud provider capabilities are difficult to match. >> And the triplet, the tri is your on-prem private cloud and the two public clouds that you mentioned, is that right? >> That is correct. And we actually have an architecture in which we operate all three of those cloud platforms in close proximity with one another in three different major regions in the US. So we have east, west, and central. And in each of those regions, we have all three cloud providers. And the way it's configured, those data centers are within 10 milliseconds of each other, meaning that it's of negligible cost to interact between them. And this allows us to be fairly agnostic to where a particular workload is running. >> Does a human make that decision, Jack or is there some intelligence in the system that determines that? >> That's a really great question, Dave. And it's a great question because we're at the cusp of that transition. So currently humans make that decision. Humans choose to deploy workloads into a particular region and a particular provider within that region. That said, we're actively developing patterns and practices that will allow us to automate the placement of the workloads for a variety of criteria. For example, if in a particular region, a particular provider is heavily overloaded and is unable to provide the level of service that's expected through our SLAs, we could choose to fail workloads over from that cloud provider to a different one within the same region. But that's manual today. We do that, but people do it. Okay, we'd like to get to where that happens automatically. In the same way, we'd like to be able to automate the failovers, both for high availability and sort of the heavier disaster recovery model between, within a region between providers and even within a provider between the availability zones that are there, but also between regions for the sort of heavier disaster recovery or maintenance driven realignment of workload placement. Today, that's all manual. So we have people moving workloads from region A to region B or data center A to data center B. It's clean because of the abstraction. The workloads don't have to know or care, but there are latency considerations that come into play, and the humans have to be cognizant of those. And automating that can help ensure that we get the best performance and the best reliability. >> But you're developing the dataset to actually, I would imagine, be able to make those decisions in an automated fashion over time anyway. Is that a fair assumption? >> It is, and that's what we're actively developing right now. So if you were to look at us today, we have these nice abstractions and APIs in place, but people run that machine, if you will, moving toward a world where that machine is fully automated. >> What exactly are you abstracting? Is it sort of the deployment model or, you know, are you able to abstract, I'm just making this up like Azure functions and GCP functions so that you can sort of run them, you know, with a consistent experience. What exactly are you abstracting and how difficult was it to achieve that objective technically? >> that's a good question. What we're abstracting is the Kubernetes node construct. That is to say a cluster of Kubernetes nodes which are typically VMs, although they can run bare metal in certain contexts, is something that typically to stand up requires knowledge of the underlying cloud provider. So for example, with GCP, you would use GKE to set up a Kubernetes cluster, and in Azure, you'd use AKS. We are actually abstracting that aspect of things so that the developers standing up applications don't have to know what the underlying cluster management provider is. They don't have to know if it's GCP, AKS or our own Walmart private cloud. Now, in terms of functions like Azure functions that you've mentioned there, we haven't done that yet. That's another piece that we have sort of on our radar screen that, we'd like to get to is serverless approach, and the Knative work from Google and the Azure functions, those are things that we see good opportunity to use for a whole variety of use cases. But right now we're not doing much with that. We're strictly container based right now, and we do have some VMs that are running in sort of more of a traditional model. So our stateful workloads are primarily VM based, but for serverless, that's an opportunity for us to take some of these stateless workloads and turn them into cloud functions. >> Well, and that's another cost lever that you can pull down the road that's going to drop right to the bottom line. Do you see a day or maybe you're doing it today, but I'd be surprised, but where you build applications that actually span multiple clouds or is there, in your view, always going to be a direct one-to-one mapping between where an application runs and the specific cloud platform? >> That's a really great question. Well, yes and no. So today, application development teams choose a cloud provider to deploy to and a location to deploy to, and they have to get involved in moving an application like we talked about today. That said, the bursting capability that I mentioned previously is something that is a step in the direction of automatic migration. That is to say we're migrating workload to different locations automatically. Currently, the prototypes we've been developing and that we think are going to eventually make their way into production are leveraging Istio to assess the load incoming on a particular cluster and start shedding that load into a different location. Right now, the configuration of that is still manual, but there's another opportunity for automation there. And I think a key piece of this is that down the road, well, that's a, sort of a small step in the direction of an application being multi provider. We expect to see really an abstraction of the fact that there is a triplet even. So the workloads are moving around according to whatever the control plane decides is necessary based on a whole variety of inputs. And at that point, you will have true multi-cloud applications, applications that are distributed across the different providers and in a way that application developers don't have to think about. >> So Walmart's been a leader, Jack, in using data for competitive advantages for decades. It's kind of been a poster child for that. You've got a mountain of IP in the form of data, tools, applications best practices that until the cloud came out was all On Prem. But I'm really interested in this idea of building a Walmart ecosystem, which obviously you have. Do you see a day or maybe you're even doing it today where you take what we call the Walmart SuperCloud, WCNP in your words, and point or turn that toward an external world or your ecosystem, you know, supporting those partners or customers that could drive new revenue streams, you know directly from the platform? >> Great questions, Dave. So there's really two things to say here. The first is that with respect to data, our data workloads are primarily VM basis. I've mentioned before some VMware, some straight open stack. But the key here is that WCNP and Kubernetes are very powerful for stateless workloads, but for stateful workloads tend to be still climbing a bit of a growth curve in the industry. So our data workloads are not primarily based on WCNP. They're VM based. Now that said, there is opportunity to make some progress there, and we are looking at ways to move things into containers that are currently running in VMs which are stateful. The other question you asked is related to how we expose data to third parties and also functionality. Right now we do have in-house, for our own use, a very robust data architecture, and we have followed the sort of domain-oriented data architecture guidance from Martin Fowler. And we have data lakes in which we collect data from all the transactional systems and which we can then use and do use to build models which are then used in our applications. But right now we're not exposing the data directly to customers as a product. That's an interesting direction that's been talked about and may happen at some point, but right now that's internal. What we are exposing to customers is applications. So we're offering our global integrated fulfillment capabilities, our order picking and curbside pickup capabilities, and our cloud powered checkout capabilities to third parties. And this means we're standing up our own internal applications as externally facing SaaS applications which can serve our partners' customers. >> Yeah, of course, Martin Fowler really first introduced to the world Zhamak Dehghani's data mesh concept and this whole idea of data products and domain oriented thinking. Zhamak Dehghani, by the way, is a speaker at our event as well. Last question I had is edge, and how you think about the edge? You know, the stores are an edge. Are you putting resources there that sort of mirror this this triplet model? Or is it better to consolidate things in the cloud? I know there are trade-offs in terms of latency. How are you thinking about that? >> All really good questions. It's a challenging area as you can imagine because edges are subject to disconnection, right? Or reduced connection. So we do place the same architecture at the edge. So WCNP runs at the edge, and an application that's designed to run at WCNP can run at the edge. That said, there are a number of very specific considerations that come up when running at the edge, such as the possibility of disconnection or degraded connectivity. And so one of the challenges we have faced and have grappled with and done a good job of I think is dealing with the fact that applications go offline and come back online and have to reconnect and resynchronize, the sort of online offline capability is something that can be quite challenging. And we have a couple of application architectures that sort of form the two core sets of patterns that we use. One is an offline/online synchronization architecture where we discover that we've come back online, and we understand the differences between the online dataset and the offline dataset and how they have to be reconciled. The other is a message-based architecture. And here in our health and wellness domain, we've developed applications that are queue based. So they're essentially business processes that consist of multiple steps where each step has its own queue. And what that allows us to do is devote whatever bandwidth we do have to those pieces of the process that are most latency sensitive and allow the queue lengths to increase in parts of the process that are not latency sensitive, knowing that they will eventually catch up when the bandwidth is restored. And to put that in a little bit of context, we have fiber lengths to all of our locations, and we have I'll just use a round number, 10-ish thousand locations. It's larger than that, but that's the ballpark, and we have fiber to all of them, but when the fiber is disconnected, When the disconnection happens, we're able to fall back to 5G and to Starlink. Starlink is preferred. It's a higher bandwidth. 5G if that fails. But in each of those cases, the bandwidth drops significantly. And so the applications have to be intelligent about throttling back the traffic that isn't essential, so that it can push the essential traffic in those lower bandwidth scenarios. >> So much technology to support this amazing business which started in the early 1960s. Jack, unfortunately, we're out of time. I would love to have you back or some members of your team and drill into how you're using open source, but really thank you so much for explaining the approach that you've taken and participating in SuperCloud2. >> You're very welcome, Dave, and we're happy to come back and talk about other aspects of what we do. For example, we could talk more about the data lakes and the data mesh that we have in place. We could talk more about the directions we might go with serverless. So please look us up again. Happy to chat. >> I'm going to take you up on that, Jack. All right. This is Dave Vellante for John Furrier and the Cube community. Keep it right there for more action from SuperCloud2. (upbeat music)

>> Welcome back to SuperCloud2. This is Dave Vellante, and we're here with Jack Greenfield. He's the Vice President of Enterprise Architecture and the Chief Architect for the global technology platform at Walmart. Jack, I want to thank you for coming on the program. Really appreciate your time. >> Glad to be here, Dave. Thanks for inviting me and appreciate the opportunity to chat with you. >> Yeah, it's our pleasure. Now we call what you've built a SuperCloud. That's our term, not yours, but how would you describe the Walmart Cloud Native Platform? >> So WCNP, as the acronym goes, is essentially an implementation of Kubernetes for the Walmart ecosystem. And what that means is that we've taken Kubernetes off the shelf as open source, and we have integrated it with a number of foundational services that provide other aspects of our computational environment. So Kubernetes off the shelf doesn't do everything. It does a lot. In particular the orchestration of containers, but it delegates through API a lot of key functions. So for example, secret management, traffic management, there's a need for telemetry and observability at a scale beyond what you get from raw Kubernetes. That is to say, harvesting the metrics that are coming out of Kubernetes and processing them, storing them in time series databases, dashboarding them, and so on. There's also an angle to Kubernetes that gets a lot of attention in the daily DevOps routine, that's not really part of the open source deliverable itself, and that is the DevOps sort of CICD pipeline-oriented lifecycle. And that is something else that we've added and integrated nicely. And then one more piece of this picture is that within a Kubernetes cluster, there's a function that is critical to allowing services to discover each other and integrate with each other securely and with proper configuration provided by the concept of a service mesh. So Istio, Linkerd, these are examples of service mesh technologies. And we have gone ahead and integrated actually those two. There's more than those two, but we've integrated those two with Kubernetes. So the net effect is that when a developer within Walmart is going to build an application, they don't have to think about all those other capabilities where they come from or how they're provided. Those are already present, and the way the CICD pipelines are set up, it's already sort of in the picture, and there are configuration points that they can take advantage of in the primary YAML and a couple of other pieces of config that we supply where they can tune it. But at the end of the day, it offloads an awful lot of work for them, having to stand up and operate those services, fail them over properly, and make them robust. All of that's provided for. >> Yeah, you know, developers often complain they spend too much time wrangling and doing things that aren't productive. So I wonder if you could talk about the high level business goals of the initiative in terms of the hardcore benefits. Was the real impetus to tap into best of breed cloud services? Were you trying to cut costs? Maybe gain negotiating leverage with the cloud guys? Resiliency, you know, I know was a major theme. Maybe you could give us a sense of kind of the anatomy of the decision making process that went in. >> Sure, and in the course of answering your question, I think I'm going to introduce the concept of our triplet architecture which we haven't yet touched on in the interview here. First off, just to sort of wrap up the motivation for WCNP itself which is kind of orthogonal to the triplet architecture. It can exist with or without it. Currently does exist with it, which is key, and I'll get to that in a moment. The key drivers, business drivers for WCNP were developer productivity by offloading the kinds of concerns that we've just discussed. Number two, improving resiliency, that is to say reducing opportunity for human error. One of the challenges you tend to run into in a large enterprise is what we call snowflakes, lots of gratuitously different workloads, projects, configurations to the extent that by developing and using WCNP and continuing to evolve it as we have, we end up with cookie cutter like consistency across our workloads which is super valuable when it comes to building tools or building services to automate operations that would otherwise be manual. When everything is pretty much done the same way, that becomes much simpler. Another key motivation for WCNP was the ability to abstract from the underlying cloud provider. And this is going to lead to a discussion of our triplet architecture. At the end of the day, when one works directly with an underlying cloud provider, one ends up taking a lot of dependencies on that particular cloud provider. Those dependencies can be valuable. For example, there are best of breed services like say Cloud Spanner offered by Google or say Cosmos DB offered by Microsoft that one wants to use and one is willing to take the dependency on the cloud provider to get that functionality because it's unique and valuable. On the other hand, one doesn't want to take dependencies on a cloud provider that don't add a lot of value. And with Kubernetes, we have the opportunity, and this is a large part of how Kubernetes was designed and why it is the way it is, we have the opportunity to sort of abstract from the underlying cloud provider for stateless workloads on compute. And so what this lets us do is build container-based applications that can run without change on different cloud provider infrastructure. So the same applications can run on WCNP over Azure, WCNP over GCP, or WCNP over the Walmart private cloud. And we have a private cloud. Our private cloud is OpenStack based and it gives us some significant cost advantages as well as control advantages. So to your point, in terms of business motivation, there's a key cost driver here, which is that we can use our own private cloud when it's advantageous and then use the public cloud provider capabilities when we need to. A key place with this comes into play is with elasticity. So while the private cloud is much more cost effective for us to run and use, it isn't as elastic as what the cloud providers offer, right? We don't have essentially unlimited scale. We have large scale, but the public cloud providers are elastic in the extreme which is a very powerful capability. So what we're able to do is burst, and we use this term bursting workloads into the public cloud from the private cloud to take advantage of the elasticity they offer and then fall back into the private cloud when the traffic load diminishes to the point where we don't need that elastic capability, elastic capacity at low cost. And this is a very important paradigm that I think is going to be very commonplace ultimately as the industry evolves. Private cloud is easier to operate and less expensive, and yet the public cloud provider capabilities are difficult to match. >> And the triplet, the tri is your on-prem private cloud and the two public clouds that you mentioned, is that right? >> That is correct. And we actually have an architecture in which we operate all three of those cloud platforms in close proximity with one another in three different major regions in the US. So we have east, west, and central. And in each of those regions, we have all three cloud providers. And the way it's configured, those data centers are within 10 milliseconds of each other, meaning that it's of negligible cost to interact between them. And this allows us to be fairly agnostic to where a particular workload is running. >> Does a human make that decision, Jack or is there some intelligence in the system that determines that? >> That's a really great question, Dave. And it's a great question because we're at the cusp of that transition. So currently humans make that decision. Humans choose to deploy workloads into a particular region and a particular provider within that region. That said, we're actively developing patterns and practices that will allow us to automate the placement of the workloads for a variety of criteria. For example, if in a particular region, a particular provider is heavily overloaded and is unable to provide the level of service that's expected through our SLAs, we could choose to fail workloads over from that cloud provider to a different one within the same region. But that's manual today. We do that, but people do it. Okay, we'd like to get to where that happens automatically. In the same way, we'd like to be able to automate the failovers, both for high availability and sort of the heavier disaster recovery model between, within a region between providers and even within a provider between the availability zones that are there, but also between regions for the sort of heavier disaster recovery or maintenance driven realignment of workload placement. Today, that's all manual. So we have people moving workloads from region A to region B or data center A to data center B. It's clean because of the abstraction. The workloads don't have to know or care, but there are latency considerations that come into play, and the humans have to be cognizant of those. And automating that can help ensure that we get the best performance and the best reliability. >> But you're developing the dataset to actually, I would imagine, be able to make those decisions in an automated fashion over time anyway. Is that a fair assumption? >> It is, and that's what we're actively developing right now. So if you were to look at us today, we have these nice abstractions and APIs in place, but people run that machine, if you will, moving toward a world where that machine is fully automated. >> What exactly are you abstracting? Is it sort of the deployment model or, you know, are you able to abstract, I'm just making this up like Azure functions and GCP functions so that you can sort of run them, you know, with a consistent experience. What exactly are you abstracting and how difficult was it to achieve that objective technically? >> that's a good question. What we're abstracting is the Kubernetes node construct. That is to say a cluster of Kubernetes nodes which are typically VMs, although they can run bare metal in certain contexts, is something that typically to stand up requires knowledge of the underlying cloud provider. So for example, with GCP, you would use GKE to set up a Kubernetes cluster, and in Azure, you'd use AKS. We are actually abstracting that aspect of things so that the developers standing up applications don't have to know what the underlying cluster management provider is. They don't have to know if it's GCP, AKS or our own Walmart private cloud. Now, in terms of functions like Azure functions that you've mentioned there, we haven't done that yet. That's another piece that we have sort of on our radar screen that, we'd like to get to is serverless approach, and the Knative work from Google and the Azure functions, those are things that we see good opportunity to use for a whole variety of use cases. But right now we're not doing much with that. We're strictly container based right now, and we do have some VMs that are running in sort of more of a traditional model. So our stateful workloads are primarily VM based, but for serverless, that's an opportunity for us to take some of these stateless workloads and turn them into cloud functions. >> Well, and that's another cost lever that you can pull down the road that's going to drop right to the bottom line. Do you see a day or maybe you're doing it today, but I'd be surprised, but where you build applications that actually span multiple clouds or is there, in your view, always going to be a direct one-to-one mapping between where an application runs and the specific cloud platform? >> That's a really great question. Well, yes and no. So today, application development teams choose a cloud provider to deploy to and a location to deploy to, and they have to get involved in moving an application like we talked about today. That said, the bursting capability that I mentioned previously is something that is a step in the direction of automatic migration. That is to say we're migrating workload to different locations automatically. Currently, the prototypes we've been developing and that we think are going to eventually make their way into production are leveraging Istio to assess the load incoming on a particular cluster and start shedding that load into a different location. Right now, the configuration of that is still manual, but there's another opportunity for automation there. And I think a key piece of this is that down the road, well, that's a, sort of a small step in the direction of an application being multi provider. We expect to see really an abstraction of the fact that there is a triplet even. So the workloads are moving around according to whatever the control plane decides is necessary based on a whole variety of inputs. And at that point, you will have true multi-cloud applications, applications that are distributed across the different providers and in a way that application developers don't have to think about. >> So Walmart's been a leader, Jack, in using data for competitive advantages for decades. It's kind of been a poster child for that. You've got a mountain of IP in the form of data, tools, applications best practices that until the cloud came out was all On Prem. But I'm really interested in this idea of building a Walmart ecosystem, which obviously you have. Do you see a day or maybe you're even doing it today where you take what we call the Walmart SuperCloud, WCNP in your words, and point or turn that toward an external world or your ecosystem, you know, supporting those partners or customers that could drive new revenue streams, you know directly from the platform? >> Great question, Steve. So there's really two things to say here. The first is that with respect to data, our data workloads are primarily VM basis. I've mentioned before some VMware, some straight open stack. But the key here is that WCNP and Kubernetes are very powerful for stateless workloads, but for stateful workloads tend to be still climbing a bit of a growth curve in the industry. So our data workloads are not primarily based on WCNP. They're VM based. Now that said, there is opportunity to make some progress there, and we are looking at ways to move things into containers that are currently running in VMs which are stateful. The other question you asked is related to how we expose data to third parties and also functionality. Right now we do have in-house, for our own use, a very robust data architecture, and we have followed the sort of domain-oriented data architecture guidance from Martin Fowler. And we have data lakes in which we collect data from all the transactional systems and which we can then use and do use to build models which are then used in our applications. But right now we're not exposing the data directly to customers as a product. That's an interesting direction that's been talked about and may happen at some point, but right now that's internal. What we are exposing to customers is applications. So we're offering our global integrated fulfillment capabilities, our order picking and curbside pickup capabilities, and our cloud powered checkout capabilities to third parties. And this means we're standing up our own internal applications as externally facing SaaS applications which can serve our partners' customers. >> Yeah, of course, Martin Fowler really first introduced to the world Zhamak Dehghani's data mesh concept and this whole idea of data products and domain oriented thinking. Zhamak Dehghani, by the way, is a speaker at our event as well. Last question I had is edge, and how you think about the edge? You know, the stores are an edge. Are you putting resources there that sort of mirror this this triplet model? Or is it better to consolidate things in the cloud? I know there are trade-offs in terms of latency. How are you thinking about that? >> All really good questions. It's a challenging area as you can imagine because edges are subject to disconnection, right? Or reduced connection. So we do place the same architecture at the edge. So WCNP runs at the edge, and an application that's designed to run at WCNP can run at the edge. That said, there are a number of very specific considerations that come up when running at the edge, such as the possibility of disconnection or degraded connectivity. And so one of the challenges we have faced and have grappled with and done a good job of I think is dealing with the fact that applications go offline and come back online and have to reconnect and resynchronize, the sort of online offline capability is something that can be quite challenging. And we have a couple of application architectures that sort of form the two core sets of patterns that we use. One is an offline/online synchronization architecture where we discover that we've come back online, and we understand the differences between the online dataset and the offline dataset and how they have to be reconciled. The other is a message-based architecture. And here in our health and wellness domain, we've developed applications that are queue based. So they're essentially business processes that consist of multiple steps where each step has its own queue. And what that allows us to do is devote whatever bandwidth we do have to those pieces of the process that are most latency sensitive and allow the queue lengths to increase in parts of the process that are not latency sensitive, knowing that they will eventually catch up when the bandwidth is restored. And to put that in a little bit of context, we have fiber lengths to all of our locations, and we have I'll just use a round number, 10-ish thousand locations. It's larger than that, but that's the ballpark, and we have fiber to all of them, but when the fiber is disconnected, and it does get disconnected on a regular basis. In fact, I forget the exact number, but some several dozen locations get disconnected daily just by virtue of the fact that there's construction going on and things are happening in the real world. When the disconnection happens, we're able to fall back to 5G and to Starlink. Starlink is preferred. It's a higher bandwidth. 5G if that fails. But in each of those cases, the bandwidth drops significantly. And so the applications have to be intelligent about throttling back the traffic that isn't essential, so that it can push the essential traffic in those lower bandwidth scenarios. >> So much technology to support this amazing business which started in the early 1960s. Jack, unfortunately, we're out of time. I would love to have you back or some members of your team and drill into how you're using open source, but really thank you so much for explaining the approach that you've taken and participating in SuperCloud2. >> You're very welcome, Dave, and we're happy to come back and talk about other aspects of what we do. For example, we could talk more about the data lakes and the data mesh that we have in place. We could talk more about the directions we might go with serverless. So please look us up again. Happy to chat. >> I'm going to take you up on that, Jack. All right. This is Dave Vellante for John Furrier and the Cube community. Keep it right there for more action from SuperCloud2. (upbeat music)

>>Hello, brilliant humans and welcome back to Las Vegas, Nevada, where we are live from the AWS Reinvent Show floor here with the cube. My name is Savannah Peterson, joined with Dave Valante, and we have a very exciting conversation with you. Two, two companies you may have heard of. We've got AWS and Red Hat in the house. Manu and Joel, thank you so much for being here. Love this little fist bump. Started off, that's right. Before we even got rolling, Manu, you said that you wanted this to be the best segment of, of the cubes airing. We we're doing over a hundred segments, so you're gonna have to bring the heat. >>We're ready. We're did go. Are we ready? Yeah, go. We're ready. Let's bring it on. >>We're ready. All right. I'm, I'm ready. Dave's ready. Let's do it. How's the show going for you guys real quick before we dig in? >>Yeah, I think after Covid, it's really nice to see that we're back into the 2019 level and, you know, people just want to get out, meet people, have that human touch with each other, and I think a lot of trust gets built as a functional that, so it's super amazing to see our partners and customers here at Reedman. Yeah, >>And you've got a few in the house. That's true. Just a few maybe, maybe a couple >>Very few shows can say that, by the way. Yeah, it's maybe a handful. >>I think one of the things we were saying, it's almost like the entire Silicon Valley descended in the expo hall area, so >>Yeah, it's >>For a few different reasons. There's a few different silicon defined. Yeah, yeah, yeah. Don't have strong on for you. So far >>It's, it's, it is amazing. It's the 10th year, right? It's decade, I think I've been to five and it's, it grows every single year. It's the, you have to be here. It's as simple as that. And customers from every single industry are here too. You don't get, a lot of shows have every single industry and almost every single location around the globe. So it's, it's a must, must be >>Here. Well, and the personas evolved, right? I was at reinvent number two. That was my first, and it was all developers, not all, but a lot of developers. And today it's a business mix, really is >>Totally, is a business mix. And I just, I've talked about it a little bit down the show, but the diversity on the show floor, it's the first time I've had to wait in line for the ladies' room at a tech conference. Almost a two decade career. It is, yeah. And it was really refreshing. I'm so impressed. So clearly there's a commitment to community, but also a commitment to diversity. Yeah. And, and it's brilliant to see on the show floor. This is a partnership that is robust and has been around for a little while. Money. Why don't you tell us a little bit about the partnership here? >>Yes. So Red Hand and AWS are best friends, you know, forever together. >>Aw, no wonder we got the fist bumps and all the good vibes coming out. I know, it's great. I love that >>We have a decade of working together. I think the relationship in the first phase was around running rail bundled with E two. Sure. We have about 70,000 customers that are running rail, which are running mission critical workloads such as sap, Oracle databases, bespoke applications across the state of verticals. Now, as more and more enterprise customers are finally, you know, endorsing and adopting public cloud, I think that business is just gonna continue to grow. So a, a lot of progress there. The second titration has been around, you know, developers tearing Red Hat and aws, Hey, listen, we wanna, it's getting competitive. We wanna deliver new features faster, quicker, we want scale and we want resilience. So just entire push towards devs containers. So that's the second chapter with, you know, red Hat OpenShift on aws, which launched as a, a joint manage service in 2021 last year. And I think the third phase, which you're super excited about, is just bringing the ease of consumption, one click deployment, and then having our customers, you know, benefit from the joint committed spend programs together. So, you know, making sure that re and Ansible and JBoss, the entire portfolio of Red Hat products are available on AWS marketplace. So that's the 1, 2, 3, it of our relationship. It's a decade of working together and, you know, best friends are super committed to making sure our customers and partners continue successful. >>Yeah, that he said it, he said it perfectly. 2008, I know you don't like that, but we started with Rel on demand just in 2008 before E two even had a console. So the partnership has been there, like Manu says, for a long time, we got the partnership, we got the products up there now, and we just gotta finalize that, go to market and get that gas on the fire. >>Yeah. So Graviton Outpost, local zones, you lead it into all the new stuff. So that portends, I mean, 2008, we're talking two years after the launch of s3. >>That's right. >>Right. So, and now look, so is this a harbinger of things to come with these new innovations? >>Yeah, I, I would say, you know, the innovation is a key tenant of our partnership, our relationship. So if you look at from a product standpoint, red Hat or Rel was one of the first platforms that made a support for graviton, which is basically 40% better price performance than any other distribution. Then that translated into making sure that Rel is available on all of our regions globally. So this year we launched Switzerland, Spain, India, and Red Hat was available on launch there, support for Nitro support for Outpost Rosa support on Outpost as well. So I think that relationship, that innovation on the product side, that's pretty visible. I think that innovation again then translates into what we are doing on marketplace with one click deployments we spoke about. I think the third aspect of the know innovation is around making sure that we are making our partners and our customers successful. So one of the things that we've done so far is Joe leads a, you know, a black belt team that really goes into each customer opportunity, making sure how can we help you be successful. We launched and you know, we should be able to share that on a link. After this, we launched like a big playlist, which talks about every single use case on how do you get successful and running OpenShift on aws. So that innovation on behalf of our customers partners to make them successful, that's been a key tenant for us together as >>Well. That's right. And that team that Manu is talking about, we're gonna, gonna 10 x that team this year going into January. Our fiscal yield starts in January. Love that. So yeah, we're gonna have a lot of no hiring freeze over here. Nope. No ma'am. No. Yeah, that's right. Yeah. And you know what I love about working with aws and, and, and Manu just said it very, all of that's customer driven. Every single event that we, that he just talked about in that timeline, it's customer driven, right? Customers wanted rail on demand, customers want JBoss up in the cloud, Ansible this week, you know, everything's up there now. So it's just getting that go to market tight and we're gonna, we're gonna get that done. >>So what's the algorithm for customer driven in terms of taking the input? Because if every customers saying, Hey, I this a >>Really similar >>Question right up, right? I, that's what I want. And if you know, 95% of the customers say it, Jay, maybe that's a good idea. >>Yeah, that's right. Trends. But >>Yeah. You know, 30% you might be like, mm, you know, 20%, you know, how do you guys decide when to put gas on the fire? >>No, that, I think, as I mentioned, there are about 70,000 large customers that are running rail on Easy Two, many of these customers are informing our product strategy. So we have, you know, close to about couple of thousand power users. We have customer advisory booths, and these are the, you know, customers are informing us, Hey, let's get all of the Red Hat portfolio and marketplace support for graviton, support for Outpost. Why don't we, why are we not able to dip into the consumption committed spend programs for both Red Hat and aws? That's right. So it's these power users both at the developer level as well as the guys who are actually doing large commercial consumption. They are the ones who are informing the roadmap for both Red Hat and aws. >>But do, do you codify the the feedback? >>Yeah, I'm like, I wanna see the database, >>The, I think it was, I don't know, it was maybe Chasy, maybe it was Besos, that that data beats intuition. So do you take that information and somehow, I mean, it's global, 70,000 customers, right? And they have different weights, different spending patterns, different levels of maturity. Yeah. Do you, how do you codify that and then ultimately make the decision? Yeah, I >>If, I mean, well you, you've got the strategic advisory boards, which are made up of customers and partners and you know, you get, you get a good, you gotta get a good slice of your customer base to get, and you gotta take their feedback and you gotta do something with it, right? That's the, that's the way we do it and codify it at the product level, I'm sure open source. That's, that's basically how we work at the product level, right? The most elegant solution in open source wins. And that's, that's pretty much how we do that at the, >>I would just add, I think it's also just the implicit trust that the two companies had built with each other, working in the trenches, making our customers and partners successful over the last decade. And Alex, give an example. So that manifests itself in context of like, you know, Amazon and Red Hat just published the entire roadmap for OpenShift. What are the new features that are becoming over the next six to nine to 12 months? It's open source available on GitHub. Customers can see, and then they can basically come back and give feedback like, Hey, you know, we want hip compliance. We just launched. That was a big request that was coming from our >>Customers. That is not any process >>Also for Graviton or Nvidia instances. So I I I think it's a, >>Here's the thing, the reason I'm pounding on this is because you guys have a pretty high hit rate, and I think as a >>Customer, mildly successful company >>As, as a customer advocate, the better, you know, if, if you guys make bets that pay off, it's gonna pay off for customers. Right. And because there's a lot of failures in it. Yeah. I mean, let's face it. That's >>Right. And I think, I think you said the key word bets. You place a lot of small bets. Do you have the, the innovation engine to do that? AWS is the perfect place to place those small bets. And then you, you know, pour gas on the fire when, when they take off. >>Yeah, it's a good point. I mean, it's not expensive to experiment. Yeah. >>Especially in the managed service world. Right? >>And I know you love taking things to market and you're a go to market guy. Let's talk gtm, what's got your snow pumped about GTM for 2023? >>We, we are gonna, you know, 10 x the teams that's gonna be focused on these products, right? So we're gonna also come out with a hybrid committed spend program for our customers that meet them where they want to go. So they're coming outta the data center going into a cloud. We're gonna have a nice financial model for them to do that. And that's gonna take a lot of the friction out. >>Yeah. I mean, you've nailed it. I, I think the, the fact that now entire Red Hat portfolio is available on marketplace, you can do it on one click deployment. It's deeply integrated with Amazon services and the most important part that Joel was making now customers can double dip. They can drive benefit from the consumption committed spend programs, both from Red Hat and from aws, which is amazing. Which is a game changer That's right. For many of our large >>Customers. That's right. And that, so we're gonna, we're gonna really go to town on that next year. That's, and all the, all the resources that I have, which are the technology sellers and the sas, you know, the engineers we're growing this team the most out that team. So it's, >>When you say 10 x, how many are you at now? I'm >>Curious to see where you're headed. Tell you, okay. There's not right? Oh no, there's not one. It's triple digit. Yeah, yeah. >>Today. Oh, sweet. Awesome. >>So, and it's a very sizable team. They're actually making sure that each of our customers are successful and then really making sure that, you know, no customer left behind policy. >>And it's a great point that customers love when Amazonians and Red Hats show up, they love it and it's, they want to get more of it, and we're gonna, we're gonna give it to 'em. >>Must feel great to be loved like that. >>Yeah, that's right. Yeah. Yeah. I would say yes. >>Seems like it's safe to say that there's another decade of partnership between your two companies. >>Hope so. That's right. That's the plan. >>Yeah. And I would say also, you know, just the IBM coming into the mix here. Yeah. I, you know, red Hat has informed the way we have turned around our partnership with ibm, essentially we, we signed the strategic collaboration agreement with the company. All of IBM software now runs on Rosa. So that is now also providing a lot of tailwinds both to our rail customers and as well as Rosa customers. And I think it's a very net creative, very positive for our partnership. >>That's right. It's been very positive. Yep. Yeah. >>You see the >>Billboards positive. Yeah, right. Also that, that's great. Great point, Dave. Yep. We have a, we have a new challenge, a new tradition on the cube here at Reinvent where we're, well, it's actually kind of a glamor moment for you, depending on how you leverage it. We're looking for your 32nd hot take your Instagram reel, your sizzle thought leadership, biggest takeaway, most important theme from this year's show. I know you want, right, Joel? I mean, you TM boy, I feel like you can spit the time. >>Yeah. It is all about Rosa for us. It is all in on that, that's the native OpenShift offering on aws and that's, that's the soundbite we're going go to town with. Now, I don't wanna forget all the other products that are in there, but Rosa is a, is a very key push for us this year. >>Fantastic. All right. Manu. >>I think our customers, it's getting super competitive. Our customers want to innovate just a >>Little bit. >>The enterprise customers see the cloud native companies. I wanna do what these guys are doing. I wanna develop features at a fast clip. I wanna scale, I wanna be resilient. And I think that's really the spirit that's coming out. So to Joel's point, you know, move to worlds containers, serverless, DevOps, which was like, you know, aha, something that's happening on the side of an enterprise is not becoming mainstream. The business is demanding it. The, it is becoming the centerpiece in the business strategy. So that's been really like the aha. Big thing that's happening here. >>Yeah. And those architectures are coming together, aren't they? That's correct. Right. You know, VMs and containers, it used to be one architecture and then at the other end of the spectrum is serverless. People thought of those as different things and now it's a single architecture and, and it's kind of right approach for the right job. >>And, and a compliments say to Red Hat, they do an incredible job of hiding that complexity. Yeah. Yes. And making sure that, you know, for example, just like, make it easier for the developers to create value and then, and you know, >>Yeah, that's right. Those, they were previously siloed architectures and >>That's right. OpenShift wanna be place where you wanna run containers or virtual machines. We want that to be this Yeah. Single place. Not, not go bolt on another piece of architecture to just do one or the other. Yeah. >>And hey, the hybrid cloud vision is working for ibm. No question. You know, and it's achievable. Yeah. I mean, I just, I've said unlike, you know, some of the previous, you know, visions on fixing the world with ai, hybrid cloud is actually a real problem that you're attacking and it's showing the results. Agreed. Oh yeah. >>Great. Alright. Last question for you guys. Cause it might be kind of fun, 10 years from now, oh, we're at another, we're sitting here, we all look the same. Time has passed, but we are not aging, which is a part of the new technology that's come out in skincare. That's my, I'm just throwing that out there. Why not? What do you guys hope that you can say about the partnership and, and your continued commitment to community? >>Oh, that's a good question. You go first this time. Yeah. >>I think, you know, the, you know, for looking into the future, you need to look into the past. And Amazon has always been driven by working back from our customers. That's like our key tenant, principle number 1 0 1. >>Couple people have said that on this stage this week. Yeah. >>Yeah. And I think our partnership, I hope over the next decade continues to keep that tenant as a centerpiece. And then whatever comes out of that, I think we, we are gonna be, you know, working through that. >>Yeah. I, I would say this, I think you said that, well, the customer innovation is gonna lead us to wherever that is. And it's, it's, it's gonna be in the cloud for sure. I think we can say that in 10 years. But yeah, anything from, from AI to the quant quantum computing that IBM's really pushing behind that, you know, those are, those are gonna be things that hopefully we show up on a, on a partnership with Manu in 10 years, maybe sooner. >>Well, whatever happens next, we'll certainly be covering it here on the cube. That's right. Thank you both for being here. Joel Manu, fantastic interview. Thanks to see you guys. Yeah, good to see you brought the energy. I think you're definitely ranking high on the top interviews. We >>Love that for >>The day. >>Thank >>My pleasure >>Job, guys. Now that you're competitive at all, and thank you all for tuning in to our live coverage here from AWS Reinvent in Las Vegas, Nevada, with Dave Valante. I'm Savannah Peterson. You're watching The Cube, the leading source for high tech coverage.

(upbeat music) >> You got it, it's theCUBE. We are in Vegas. This is the Cube's live coverage day one of the full event coverage of AWS reInvent '22 from the Venetian Expo Center. Lisa Martin here with Dave Vellante. We love being in Vegas, Dave. >> Well, you know, this is where Super Cloud sort of was born. >> It is. >> Last year, just about a year ago. Steve Mullaney, CEO of of Aviatrix, you know, kind of helped us think it through. And we got some fun stories around. It's happening, but... >> It is happening. We're going to be talking about Super Cloud guys. >> I guess I just did the intro, Steve Mullaney >> You did my intro, don't do it again. >> Sorry I stole that from you, yeah. >> Steve Mullaney, joined just once again, one of our alumni. Steve, great to have you back on the program. >> Thanks for having me back. >> Dave: It's happening. >> It is happening. >> Dave: We talked about a year ago. Net Studio was right there. >> That was two years. Was that year ago, that was a year ago. >> Dave: It was last year. >> Yeah, I leaned over >> What's happening? >> so it's happening. It's happening. You know what, the thing I noticed what's happening now is the maturity of the cloud, right? So, if you think about this whole journey to cloud that has been, what, AWS 12 years. But really over the last few years is when enterprises have really kind of joined that journey. And three or four years ago, and this is why I came out of retirement and went to Aviatrix, was they all said, okay, now we're going to do cloud. You fast forward now three, four years from now, all of a sudden those five-year plans of evacuating the data center, they got one year left, two year left, and they're going, oh crap, we don't have five years anymore. We're, now the maturity's starting to say, we're starting to put more apps into the cloud. We're starting to put business critical apps like SAP into the cloud. This is not just like the low-hanging fruit anymore. So what's happening now is the business criticality, the scale, the maturity. And they're all now starting to hit a lot of limits that have been put into the CSPs that you never used to hit when you didn't have business critical and you didn't have that scale. They were always there. The rocks were always there. Just it was, you never hit 'em. People are starting to hit 'em now. So what's happening now is people are realizing, and I'm going to jump the gun, you asked me for my bumper sticker. The bumper sticker for Aviatrix is, "Good enough is no longer good enough." Now it's funny, it came in a keynote today, but what we see from our customers is it's time to upgrade the native constructs of networking and network security to be enterprise-grade now. It's no longer good enough to just use the native constructs because of a lack of visibility, the lack of controls, the lack of troubleshooting capabilities, all these things. "I now need enterprise grade networking." >> Let me ask you a question 'cause you got a good historical perspective on the industry. When you think about when Maritz was running VMWare. He was like any app, he said basically we're building a software mainframe. And they kind of did that, right? But then they, you know, hit the issue with scale, right? And they can't replicate the cloud. Are there things that we can draw from that experience and apply that to the cloud? What's the same, what's different? >> Oh yeah. So, 1992, do you remember what happened in 1992? I do this, weird German software company called SAP >> Yeah, R3. announced a release as R/3. Which was their first three-tier client-server application of SAP. Before that it ran on mainframes, TCP/IP. Remember that Protocol War? Guess what happened post-1992, everybody goes up like this. Infrastructure completely changes. Cisco, EMC, you name it, builds out these PCE client-server architectures. The WAN changes, MPLS, the campus, everything's home running back to that data center running SAP. That was the last 30 years ago. Great transformation of SAP. They've did it again. It's called S/4Hana. And now it's running and people are switching to S/4Hana and they're moving to the cloud. It's just starting. And that is going to alter how you build infrastructure. And so when you have that, being able to troubleshoot in hours versus minutes is a big deal. This is business critical, millions of dollars. This is not fun and games. So again, back to my, what was good enough for the last three or four years for enterprises no longer good enough, now I'm running business critical apps like SAP, and it's going to completely change infrastructure. That's happening in the cloud right now. And that's obviously a significant seismic shift, but what are some of the barriers that customers have been able to eliminate in order to get there? Or is it just good enough isn't good enough anymore? >> Barriers in terms of, well, I mean >> Lisa: The adoption. Yeah well, I mean, I think it's all the things that they go to cloud is, you know, the complexity, really, it's the agility, right? So the barrier that they have to get over is how do I keep the developer happy because the developer went to the cloud in the first place, why? Swipe the credit card because IT wasn't doing their job, 'cause every time I asked them for something, they said no. So I went around 'em. We need that. That's what they have to overcome in the move to the cloud. That is the obstacle is how do I deliver that visibility, that control, the enterprise, great functionality, but yet give the developer what they want. Because the minute I stop giving them that swipe the card operational model, what do you think they're going to do? They're going to go around me again and I can't, and the enterprise can't have that. >> That's a cultural shift. >> That's the main barrier they've got to overcome. >> Let me ask you another question. Is what we think of as mission critical, the definition changing? I mean, you mentioned SAP, obviously that's mission critical for operations, but you're also seeing new applications being developed in the cloud. >> I would say anything that's, I call business critical, same thing, but it's, business critical is internal to me, like SAP, but also anything customer-facing. That's business critical to me. If that app goes down or it has a problem, I'm not collecting revenue. So, you know, back 30 years ago, we didn't have a lot of customer-facing apps, right? It really was just SAP. I mean there wasn't a heck of a lot of cust- There were customer-facing things. But you didn't have all the digitalization that we have now, like the digital economy, where that's where the real explosion has come, is you think about all the customer-facing applications. And now every enterprise is what? A technology, digital company with a customer-facing and you're trying to get closer and closer to who? The consumer. >> Yeah, self-service. >> Self-service, B2C, everybody wants to do that. Get out of the middle man. And those are business critical applications for people. >> So what's needed under the covers to make all this happen? Give us a little double click on where you guys fit. >> You need consistent architecture. Obviously not just for one cloud, but for any cloud. But even within one cloud, forget multicloud, it gets worst with multicloud. You need a consistent architecture, right? That is automated, that is as code. I can't have the human involved. These are all, this is the API generation, you've got to be able to use automation, Terraform. And all the way from the application development platform you know, through Jenkins and all other software, through CICD pipeline and Terraform, when you, when that developer says, I want infrastructure, it has to go build that infrastructure in real time. And then when it says, I don't need it anymore it's got to take it away. And you cannot have a human involved in that process. That's what's completely changed. And that's what's giving the agility. And that's kind of a cloud model, right? Use software. >> Well, okay, so isn't that what serverless does, right? >> That's part of it. Absolutely. >> But I might still want control sometimes over the runtime if I'm running those mission critical applications. Everything in enterprise is a heterogeneous thing. It's like people, people say, well there's going to, the people going to repatriate back to on-prem, they are not repatriating back to on-prem. >> We were just talking about that, I'm like- >> Steve: It's not going to happen, right? >> It's a myth, it's a myth. >> And there's things that maybe shouldn't have ever gone into the cloud, I get that. Look, do people still have mainframes? Of course. There's certain things that you just, doesn't make sense to move to the new generation. There were things, certain applications that are very static, they weren't dynamic. You know what, keeping it on-prem it's, probably makes sense. So some of those things maybe will go back, but they never should have gone. But we are not repatriating ever, you know, that's not going to happen. >> No I agree. I mean, you know, there was an interesting paper by Andreessen, >> Yeah. >> But, I mean- >> Steve: Yeah it was a little self-serving for some company that need more funding, yeah. You look at the numbers. >> Steve: Yeah. >> It tells the story. It's just not happening. >> No. And the reason is, it's that agility, right? And so that's what people, I would say that what you need to do is, and in order to get that agility, you have to have that consistency. You have to have automation, you have to get these people out of the way. You have to use software, right? So it's that you have that swipe the card operational model for the developers. They don't want to hear the word no. >> Lisa: Right. >> What do you think is going to happen with AWS? Because we heard, I don't know if you heard Selipsky's keynote this morning, but you've probably heard the hallway talk. >> Steve: I did, yeah. >> Okay. You did. So, you know, connecting the dots, you know doubling down on all the primitives, that we expected. We kind of expected more of the higher level stuff, which really didn't see much of that, a little bit. >> Steve: Yeah. So, you know, there's a whole thing about, okay, does the cloud get commoditized? Does it not? I think the secret weapon's the ecosystem, right? Because they're able to sell through with guys like you. Make great margins on that. >> Steve: Yeah, well, yeah. >> What are your thoughts though on the future of AWS? >> IAS is going to get commoditized. So this is the fallacy that a lot of the CSPs have, is they thought that they were going to commoditize enterprise. It never happens that way. What's going to happen is infrastructure as a service, the lower level, which is why you see all the CSPs talking about what? Oracle Cloud, industry cloud. >> Well, sure, absolutely, yeah. >> We got to get to the apps, we got to get to SAP, we got to get to all that, because that's not going to get commoditized, right. But all the infrastructural service where AWS is king that is going to get commoditized, absolutely. >> Okay, so, but historically, you know Cisco's still got 60% plus gross margins. EMC always had good margin. How pure is the lone survivor in Flash? They got 70% gross margins. So infrastructure actually has always been a pretty good business. >> Yeah that's true. But it's a hell of a lot easier, particularly with people like Aviatrix and others that are building these common architectural things that create simplicity and abstract the way the complexities of underneath such that we allow your network to run an AWS, Azure, Google, Oracle, whatever, exactly the same. So it makes it a hell of a lot easier >> Dave: Super cloud. >> to go move. >> But I want to tap your brain because you have a good perspective of this because servers used to be a great margin business too on-prem and now it's not. It's a low margin business 'cause all the margin went to Intel. >> Yeah. But the cloud guys, you know, AWS in particular, makes a ton of dough on servers, so, or compute. So it's going to be interesting to see over time if that gets com- that's why they're going so hard after silicon. >> I think if they can, I think if you can capture the workload. So AWS and everyone else, as another example, this SAP, they call that a gravity workload. You know what gravity workload is? It's a black hole. It drags everything else with it. If you get SAP or Oracle or a mainframe app, it ain't going anywhere. And then what's going to happen is all your other apps are going to follow it. So that's what they're all going to fight for, is type of app. >> You said something earlier about, forget multicloud, for a moment, but, that idea of the super cloud, this abstraction layer, I mean, is that a real business value for customers other than, oh I got all these clouds, I need 'em to work together. You know, from your perspective from Aviatrix perspective, is it an opportunity for you to build on top of that? Or are you just looking at, look, I'm going to do really good work in AWS, in Azure? Now we're making the same experience. >> I hear this every single day from our customers is they look and they say, good enough isn't good enough. I've now hit the point, I'm hitting route limitations. I'm hitting, I'm doing things manually, and that's fine when I don't have that many applications or I don't have mission critical. The dogs are eating the dog food, we're going into the cloud and they're looking and then saying this is not an operational model for me. I've hit the point where I can't keep doing this, I can't throw bodies at this, I need software. And that's the opportunity for us, is they look and they say, I'm doing it in one cloud, but, and there's zero chance I'm going to be able to figure that out in the two or three other clouds. Every enterprise I talk to says multicloud is inevitable. Whether they're in it now, they all know they're going to go, because it's the business units that demand it. It's not the IT teams that demand it, it's the line of business that says, I like GCP for this reason. >> The driver's functionality that they're getting. >> It's the app teams that say, I have this service and GCP's better at it than AWS. >> Yeah, so it's not so much a cost game or the end all coffee mug, right? >> No, no. >> Google does this better than Microsoft, or better than- >> If you asked an IT person, they would rather not have multicloud. They actually tried to fight it. No, why would you want to support four clouds when you could support one right? That's insane. >> Dave and Lisa: Right. If they didn't have a choice and, and so it, the decision was made without them, and actually they weren't even notified until day before. They said, oh, good news, we're going to GCP tomorrow. Well, why wasn't I notified? Well, we're notifying you now. >> Yeah, you would've said, no. >> Steve: This is cloud bottle, let's go. >> Super cloud again. Did you see the Berkeley paper, sky computing I think they call it? Down at Berkeley, yep Dave Linthicum from Deloitte. He's talking about, I think he calls it meta cloud. It's happening. >> Yeah, yeah, yeah. >> It's happening. >> No, and because customers, customers want that. They... >> And talk about some customer example or two that you think really articulates the value of why it's happening and the outcomes that it's generating. >> I mean, I was just talking to Lamb Weston last night. So we had a reception, Lamb Weston, huge, frozen potatoes. They serve like, I dunno, some ungodly percentage of all the french fries to all the fast food. It's unbelievable what they do. Do you know, they have special chemicals they put on the french fries. So when you get your DoorDash, they stay crispy longer. They've invented that patented it. But anyway, it's all these businesses you've never heard of and they do all the, and again, they're moving to SAP or they're actually SAP in the cloud, they're one of the first ones. They did it through Accenture. They're pulling it back off from Accenture. They're not happy with the service they're getting. They're going to use us for their networking and network security because they're going to get that visibility and control back. And they're going to repatriate it back from a managed service and bring it back and run it in-house. And the SAP basis engineers want it to happen because they see the visibility and control that the infrastructure guy's going to get because of us, which leads to, all they care about is uptime and performance. That's it. And they're going to say the infrastructure team's going to lead to better uptime and better performance if it's running on Aviatrix. >> And business performance and uptime, business critical >> That is the business. That is the business. >> It is. So what are some of the things next coming down the pike from Aviatrix? Any secret sauce you can share? >> Lot of secrets. So, two secrets. One, the next thing people really want to do, embedded network security into the network. We've kind of talked about this. You're going to be seeing some things from us. Where does network security belong? In the network. Embedded in the fabric of the network, not as this dumb device called the next-gen firewall that you steer traffic to. It has to be into the fabric of what we do, what we call airspace. You're going to see us talk about that. And then the next thing, back to the maturity of the cloud, as they build out the core, guess what they're doing? It's this thing called edge, Dave, right? And guess what they're going to do? It's not about connecting the cloud to the edge to the cloud with dumb things like SD-WAN, right? Or SaaS. It's actually the other way around. Go into the cloud, turn around, look out at the edge and say, how do I extend the cloud out to the edge, and make it look like a VPC. That's what people are doing. Why, 'cause I want the operational model. I want all the things that I can do in the cloud out at the edge. And everyone knows it's been in networking. I've been in networking for 37 years. He who wins the core does what? Wins the edge, 'cause that's what happens. You do it first in the core and then you want one architecture, one common architecture, one consistent way of doing everything. And that's going to go out to the edge and it's going to look like a VPC from an operational model. >> And Amazon's going to support that, no doubt. >> Yeah, I mean every, you know, every, and then it's just how do you want to go do that? And us as the networking and network security provider, we're getting dragged to the edge by our customer. Because you're my networking provider. And that means, end to end. And they're trying to drag us into on-prem too, yeah. >> Lot's going on, you're going to have to come back- >> Because they want one networking vendor. >> But wait, and you say what? >> We will never do like switches and any of the keep Arista, the Cisco, and all that kind of stuff. But we will start sucking in net flow. We will start doing, from an operational perspective, we will integrate a lot of the things that are happening in on-prem into our- >> No halfway house. >> Copilot. >> No halfway house, no two architectures. But you'll take the data in. >> You want one architecture. >> Yeah. >> Yeah, totally. >> Right play. >> Amazing stuff. >> And he who wins the core, guess what's more strategic to them? What's more strategic on-prem or cloud? Cloud. >> It flipped three years ago. >> Dave: Yeah. >> So he who wins in the clouds going to win everywhere. >> Got it, We'll keep our eyes on that. >> Steve: Cause and effect. >> Thank you so much for joining us. We've got your bumper sticker already. It's been a great pleasure having you on the program. You got to come back, there's so, we've- >> You posting the bumper sticker somewhere? >> Lisa: It's going to be our Instagram. >> Oh really, okay. >> And an Instagram sto- This is new for you guys. Always coming up with new ideas. >> Raising the bar. >> It is, it is. >> Me advance, I mean, come on. >> I love it. >> All right, for our guest Steve Mullaney and Dave Vellante, I'm Lisa Martin. You're watching theCUBE, the leader in live enterprise and emerging tech coverage.