(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)

>> Narrator: From theCUBE Studios in Palo Alto and Boston bringing you data-driven insights from theCUBE and ETR. This is breaking analysis with Dave Vellante >> Enterprise tech practitioners, like most of us they want to make their lives easier so they can focus on delivering more value to their businesses. And to do so, they want to tap best of breed services in the public cloud, but at the same time connect their on-prem intellectual property to emerging applications which drive top line revenue and bottom line profits. But creating a consistent experience across clouds and on-prem estates has been an elusive capability for most organizations, forcing trade-offs and injecting friction into the system. The need to create seamless experiences is clear and the technology industry is starting to respond with platforms, architectures, and visions of what we've called the Supercloud. Hello and welcome to this week's Wikibon Cube Insights powered by ETR. In this breaking analysis we give you a preview of Supercloud 2, the second event of its kind that we've had on the topic. Yes, folks that's right Supercloud 2 is here. As of this recording, it's just about four days away 33 guests, 21 sessions, combining live discussions and fireside chats from theCUBE's Palo Alto Studio with prerecorded conversations on the future of cloud and data. You can register for free at supercloud.world. And we are super excited about the Supercloud 2 lineup of guests whereas Supercloud 22 in August, was all about refining the definition of Supercloud testing its technical feasibility and understanding various deployment models. Supercloud 2 features practitioners, technologists and analysts discussing what customers need with real-world examples of Supercloud and will expose thinking around a new breed of cross-cloud apps, data apps, if you will that change the way machines and humans interact with each other. Now the example we'd use if you think about applications today, say a CRM system, sales reps, what are they doing? They're entering data into opportunities they're choosing products they're importing contacts, et cetera. And sure the machine can then take all that data and spit out a forecast by rep, by region, by product, et cetera. But today's applications are largely about filling in forms and or codifying processes. In the future, the Supercloud community sees a new breed of applications emerging where data resides on different clouds, in different data storages, databases, Lakehouse, et cetera. And the machine uses AI to inspect the e-commerce system the inventory data, supply chain information and other systems, and puts together a plan without any human intervention whatsoever. Think about a system that orchestrates people, places and things like an Uber for business. So at Supercloud 2, you'll hear about this vision along with some of today's challenges facing practitioners. Zhamak Dehghani, the founder of Data Mesh is a headliner. Kit Colbert also is headlining. He laid out at the first Supercloud an initial architecture for what that's going to look like. That was last August. And he's going to present his most current thinking on the topic. Veronika Durgin of Sachs will be featured and talk about data sharing across clouds and you know what she needs in the future. One of the main highlights of Supercloud 2 is a dive into Walmart's Supercloud. Other featured practitioners include Western Union Ionis Pharmaceuticals, Warner Media. We've got deep, deep technology dives with folks like Bob Muglia, David Flynn Tristan Handy of DBT Labs, Nir Zuk, the founder of Palo Alto Networks focused on security. Thomas Hazel, who's going to talk about a new type of database for Supercloud. It's several analysts including Keith Townsend Maribel Lopez, George Gilbert, Sanjeev Mohan and so many more guests, we don't have time to list them all. They're all up on supercloud.world with a full agenda, so you can check that out. Now let's take a look at some of the things that we're exploring in more detail starting with the Walmart Cloud native platform, they call it WCNP. We definitely see this as a Supercloud and we dig into it with Jack Greenfield. He's the head of architecture at Walmart. Here's a quote from Jack. "WCNP is an implementation of Kubernetes for the Walmart ecosystem. We've taken Kubernetes off the shelf as open source." By the way, they do the same thing with OpenStack. "And we have integrated it with a number of foundational services that provide other aspects of our computational environment. Kubernetes off the shelf doesn't do everything." And so what Walmart chose to do, they took a do-it-yourself approach to build a Supercloud for a variety of reasons that Jack will explain, along with Walmart's so-called triplet architecture connecting on-prem, Azure and GCP. No surprise, there's no Amazon at Walmart for obvious reasons. And what they do is they create a common experience for devs across clouds. Jack is going to talk about how Walmart is evolving its Supercloud in the future. You don't want to miss that. Now, next, let's take a look at how Veronica Durgin of SAKS thinks about data sharing across clouds. Data sharing we think is a potential killer use case for Supercloud. In fact, let's hear it in Veronica's own words. Please play the clip. >> How do we talk to each other? And more importantly, how do we data share? You know, I work with data, you know this is what I do. So if you know I want to get data from a company that's using, say Google, how do we share it in a smooth way where it doesn't have to be this crazy I don't know, SFTP file moving? So that's where I think Supercloud comes to me in my mind, is like practical applications. How do we create that mesh, that network that we can easily share data with each other? >> Now data mesh is a possible architectural approach that will enable more facile data sharing and the monetization of data products. You'll hear Zhamak Dehghani live in studio talking about what standards are missing to make this vision a reality across the Supercloud. Now one of the other things that we're really excited about is digging deeper into the right approach for Supercloud adoption. And we're going to share a preview of a debate that's going on right now in the community. Bob Muglia, former CEO of Snowflake and Microsoft Exec was kind enough to spend some time looking at the community's supercloud definition and he felt that it needed to be simplified. So in near real time he came up with the following definition that we're showing here. I'll read it. "A Supercloud is a platform that provides programmatically consistent services hosted on heterogeneous cloud providers." So not only did Bob simplify the initial definition he's stressed that the Supercloud is a platform versus an architecture implying that the platform provider eg Snowflake, VMware, Databricks, Cohesity, et cetera is responsible for determining the architecture. Now interestingly in the shared Google doc that the working group uses to collaborate on the supercloud de definition, Dr. Nelu Mihai who is actually building a Supercloud responded as follows to Bob's assertion "We need to avoid creating many Supercloud platforms with their own architectures. If we do that, then we create other proprietary clouds on top of existing ones. We need to define an architecture of how Supercloud interfaces with all other clouds. What is the information model? What is the execution model and how users will interact with Supercloud?" What does this seemingly nuanced point tell us and why does it matter? Well, history suggests that de facto standards will emerge more quickly to resolve real world practitioner problems and catch on more quickly than consensus-based architectures and standards-based architectures. But in the long run, the ladder may serve customers better. So we'll be exploring this topic in more detail in Supercloud 2, and of course we'd love to hear what you think platform, architecture, both? Now one of the real technical gurus that we'll have in studio at Supercloud two is David Flynn. He's one of the people behind the the movement that enabled enterprise flash adoption, that craze. And he did that with Fusion IO and he is now working on a system to enable read write data access to any user in any application in any data center or on any cloud anywhere. So think of this company as a Supercloud enabler. Allow me to share an excerpt from a conversation David Flore and I had with David Flynn last year. He as well gave a lot of thought to the Supercloud definition and was really helpful with an opinionated point of view. He said something to us that was, we thought relevant. "What is the operating system for a decentralized cloud? The main two functions of an operating system or an operating environment are one the process scheduler and two, the file system. The strongest argument for supercloud is made when you go down to the platform layer and talk about it as an operating environment on which you can run all forms of applications." So a couple of implications here that will be exploring with David Flynn in studio. First we're inferring from his comment that he's in the platform camp where the platform owner is responsible for the architecture and there are obviously trade-offs there and benefits but we'll have to clarify that with him. And second, he's basically saying, you kill the concept the further you move up the stack. So the weak, the further you move the stack the weaker the supercloud argument becomes because it's just becoming SaaS. Now this is something we're going to explore to better understand is thinking on this, but also whether the existing notion of SaaS is changing and whether or not a new breed of Supercloud apps will emerge. Which brings us to this really interesting fellow that George Gilbert and I RIFed with ahead of Supercloud two. Tristan Handy, he's the founder and CEO of DBT Labs and he has a highly opinionated and technical mind. Here's what he said, "One of the things that we still don't know how to API-ify is concepts that live inside of your data warehouse inside of your data lake. These are core concepts that the business should be able to create applications around very easily. In fact, that's not the case because it involves a lot of data engineering pipeline and other work to make these available. So if you really want to make it easy to create these data experiences for users you need to have an ability to describe these metrics and then to turn them into APIs to make them accessible to application developers who have literally no idea how they're calculated behind the scenes and they don't need to." A lot of implications to this statement that will explore at Supercloud two versus Jamma Dani's data mesh comes into play here with her critique of hyper specialized data pipeline experts with little or no domain knowledge. Also the need for simplified self-service infrastructure which Kit Colbert is likely going to touch upon. Veronica Durgin of SAKS and her ideal state for data shearing along with Harveer Singh of Western Union. They got to deal with 200 locations around the world in data privacy issues, data sovereignty how do you share data safely? Same with Nick Taylor of Ionis Pharmaceutical. And not to blow your mind but Thomas Hazel and Bob Muglia deposit that to make data apps a reality across the Supercloud you have to rethink everything. You can't just let in memory databases and caching architectures take care of everything in a brute force manner. Rather you have to get down to really detailed levels even things like how data is laid out on disk, ie flash and think about rewriting applications for the Supercloud and the MLAI era. All of this and more at Supercloud two which wouldn't be complete without some data. So we pinged our friends from ETR Eric Bradley and Darren Bramberm to see if they had any data on Supercloud that we could tap. And so we're going to be analyzing a number of the players as well at Supercloud two. Now, many of you are familiar with this graphic here we show some of the players involved in delivering or enabling Supercloud-like capabilities. On the Y axis is spending momentum and on the horizontal accesses market presence or pervasiveness in the data. So netscore versus what they call overlap or end in the data. And the table insert shows how the dots are plotted now not to steal ETR's thunder but the first point is you really can't have supercloud without the hyperscale cloud platforms which is shown on this graphic. But the exciting aspect of Supercloud is the opportunity to build value on top of that hyperscale infrastructure. Snowflake here continues to show strong spending velocity as those Databricks, Hashi, Rubrik. VMware Tanzu, which we all put under the magnifying glass after the Broadcom announcements, is also showing momentum. Unfortunately due to a scheduling conflict we weren't able to get Red Hat on the program but they're clearly a player here. And we've put Cohesity and Veeam on the chart as well because backup is a likely use case across clouds and on-premises. And now one other call out that we drill down on at Supercloud two is CloudFlare, which actually uses the term supercloud maybe in a different way. They look at Supercloud really as you know, serverless on steroids. And so the data brains at ETR will have more to say on this topic at Supercloud two along with many others. Okay, so why should you attend Supercloud two? What's in it for me kind of thing? So first of all, if you're a practitioner and you want to understand what the possibilities are for doing cross-cloud services for monetizing data how your peers are doing data sharing, how some of your peers are actually building out a Supercloud you're going to get real world input from practitioners. If you're a technologist, you're trying to figure out various ways to solve problems around data, data sharing, cross-cloud service deployment there's going to be a number of deep technology experts that are going to share how they're doing it. We're also going to drill down with Walmart into a practical example of Supercloud with some other examples of how practitioners are dealing with cross-cloud complexity. Some of them, by the way, are kind of thrown up their hands and saying, Hey, we're going mono cloud. And we'll talk about the potential implications and dangers and risks of doing that. And also some of the benefits. You know, there's a question, right? Is Supercloud the same wine new bottle or is it truly something different that can drive substantive business value? So look, go to Supercloud.world it's January 17th at 9:00 AM Pacific. You can register for free and participate directly in the program. Okay, that's a wrap. I want to give a shout out to the Supercloud supporters. VMware has been a great partner as our anchor sponsor Chaos Search Proximo, and Alura as well. For contributing to the effort I want to thank Alex Myerson who's on production and manages the podcast. Ken Schiffman is his supporting cast as well. Kristen Martin and Cheryl Knight to help get the word out on social media and at our newsletters. And Rob Ho is our editor-in-chief over at Silicon Angle. Thank you all. Remember, these episodes are all available as podcast. Wherever you listen we really appreciate the support that you've given. We just saw some stats from from Buzz Sprout, we hit the top 25% we're almost at 400,000 downloads last year. So really appreciate your participation. All you got to do is search Breaking Analysis podcast and you'll find those I publish each week on wikibon.com and siliconangle.com. Or if you want to get ahold of me you can email me directly at David.Vellante@siliconangle.com or dm me DVellante or comment on our LinkedIn post. I want you to check out etr.ai. They've got the best survey data in the enterprise tech business. This is Dave Vellante for theCUBE Insights, powered by ETR. Thanks for watching. We'll see you next week at Supercloud two or next time on breaking analysis. (light music)

(gentle music) >> Now welcome back to theCUBE, everyone. I'm John Walls, and once again, we're glad to have you here for AWS re:Invent 22. Our coverage continues here on Thursday, day three, of what has been a jam-packed week of tech and AWS, of course, has been the great host for this. It's now a pleasure to welcome in Anurag Gupta, who is the founder and CEO of Shoreline, joining us here as part of the AWS Global Showcase Startup Program, and Anurag, good to see you, sir. Thanks for joining us. >> Thank you so much. >> Tell us about Shoreline, about what you're up to. >> So we're a DevOps company. We're really focused on repairing issues. If you think about it, there are a ton DevOps companies and we all went to the cloud in order to gain faster innovation and by and large check. Then all of the things involved in getting things into production, artifact generation, testing, configuration management, deployment, also by and large, automated. Now pity the poor SRE who's getting the deluge of stuff on them, every week, every two days, sometimes multiple times a day, and it's complicated, right? Kubernetes, VMs, lots of services, multiple clouds, sometimes, and you know, they need to know a little bit about everything. And you know what, there are a ton of companies that actually help you with what we call Day-2 Ops. It's just that most of them help you with observability, telling you what's gone wrong, or incident management, routing something to someone. But you know, back when I was at AWS, I never got really that excited about one more dashboard to look at or one more like better ticket routing. What used to really excite me was having some issue extinguished forever. And if you think about it, like the first five minutes of an incident are detecting and routing. The next hour, two hours, is some human being going in and fixing it, so that feels like the big opportunity to reduce, so hopefully we can talk a little bit about different ways that one can do that. >> What about Day-2 Ops? Just tell me about how you define that. >> So I basically define it as once the software goes into a production, just making sure things stay up and are healthy and you're resilient and you don't get errors and all of those sorts of things because everything breaks sooner or later, you know, to a greater or lesser degree. >> Especially that SRE you're talking about, right? >> Yeah. >> So let's go back to that scenario. Yeah, you pity the poor soul because they do have to be a little expert in everything. >> Exactly. >> And that's really challenging and we all know that, that's really hard. So how do you go about trying to lighten that burden, then? >> So when you look at the numbers, about somewhere between 40% to even 95% of the alarms that fire, the alerts that fire, are false positives and that's crazy. Why is someone waking up just to deal with? >> It's a lot of wasted time, isn't it? >> A lot of wasted time. And you know, you're also training someone into what I call ClickOps, just to go in and click the button and resolve it and you don't actually know if it was the false positive or it's the rare real positive, and so that's a challenge, right? And so the first thing to do is to figure out where the false positives are. Like, let's say Datadog tells you that CPU is high and alarms. Is that a good thing or a bad thing? It's hard for them to tell, right? But you have to then introspect it into something precise like, oh, CPU is high, but response times are standard and the request rate is high. Okay, that's a good thing. I'm going to ignore this. Or CPU is high, but it kind of resolves itself, so I'm going to not wake anybody up. Or CPU is high and oh, it's the darn JVM starting to garbage collect again, so let me go and take a heap dump and give that to my dev team and then bounce the JVM and you know, without waking anybody up, or CPU is high, I have no idea what's going on. Now it's time to wake somebody up. You know, what you want to use humans for is the ability to think about novel stuff, not to do repetitive stuff, so that's the first step. The second step is, about 40% of what remains is repetitive and straightforward. So like a disk is full, I'd better clean up the garbage on the disk or maybe grow the disk. People shouldn't wake up to deal to grow a disk. And so for that, what you want to do is just have those sorts of things get automated away. One of the nice things about Shoreline is, is that we take the experience in what we build for one company, and if they're willing, provide it to everybody else. Our belief is, a central tenant is, if someone somewhere fixes something, everyone everywhere should gain the benefit because we all sit on the same three clouds, we all sit on the same set of database infrastructure, et cetera. We should all get the same benefits. Why do we have to scar our own backs rather than benefiting from somebody else's scar tissue, so that's the second thing. The third thing is, okay, let's say it's not straightforward, not something I've seen before, then in that case, what often happens is on average like eight people get involved. You know, it initially goes to L1 support or L1 ops and, but they don't necessarily know because, as you say, the environment's complex. And so, you know, they go into Slack and they say, "At here, can somebody help me with this?" And those things take a much longer time, so wouldn't it be better that if your best SRE is able to say, "Hey, check these 20 things and then run these actions." We could convert that into like a Jupyter Notebook where you could say the incident got fired I pre-populated all the diagnostics, and then I tell people very precisely, "If you see this, run this, et cetera." Like a wiki, but actually something you could run right in this product. And then, you know, last piece of the puzzle, the smaller piece, is sometimes new things happen and when something new happens, what you want is sort of the central tech of Shoreline, which is parallel distributed, real-time debugging. And so the ability to do, you know, execute a command across your fleet rather than individual boxes so that you can say something like, "I'm hearing that my credit card app is slow. For everything tagged as being part of my credit card app, please run for everything that's running over 90% CPU, please run a top command." And so, you know, then you can run in the same time on one host as you can on 30,000 and that helps a lot. So that's the core of what we do. People use us for all sorts of things, also preventative maintenance, you know, just the proactive regular things. You know, like your car, you do an oil change, well, you know, you need to rotate your certs, certificates. You need to make sure that, you know, there isn't drift in your configurations, there isn't drift in your software. There's also security elements to it, right? You want to make sure that you aren't getting weird inbound/outbound traffic across to ports you don't expect to be open. You don't want to have these processes running, you know, maybe something's bad. And so that's all the kind of weird anomaly detection that's easy to do if you run things in a distributed parallel way across everything. That's super hard to do if you have to go and Whac-A-Mole across one box after the next. >> Well, which leads to a question just in terms of setting priorities then, which is what you're talking about helping companies establish priorities, this hierarchy of level one warning, level two, level three, level four. Sounds like that should be a basic, right? But you're saying that's not, that's not really happening in the enterprise. >> Well, you know, I would say that if you hadn't automated deployments, you should do that first. If you haven't automated your testing pipeline, shame on you, you should do that like a year ago. But now it's time to help people in production because you've done that other work and people are suffering. You know, the crazy thing about the cloud is, is that companies spend about three times more on the human beings to operate their cloud infrastructure as on the cloud infrastructure itself. I've yet to hear anybody say that their cloud bill is too low, you know, so, you know, there's a clearer savings also available. And you know, back when I was at AWS, obviously I had to keep the lights on too, but you know, I had to do that, but it's kind of a tax on my engineers and I'd really spend, prefer to spend the head count on innovation, on doing things that delight my customers. You never delight your customers by keeping the lights on, you just avoid irritating them by turning 'em off, right? >> So why are companies so fixed in on spending so much time on manually repairing things and not looking for these kinds of little, much more elegant solution and cost-efficient, time-saving, so on so forth. >> Yeah, I think there just hasn't been very much in this space as yet because it's a hard, hard problem to solve. You know, automation's a little bit scary and that's the reality of it and the way you make it less scary is by proving it out, by doing the simple things first, like reducing the alert fatigue, you know, that's easy. You know, providing notebooks to people so that they can click things and do things in a straightforward way. That's pretty easy. The full automation, that's kind of the North Star, that's what we aspire to do. But you know, people get there over time and one of our customers had 700 instances of this particular incident solved for them last week. You imagine how many human beings would've been doing it otherwise, you know? >> Right. >> That's just one thing, you know? >> How many did it take the build a pyramid? How many decades did that take, right? You had an announcement this week. I don't think we've talked about that. >> No, yeah, so we just announced Incident Insights, which is a free product that lets people plug into initially PagerDuty and pretty soon the Opsgenie ServiceNow, et cetera. And what you can do is, is you give us an API key read-only and we will suck your PagerDuty data out. We apply some lightweight ML unsupervised learning, and in a couple of minutes, we categorize all of your incidents so that you can understand which are the ones that happen most often and are getting resolved really quickly. That's ClickOps, right? Those alarms shouldn't fire. Which are the ones that involve a lot of people? Those are good candidates to build a notebook. Which are the ones that happen again and again and again? Those are good candidates for automation. And so, I think one of the challenges people have is, is that they don't actually know what their teams are doing and so this is intended to provide them that visibility. One of our very first customers was doing the beta test for us on it. He used to tell us he had about 100 tickets, incidents a week. You know, he brought this tool in and he had 2,100 last week and was all, you know, like these false alarms, so while he's giving us- >> That was eye opening for him to see that, sure. >> And why he's, you know, looking at it, you know, he's just like filing Jiras to say, "Oh, change this threshold, cancel this alarm forever." You know, all of that kind of stuff. Before you get to do the fancy work, you got to clean your room before you get to do anything else, right? >> Right, right, dinner before dessert, basically. >> There you go. >> Hey, thanks for the insights on this and again the name of the new product, by the way, is... >> Incident Insights. >> Incident Insights. >> Totally free. >> Free. >> Yeah, it takes a couple of minutes to set up. Go to the website, Shoreline.io/insight and you can be up and running in a couple of minutes. >> Outstanding, again, the company is Shoreline. This is Anurag Gupta, and thank you for being with us. We appreciate it. >> Appreciate it, thank you. >> Glad to have to here on theCUBE. Back with more from AWA re:Invent 22. You're watching theCUBE, the leader in high-tech coverage. (gentle music)

>>And welcome back to the Cube everyone. I'm John Walls to continue our coverage here of AWS Reinvent 22. We're part of the AWS Startup Showcase is the global startup program that AWS so proudly sponsors and with us to talk about what they're doing now in the AWS space. Shaun Knapps, the CEO of AS Send IO and Sean, good to have here with us. We appreciate >>It. Thanks for having me, >>John. Yeah, thanks for the time. First off, gotta show the t-shirt. You caught my attention. Big data is a cluster. I don't think you get a lot of argument from some folks, right? But it's your job to make some sense of it, is it not? Yeah. Tell us about a Send io. >>Sure. As Send IO is a data automation platform. What we do is connect a lot of the, the disparate parts of what data teams do when they create ETL and E o T data pipelines. And we use advanced levels of automation to make it easier and faster for them to build these complex systems and have their world be a little bit less of a, a cluster. >>All right. So let's get into automation a little bit then again, I, your definition of automation and how you're applying it to your business case. >>Absolutely. You know, what we see oftentimes is as spaces mature and evolve, the number of repetitive and repeatable tasks that actually become far less differentiating, but far more taxable if you will, right to the business, start to accumulate as those common patterns emerge. And, and, you know, as we see standardization around tech stacks, like on Amazon and on Snowflake and on data bricks, and as you see those patterns really start to, to formalize and standardize, it opens up the door to basically not have your team have to do all those things anymore and write code or perform the same actions that they used to always have to, and you can lean more on technology to properly automate and remove the, the monotony of those tasks and give your teams greater leverage. >>All right. So, so let's talk about at least maybe your, the journey, say in the past 18 months in terms of automation and, and what have you seen from a trend perspective and how are you trying to address that in order to, to meet that need? >>Yeah, I think the last 18 months have become, you know, really exciting as we've seen both that, you know, a very exciting boom and bust cycle that are driving a lot of other macro behaviors. You know, what we've seen over the last 18 months is far greater adoption of the, the standard, what we call the data planes, the, the architectures around snowflake and data bricks and, and Amazon. And what that's created as a result is the emergence of what I would call is the next problem. You know, as you start to solve that category of how >>You, that's it always works too, isn't >>It? Yeah, exactly. Always >>Works that >>This is the wonderful thing about technology is the job security. There's always the next problem to go solve. And that's what we see is, you know, as we we go into cloud, we get that infinite scale, infinite capacity, capacity, infinite flexibility. And you know, with these modern now data platforms, we get that infinite ability to store and process data incredibly quickly with incredible ease. And so what, what do most organizations do? You take a ton of new bodies, like all the people who wanted to do those like really cool things with data you're like, okay, now you can. And so you start throwing a lot more use cases, you start creating a lot more data products, you start doing a lot more things with data. And this is really where that third category starts to emerge, which is you get this data mess, not mesh, but the data mess. >>You get a cluster cluster, you get a cluster exactly where the complexity skyrockets. And as a result that that rapid innovation that, that you are all looking for and, and promised just comes to a screeching halt as you're just, just like trying to swim through molasses. And as a result, this is where that, that new awareness around automation starts really heightened. You know, we, we did a really interesting survey at the start of this year, did it as a blind survey, independent third party surveyed, 500 chief data officers, data scientists, data architects, and asked them a plethora of questions. But one of the questions we asked them was, do you currently or do you intend on investing in data automation to increase your team's productivity? And what was shocking, and I was very surprised by this, okay, what was shocking was only three and a half percent said they do today. Which is really interesting because it really hones in on this notion of automation is beyond what a lot of a think of, you know, tooling and enhancements today, only three and a half percent today had it, but 88.5% said they intend on making data automation investments in the next 12 months. And that stark contrast of how many people have a thing and how many people want that benefit of automation, right? I think it is incredibly critical as we look to 2023 and beyond. >>I mean, this seems like a no-brainer, does it not? I mean, know it is your business, of course you agree with me, but, but of course, of course what brilliant statement. But it is, it seems like, you know, the more you're, you're able to automate certain processes and then free up your resources and your dollars to be spent elsewhere and your, and your human capital, you know, to be invested elsewhere. That just seems to be a layup. I'm really, I'm very surprised by that three and a half percent figure >>I was too. I actually was expecting it to be higher. I was expecting five to 10%. Yeah. As there's other tools in the, the marketplace around ETL tools or orchestration tools that, that some would argue fit in the automation category. And I think the, what, what the market is telling us based on, on that research is that those themselves are, don't qualify as automation. That, that the market has a, a larger vision for automation. Something that is more metadata driven, more AI back, that takes us a greater leap and of leverage for the teams than than what the, the existing capabilities in the industry today can >>Afford. Okay. So if you got this big leap that you can make, but, but, but maybe, you know, should sites be set a little lower, are you, are you in danger of creating too much of an expectation or too much of a false hope? Because you know, I mean sometimes incremental increases are okay. I >>Agree. I I I think the, you know, I think you wanna do a little bit of both. I think you, you want to have a plan for, for reaching for the stars and you gotta be really pragmatic as well. Even inside of a a suni, we actually have a core value, which is build for 10 x plan for a hundred x and so know where you're going, right? But, but solve the problems that are right in front of you today as, as you get to that next scale. And I think the, the really important part for a lot of companies is how do you think about what that trajectory is and be really smart around where you choose to invest as you, one of the, the scenes that we have is last year's innovation is next year's anchor around your neck. And that's because we, we were in this very fortunately, so this really exciting, rapidly moving innovative space, but the thing that was your advantage not too long ago is everybody can move so quickly now becomes commonplace and a year or two later, if you don't jump on whatever that next innovation is that the industry start to standardize on, you're now on hook paying massive debt and, and paying, you know, you thought you had, you know, home mortgage debt and now you're paying the worst of credit card debt trying to pay that down and maintain your velocity. >>It's >>A whole different kind of fomo, right? I'm fair, miss, I'm gonna miss out. What am I missing out on? What the next big thing exactly been missing out >>On that? And so we encourage a lot of folks, you know, as you think about this as it pertains to automation too, is you solve for some of the problems right in front of you, but really make sure that you're, you're designing the right approach that as you stack on, you know, five times, 10 times as many people building data products and, and you, you're, you're your volume and library of, of data weaving throughout your, your business, make sure you're making those right investments. And that's one of the reasons why we do think automation is so important and, and really this, this next generation of automation, which is a, a metadata and AI back to level of automation that can just achieve and accomplish so much more than, than sort of traditional norms. >>Yeah. On that, like, as far as Dex Gen goes, what do you think is gonna be possible that cloud sets the stage for that maybe, you know, not too long ago seem really outta reach, like, like what's gonna give somebody to work on that 88% in there that's gonna make their spin come your way? >>Ah, good question. So I, I think there's a couple fold. I, you know, I think the, right now we see two things happening. You know, we see large movements going to the, the, the dominant data platforms today. And, and you know, frankly, one of the, the biggest challenges we see people having today is just how do you get data in which is insanity to me because that's not even the value extraction, that is the cost center piece of it. Just get data in so you can start to do something with it. And so I think that becomes a, a huge hurdle, but the access to new technologies, the ability to start to unify more of your data and, and in rapid fashion, I think is, is really important. I think as we start to, to invest more in this metadata backed layer that can connect that those notions of how do you ingest your data, how do you transform it, how do you orchestrate it, how do you observe it? One of the really compelling parts of this is metadata does become the new big data itself. And so to do these really advanced things to give these data teams greater levels of automation and leverage, we actually need cloud capabilities to process large volumes of not the data, but the metadata around the data itself to deliver on these really powerful capabilities. And so I think that's why the, this new world that we see of the, the developer platforms for modern data cloud applications actually benefit from being a cloud native application themselves. >>So before you take off, talk about the AWS relationship part of the startup showcase part of the growth program. And we've talked a lot about the cloud, what it's doing for your business, but let's just talk about again, how integral they have been to your success and, and likewise what you're thinking maybe you bring to their table too. Yeah, >>Well we bring a lot to the table. >>Absolutely. I had no doubt about that. >>I mean, honestly, it, working with with AWS has been truly fantastic. Yep. You know, I think, you know, as a, a startup that's really growing and expanding your footprint, having access to the resources in AWS to drive adoption, drive best practices, drive awareness is incredibly impactful. I think, you know, conversely too, the, the value that Ascend provides to the, the AWS ecosystem is tremendous leverage on onboarding and driving faster use cases, faster adoption of all the really great cool, exciting technologies that we get to hear about by bringing more advanced layers of automation to the existing product stack, we can make it easier for more people to build more powerful things faster and safely. Which I think is what most businesses at reinvent really are looking for. >>It's win-win, win-win. Yeah. That's for sure. Sean, thanks for the time. Thank you John. Good job on the t-shirt and keep up the good work. Thank you very much. I appreciate that. Sean Na, joining us here on the AWS startup program, part of their of the Startup Showcase. We are of course on the Cube, I'm John Walls. We're at the Venetian in Las Vegas, and the cube, as you well know, is the leader in high tech coverage.

>>Okay, we're back. I'm Dave Valante with The Cube and you're watching Evolving Influx DB into the smart data platform made possible by influx data. Anna East Otis Georgio is here. She's a developer advocate for influx data and we're gonna dig into the rationale and value contribution behind several open source technologies that Influx DB is leveraging to increase the granularity of time series analysis analysis and bring the world of data into realtime analytics. Anna is welcome to the program. Thanks for coming on. >>Hi, thank you so much. It's a pleasure to be here. >>Oh, you're very welcome. Okay, so IO X is being touted as this next gen open source core for Influx db. And my understanding is that it leverages in memory, of course for speed. It's a kilo store, so it gives you compression efficiency, it's gonna give you faster query speeds, it gonna use store files and object storages. So you got very cost effective approach. Are these the salient points on the platform? I know there are probably dozens of other features, but what are the high level value points that people should understand? >>Sure, that's a great question. So some of the main requirements that IOCs is trying to achieve and some of the most impressive ones to me, the first one is that it aims to have no limits on cardinality and also allow you to write any kind of event data that you want, whether that's lift tag or a field. It also wants to deliver the best in class performance on analytics queries. In addition to our already well served metrics queries, we also wanna have operator control over memory usage. So you should be able to define how much memory is used for buffering caching and query processing. Some other really important parts is the ability to have bulk data export and import, super useful. Also, broader ecosystem compatibility where possible we aim to use and embrace emerging standards in the data analytics ecosystem and have compatibility with things like sql, Python, and maybe even pandas in the future. >>Okay, so a lot there. Now we talked to Brian about how you're using Rust and and which is not a new programming language and of course we had some drama around Russ during the pandemic with the Mozilla layoffs, but the formation of the Russ Foundation really addressed any of those concerns. You got big guns like Amazon and Google and Microsoft throwing their collective weights behind it. It's really, adoption is really starting to get steep on the S-curve. So lots of platforms, lots of adoption with rust, but why rust as an alternative to say c plus plus for example? >>Sure, that's a great question. So Rust was chosen because of his exceptional performance and rebi reliability. So while rust is synt tactically similar to c c plus plus and it has similar performance, it also compiles to a native code like c plus plus. But unlike c plus plus, it also has much better memory safety. So memory safety is protection against bugs or security vulnerabilities that lead to excessive memory usage or memory leaks. And rust achieves this memory safety due to its like innovative type system. Additionally, it doesn't allow for dangling pointers and dangling pointers are the main classes of errors that lead to exploitable security vulnerabilities in languages like c plus plus. So Russ like helps meet that requirement of having no limits on card for example, because it's, we're also using the Russ implementation of Apache Arrow and this control over memory and also Russ, Russ Russ's packaging system called crates IO offers everything that you need out of the box to have features like AY and a weight to fixed race conditions to protect against buffering overflows and to ensure thread safe ay caching structures as well. So essentially it's just like has all the control, all the fine grain control, you need to take advantage of memory and all your resources as well as possible so that you can handle those really, really high ity use cases. >>Yeah, and the more I learned about the the new engine and the, and the platform IOCs et cetera, you know, you, you see things like, you know, the old days not even to even today you do a lot of garbage collection in these, in these systems and there's an inverse, you know, impact relative to performance. So it looks like you're really, you know, the community is modernizing the platform, but I wanna talk about Apache Arrow for a moment. It's designed to address the constraints that are associated with analyzing large data sets. We, we know that, but please explain why, what, what is Arrow and and what does it bring to Influx db? >>Sure, yeah. So Arrow is a, a framework for defining in memory calmer data and so much of the efficiency and performance of IOCs comes from taking advantage of calmer data structures. And I will, if you don't mind, take a moment to kind of illustrate why calmer data structures are so valuable. Let's pretend that we are gathering field data about the temperature in our room and also maybe the temperature of our stove. And in our table we have those two temperature values as well as maybe a measurement value, timestamp value, maybe some other tag values that describe what room and what house, et cetera we're getting this data from. And so you can picture this table where we have like two rows with the two temperature values for both our room and the stove. Well usually our room temperature is regulated so those values don't change very often. >>So when you have calm oriented st calm oriented storage, essentially you take each row, each column and group it together. And so if that's the case and you're just taking temperature values from the room and a lot of those temperature values are the same, then you'll, you might be able to imagine how equal values will then neighbor each other and when they neighbor each other in the storage format. This provides a really perfect opportunity for cheap compression. And then this cheap compression enables high cardinality use cases. It also enables for faster scan rates. So if you wanna define like the min and max value of the temperature in the room across a thousand different points, you only have to get those a thousand different points in order to answer that question and you have those immediately available to you. But let's contrast this with a row oriented storage solution instead so that we can understand better the benefits of calmer oriented storage. >>So if you had a row oriented storage, you'd first have to look at every field like the temperature in, in the room and the temperature of the stove. You'd have to go across every tag value that maybe describes where the room is located or what model the stove is. And every timestamp you'd then have to pluck out that one temperature value that you want at that one times stamp and do that for every single row. So you're scanning across a ton more data and that's why row oriented doesn't provide the same efficiency as calmer and Apache Arrow is in memory calmer data, calmer data fit framework. So that's where a lot of the advantages come >>From. Okay. So you've basically described like a traditional database, a row approach, but I've seen like a lot of traditional databases say, okay, now we've got, we can handle colo format versus what you're talking about is really, you know, kind of native it, is it not as effective as the, is the form not as effective because it's largely a, a bolt on? Can you, can you like elucidate on that front? >>Yeah, it's, it's not as effective because you have more expensive compression and because you can't scan across the values as quickly. And so those are, that's pretty much the main reasons why, why RO row oriented storage isn't as efficient as calm, calmer oriented storage. >>Yeah. Got it. So let's talk about Arrow data fusion. What is data fusion? I know it's written in rust, but what does it bring to to the table here? >>Sure. So it's an extensible query execution framework and it uses Arrow as its in memory format. So the way that it helps influx DB IOx is that okay, it's great if you can write unlimited amount of cardinality into influx cbis, but if you don't have a query engine that can successfully query that data, then I don't know how much value it is for you. So data fusion helps enable the, the query process and transformation of that data. It also has a PANDAS API so that you could take advantage of PDA's data frames as well and all of the machine learning tools associated with pandas. >>Okay. You're also leveraging par K in the platform course. We heard a lot about Par K in the middle of the last decade cuz as a storage format to improve on Hadoop column stores. What are you doing with Par K and why is it important? >>Sure. So Par K is the calm oriented durable file format. So it's important because it'll enable bulk import and bulk export. It has compatibility with Python and pandas so it supports a broader ecosystem. Parque files also take very little disc disc space and they're faster to scan because again they're column oriented in particular, I think PAR K files are like 16 times cheaper than CSV files, just as kind of a point of reference. And so that's essentially a lot of the, the benefits of par k. >>Got it. Very popular. So and these, what exactly is influx data focusing on as a committer to these projects? What is your focus? What's the value that you're bringing to the community? >>Sure. So Influx DB first has contributed a lot of different, different things to the Apache ecosystem. For example, they contribute an implementation of Apache Arrow and go and that will support clearing with flux. Also, there has been a quite a few contributions to data fusion for things like memory optimization and supportive additional SQL features like support for timestamp, arithmetic and support for exist clauses and support for memory control. So yeah, Influx has contributed a a lot to the Apache ecosystem and continues to do so. And I think kind of the idea here is that if you can improve these upstream projects and then the long term strategy here is that the more you contribute and build those up, then the more you will perpetuate that cycle of improvement and the more we will invest in our own project as well. So it's just that kind of symbiotic relationship and appreciation of the open source community. >>Yeah. Got it. You got that virtuous cycle going, the people call it the flywheel. Give us your last thoughts and kind of summarize, you know, where what, what the big takeaways are from your perspective. >>So I think the big takeaway is that influx data is doing a lot of really exciting things with Influx DB IOCs and I really encourage if you are interested in learning more about the technologies that Influx is leveraging to produce IOCs, the challenges associated with it and all of the hard work questions and I just wanna learn more, then I would encourage you to go to the monthly tech talks and community office hours and they are on every second Wednesday of the month at 8:30 AM Pacific time. There's also a community forums and a community Slack channel. Look for the influx D DB underscore IAC channel specifically to learn more about how to join those office hours and those monthly tech tech talks as well as ask any questions they have about IOCs, what to expect and what you'd like to learn more about. I as a developer advocate, I wanna answer your questions. So if there's a particular technology or stack that you wanna dive deeper into and want more explanation about how influx TB leverages it to build IOCs, I will be really excited to produce content on that topic for you. >>Yeah, that's awesome. You guys have a really rich community, collaborate with your peers, solve problems, and you guys super responsive, so really appreciate that. All right, thank you so much and East for explaining all this open source stuff to the audience and why it's important to the future of data. >>Thank you. I really appreciate it. >>All right, you're very welcome. Okay, stay right there and in a moment I'll be back with Tim Yokum. He's the director of engineering for Influx Data and we're gonna talk about how you update a SaaS engine while the plane is flying at 30,000 feet. You don't wanna miss this.

>>How y'all doing? My name's Savannah Peterson, coming to you from Detroit, Michigan, where the cube is excited to be at Cube Con. Our guest this afternoon is a wonderfully brilliant woman who's been leading in the space for over eight years. Please welcome Gar Kapur. Gar, thanks for being with us. >>Well, thank you for having me to, It's a pleasure. Good >>To see you. So, update what's going on here? Co saw you at VMware Explorer. Yes. Welcome back to the Cube. Yes. What's, what's going on for you guys here? What's the message? What's the story >>Soupcon like I always say, it's our event, it's our audience. So, you know, Minayo, I dunno if you've been keeping track, Mani ha did reach like a billion docker downloads recently. So >>Congratulations. >>This is your tribe right here. Yes, >>It is. It is. Our >>Tribe's native infrastructure. Come on. Yes. >>You know, this audience understands us. We understand them. You know, you were asking when did we start the company? So we started in 2014, and if you see, Kubernetes was born in 2015 in all sorts of ways. So we kind of literally grew up together along with the Kubernetes journey. So all the decisions that we took were just, you know, making sure that we addressed the Kubernetes and the cloud native audiences, the first class citizens when it comes to storage. So I think that has been very instrumental in leading us up to the point where we have reached a billion docker downloads and we are the most loved object storage out >>There. So, So do you like your younger brother Kubernetes? Or not? Is this is It's a family that gets along. >>It does get along. I think in, in Kubernetes space, what we are seeing from customer standpoint as well, right? They're warming up to Kubernetes and you know, they are using Kubernetes as a framework to deploy anything at scale. And especially when you're, you know, offering storage as a service to your, whether it is for your internal audience or to the external audience, Kubernetes becomes extremely instrumental because it makes Multitenancy extremely easy. It makes, you know, access control points extremely easy for different user sets and so on. Yeah. So Kubernetes is definitely the way to go. I think enterprises need to just have little bit more skill set when it comes to Kubernetes overall, because I think there are still little bit areas in which they need to invest in, but I think this is the right direction, This is the right way. If you, if you want multi-tenant, you need Kubernetes for compute, you need Kubernetes for storage. So >>You guys hit an interesting spot here with Kubernetes. You have a product that targets builders. Yes. But also it's a service that's consumed. >>Yes. Yes. >>How do you see those two lanes shaping out as the world starts to grow, the ecosystems growing, You've got products for builders and products for people who are developers consuming services. How do you see that shaking out? Is just, is there intersections there? There is. You seem to be hitting that. >>There is. There is definitely an intersection. And I think it's getting merged because a lot of these users are the ones who dictate what kind of stack they want as part of their application ecosystem overall, right? So that is where, when an application, for example, in the big data workloads, right? They tell their IT or their storage department, this is the S3 compatible storage that they want their applications to run on or sit on. So the bridges definitely like becoming very narrow in that way from builders versus the service consumers overall. And I think, you know, at the end of the day, people need to get their job done from application users perspective. They want to just get in and get out. They don't want to deal with the underlying complexity when it comes to storage or any of the framework, right? So I think what we enable is for the builders to make sure they have extremely easy, simple, high performance software service that they can offer it to their customers, which is as three compatible. So now they can take their applications wherever they need to go, whether it is edge, whether it is on-prem, whether it is any of the public cloud, wherever you need to be, go be with it. With >>Mei, I mean, I wanna get your thoughts on a really big trend that's happening now. That's right. In your area of expertise. That is people are realizing that, hey, I don't necessarily need AWS S3 for storage. I gotta do my own storage or build my own. So there's a cost slash value for commodity storage. Yes. When does a company just dive to what to do there? Do they do their own? You see, CloudFlare, you seeing Wasabi, other companies? Yes. Merging. You guys are here. Yeah, yeah. Common services then there's a differentiator in the cloud. What's the, what's this all about? >>Yeah, so there are a couple of things going on in this space, right? So firstly, I think cloud model is the way to go. And what, what we mean by cloud is not public cloud, it's the cloud operating model overall, right? You need to build the applications the correct way so that they can consume cloud native infrastructure correctly. So I think that is what is going on. And secondly, I think cloud is great for your burst workloads. It's all about productivity. It's all about getting your applications to the market as fast as you can. And that is where of course, MIN IO comes into play when you know you can develop your applications natively on something like mania. And when, when you take it to production, it's very easy no matter where you go. And thirdly, I think when it comes to the cost perspective, you know, what we offer to the customers is predictability of the cost and no surprise in the builds when it comes, which is extremely important to like a CFO of a company because everyone knows that cloud is not the cheapest place to run your sustainable workloads. And there is unpredictability element involved because, you know, people leave their buckets on, people leave their compute nodes on it, it happens all the time. So I think if you take that uncertainty out of it and have more predictability around it, I think that is, that is where the true value lies. >>You're really hitting on a theme that we've been hearing a lot on the cube today, which is standardization, predictability. Yes. We, everyone always wants to move fast, but I think we're actually stepping away from that Mark Zuckerberg parity, move fast and break things and let's move fast, but know how much it's gonna cost and also decrease the complexity. Drugs >>Don't things. >>Yeah, yeah, yeah, exactly. And try, you know, minimize the collateral damage when Yeah. I, I love that you're enabling folks like that. How is, I'm curious because I see that your background, you have a PhD in philosophy, so we don't always see philosophy and DevOps and Kubernetes in the same conversation. Yeah. So how does this translate into your leadership within your team and the, And Min i's culture, >>So it's PhD in financial management and financial economics. So that is where my specialization lies. And I think after that I came to Bay Area. So once you're in Bay Area, you cannot escape technology. It is >>To you, >>It is just the way things are. You cannot escape startups, you cannot escape technology overall. So that's how I got introduced to it. And yeah, that it has been a great journey so far. And from the culture standpoint of view, you know, I always tell like if I can learn technology, anyone can learn technology. So what we look for is the right attitude, the right kind of, you know, passion to learn is what is most important in this world if you want to succeed. And that's what I tell everyone who joins the, who joins win I, two months, three months, you'll be up and going. I, I'm not too worried about it. >>But pet pedigree doesn't always play into it because no, the changing technology you could level up. So for sure you get into those and be contributing. >>I think one of the reasons why we have been successful the way we have been successful with storage is because we've not hired storage experts. Because they come with their own legacy and mindset of how to build things. And we are like, and we always came from a point of view, we are not a storage company. We are a data company and we want to be close to the data. So when you come to that mindset, you build a product directly attacking data, not just like, you know, in traditional appliance world and so on, so forth. So I think those things have been very instrumental in terms of getting the right people on board, making sure that they're very aligned with how we do things and you know, the dnf, the company's, >>That's for passion and that's actually counterintuitive, but it's makes sense. Yes. In new markets it doesn't always seem to take the boiler plate. Yes. Skill set or person. No, we're doing journalism, but we don't hire journalists. No, >>I mean you gotta be, It's adventurers. It is. It's curious. >>Exactly. Exactly. Yeah, I, yeah, I think also, you know, for you to disrupt any space, you cannot approach it from how they approach the problem. You need to completely turn the tables upside down as they say, right? You need to disrupt it and have the surprise element. And I think that is what always makes a technology very special. You cannot follow the path that others have followed. You need to come from a different space, different mindset altogether. So that is where it's important that you, like you said, adventurous are the people >>That that is for sure. Talk to us about the company. Are you growing scaling? How do people find out more? >>Oh yeah, for sure. So people can find out more by visiting our website. Min dot i, we are growing. We just closed last year, end of last year we closed our CDC round unicorn valuation and so on, so forth. So >>She says unicorn valuation, so casually, I just wanna point that out, that, that, that, that's funny. Like a true strong female leader. I love that. I >>Love that. Thank you. Yes. So in terms of, you know, in terms of growth and scalability, we are growing the team. We are, you know, onboarding more commercial customers to the platform. So yeah, it's growth all across growth from the community standpoint, growth from commercial number standpoint. So congratulations. Yeah, thank you. >>Yeah, that's very exciting. Grma, thank you so much for being, >>Being with us. Thank you for >>Having me. Always. Thanks for hanging out and to all of you, thank you so much for tuning into the Cube, especially for this exciting edition for all of us here in Detroit, Michigan, where we're coming to you from Cuban. See you back here in a little bit.

>>Hello everyone. My name is Savannah Peterson, coming to you live from the Kim Con Show floor on the cube here in Detroit, Michigan. The energy is pulsing big event for the Cloud Native Foundation, and I'm joined by John Furrier on my left. John. Hello. >>Great, great, great to have you on the cube. Thanks for being our new host. You look great, Great segment coming up. I'm looking forward to this. Savannah, this is a great segment. A cube alumni, an OG in the cloud, native world or cloud aati. I, as I call it, been there, done that. A lot of respect, a lot of doing some really amazing, I call it the super cloud holy grail. But we'll see >>Your favorite word, >>This favorite word, It's a really strong segment. Looking forward to hearing from this guest. >>Yes, I am very excited and I'm gonna let him tee it up a little bit. But our guest and his project were actually mentioned in the opening keynote this morning, which is very, very exciting. Ladies and gentlemen, please welcome Baam Tobar Baam, thanks for being here with >>Us. Thank you guys. So good to be back here on the show and, and this exciting energy around us. So it was super, super awesome to be here. >>Yeah, it feels great. So let's start with the opening keynote. Did you know you were gonna get that shout out? >>No, not at all. I, it was, it was really cool to see, you know, I think Cruz was up there talking about how they were building their own platform for autonomous cars and what's running behind it. And they mentioned all these projects and you know, we were like, Wow, that sounds super familiar. And then, then, and then they said, Okay, yeah, we we're, you know, cross plane. They mentioned cross plane, they mentioned, Upbound mentioned the work that we're doing in this space to help folks effectively run, you know, their own layer on top of cloud computing. >>And then Tom, we've known each other, >>We're gonna do a bingo super cloud. So how many times is this Super cloud? So >>Super Cloud is super services, super apps around us. He enables a lot of great things that Brian Grace had a great podcast this week on super services. So it's super, super exciting, >>Super great time on the queue. Super, >>Super >>Cloud conversation. All seriously. Now we've known each other for a long time. You've been to every cub com, you've been in open source, you've seen the seen where it's been, where it is now. Super exciting that in mainstream conversations we're talking about super cloud extractions and around interoperability. Things that were once like really hard to do back, even back on the opens stack days. Now we're at a primetime spot where the control plane, the data planes are in play as a viable architectural component of all the biggest conversations. Yeah, you're in the middle of it. What's your take on it? Give some perspective of why this is so important. >>I mean, look, the key here is to standardize, right? Get to standardization, right? And, and what we saw, like early days of cloud native, it was mostly around Kubernetes, but it was Kubernetes as a, you know, essentially a container orchestrator, the container of wars, Docker, Mesos, et cetera. And then Kubernetes emerged as a, a, the winner in containers, right? But containers is a workload, one kind of workload. It's, I run containers on it, not everything's containers, right? And the, you know, what we're seeing now is the Kubernetes API is emerging as a way to standardize on literally everything in cloud. Not just containers, but you know, VMs, serverless, Lambda, et cetera, storage databases that all using a common approach, a common API layer, a common way to do access control, a common way to do policy, all built around open source projects and you know, the cloud data of ecosystem that you were seeing around here. And that's exciting cuz we've, for the first time we're arriving at some kind of standardization. >>Every major inflection point has this defacto standard evolution, then it becomes kind of commonplace. Great. I agree with Kubernetes. The question I wanted to ask you is what's the impact to the DevOps community? DevSecOps absolutely dominated the playbook, if you will. Developers we're saying we'll run companies cuz they'll be running the applications. It's not a department anymore. Yes, it is the business. If you believe the digital transformation finds its final conclusion, which it will at some point. So more developers doing more, ask more stuff. >>Look, if you, I'd be hard pressed to find somebody that's has a title of DevOps or SRE that can't at least spell Kubernetes, if not running in production, right? And so from that perspective, I think this is a welcome change. Standardize on something that's already familiar to everyone is actually really powerful. They don't have to go, Okay, we learned Kubernetes, now you guys are taking us down a different path of standardization. Or something else has emerged. It's the same thing. It's like we have what, eight years now of cloud native roughly. And, and people in the DevOps space welcome a change where they are basically standardizing on things that are working right? They're actually working right? And they could be used in more use cases, in more scenarios than they're actually, you know, become versatile. They become, you know, ubiquitous as >>You will take a minute to just explain what you guys are selling and doing. What's the product, what's the traction, why are people using you? What's the big, big mo position value statement you guys think? >>Yeah, so, so, so the, my company's called Upbound and where the, where the folks behind the, the cross plane project and cross plane is effective, takes Kubernetes and extends it to beyond containers and to ev managing everything in cloud, right? So if you think about that, if you love the model where you're like, I, I go to Kubernetes cluster and I tell it to run a bunch of containers and it does it for me and I walk away, you can do that for the rest of the surface area of cloud, including your VMs and your storage and across cloud vendors, hybrid models, All of it works in a consistent standardized way, you know, using crossline, right? And I found >>What do you solve? What do you solve or eliminate? What happens? Why does this work? Are you replacing something? Are you extracting away something? Are you changing >>Something? I think we're layering on top of things that people have, right? So, so you'll see people are organized differently. We see a common pattern now where there's shared services teams or platform teams as you hear within enterprises that are responsible for basically managing infrastructure and offering a self-service experience to developers, right? Those teams are all about standardization. They're all about creating things that help them reduce the toil, manage things in a common way, and then offer self-service abstractions to their, you know, developers and customers. So they don't have to be in the middle of every request. Things can go faster. We're seeing a pattern now where the, these teams are standardizing on the Kubernetes API or standardizing on cross plane and standardizing on things that make their life easier, right? They don't have to replace what they're doing, they just have to layer and use it. And I layer it's probably a, an opening for you that makes it sound >>More complex, I think, than what you're actually trying to do. I mean, you as a company are all about velocity as an ethos, which I think is great. Do you think that standardization is the key in increasing velocity for teams leveraging both cross claim, Kubernetes? Anyone here? >>Look, I mean, everybody's trying to achieve the same thing. Everybody wants to go faster, they want to innovate faster. They don't want tech to be the friction to innovation, right? Right. They want, they wanna go from feature to production in minutes, right? And so, or less to that extent, standardization is a way to achieve that. It's not the only way to achieve that. It's, it's means to achieve that. And if you've standardized, that means that less people are involved. You can automate more, you can st you can centralize. And by doing that, that means you can innovate faster. And if you don't innovate these days, you're in trouble. Yeah. You're outta business. >>Do you think that, so Kubernetes has a bit of a reputation for complexity. You're obviously creating a tool that makes things easier as you apply Kubernetes outside just an orchestration and container environment. Do you, what do you see those advantages being across the spectrum of tools that people are leveraging you >>For? Yeah, I mean, look, if Kubernetes is a platform, right? To build other things on top of, and as a, as a result, it's something that's used to kind of on the back end. Like you would never, you should put something in front of Kubernetes as an application model or consumption interface of portals or Right, Yeah. To give zero teams. But you should still capture all your policies, you know, automation and compliance governance at the Kubernetes layer, right? At the, or with cross plane at that layer as well, right? Right. And so if you follow that model, you can get the best of world both worlds. You standardize, you centralize, you are able to have, you know, common controls and policies and everything else, but you can expose something that's a dev friendly experience on top of as well. So you get the both, both the best of both worlds. >>So the problem with infrastructure is code you're saying is, is that it's not this new layer to go across environments. Does that? No, >>Infrastructure is code works slightly differently. I mean, you, you can, you can write, you know, infrastructures, codes using whatever tooling you like to go across environments. The problem with is that everybody has to learn a specific language or has to work with understanding the constructs. There's the beauty of the Kubernetes based approach and the cross playing best approach is that it puts APIs first, right? It's basically saying, look, kind of like the API meant that it, that led to AWS being created, right? Teams should interact with APIs. They're super strong contracts, right? They're visionable. Yeah. And if you, if you do that and that's kind of the power of this approach, then you can actually reach a really high level of automation and a really high level of >>Innovation. And this also just not to bring in the clouds here, but this might bring up the idea that common services create interoperability, but yet the hyper scale clouds could still differentiate on value very much faster processors if it's silicon to better functions if glam, right? I mean, so there's still, it's not killing innovation. >>It is not, And in fact I, you know, this idea of building something that looks like the lowest common denominator across clouds, we don't actually see that in practice, right? People want, people want to use the best services available to them because they don't have time to go, you know, build portability layers and everything else. But they still, even in that model want to standardize on how to call these services, how to set policy on them, how to set access control, how to actually invoke them. If you can standardize on that, you can still, you get the, you get to use these services and you get the benefits of standardization. >>Well Savannah, we were talking about this, about the Berkeley paper that came out in May, which is kind of a super cloud version they call sky computing. Their argument is that if you try to standardize too much like the old kind of OSI model back in the day, you actually gonna, the work innovations gonna stunt the growth. Do you agree with that? And how do you see, because standardization is not so much a spec and it it, it e f thing. It's not an i e committee. Yeah. It's not like that's kind of standard. It's more of defacto, >>I mean look, we've had standards emerge like, you know, if you look at my S SQL for example, and the Postgres movement, like there are now lots of vendors that offer interfaces that support Postgres even though they're differentiated completely on how it's implement. So you see that if you can stick to open interfaces and use services that offer them that tons of differentiation yet still, you know, some kind of open interface if you will. But there are also differentiated services that are, don't have open interfaces and that's okay too. As long as you're able to kind of find a way to manage them in a consistent way. I think you sh and it makes sense to your business, you should use >>Them. So enterprises like this and just not to get into the business model side real quick, but like how you guys making money? You got the project, you get the cross playing project, that's community. You guys charging what's, what's the business model? >>We we're in the business of helping people adopt and run controlled lanes that do all this management service managed service services and customer support and services, the, the plethora of things that people need where we're >>Keeping the project while >>Keeping the project. >>Correct. So that's >>The key. That's correct. Yeah. You have to balance both >>And you're all over the show. I mean, outside of the keynote mention looking here, you have four events on where can people find you if they're tuning in. We're just at the beginning and there's a lot of looks here. >>Upbound at IO is the place to find Upbound and where I have a lot of talks, you'll see Crossline mention and lots of talks and a number of talks today. We have a happy hour later today we've got a booth set up. So >>I'll be there folks. Just fyi >>And everyone will be there now. Yeah. Quick update. What's up? What's new with the cross plane project? Can you share a little commercial? What's the most important stories going on there? >>So cross plane is growing obviously, and we're seeing a ton of adoption of cross plane, especially actually in large enterprise, which is really exciting cuz they're usually the slow to move and cross plane is so central, so it's now in hundreds and thousands of deployments in woohoo, which is amazing to see. And so the, the project itself is adding a ton of features, reducing friction in terms of adoption, how people ride these control planes and alter them coverage of the space. As you know, controls are only useful when you connect them to things. And the space is like the amount of things you can connect control planes to is increasing on a day to day basis and the maturity is increasing. So it's just super exciting to see all of this right >>Now. How would you categorize the landscape? We were just talking earlier in another segment, we're in Detroit Motor City, you know, it's like teaching someone how to drive a car. Kubernetes pluss, okay, switch the gears like, you know, don't hit the other guy. You know? Now once you learn how to drive, they want a sports car. How do you keep them that progression going? How do you keep people to grow continuously? Where do you see the DevOps and or folks that are doing cross playing that are API hardcore? Cause that's a good IQ that shows 'em that they're advancing. Where's the IQ level of advancement relative to the industry? Is the adoption just like, you know, getting going? Are people advancing? Yeah. Sounds like your customers are heavily down the road on >>Yeah, the way I would describe it is there's a progression happening, right? It, it DevOps was make, initially it was like how do I keep things running right? And it transitioned to how do I automate things so that I don't have to be involved when things are running, running. Right now we're seeing a next turn, which is how do I build what looks like a product that offers shared services or a platform so that people consume it like a product, right? Yeah. And now I'm now transition becomes, well I'm an, I'm a developer on a product in operations building something that looks like a product and thinking about it as a, as a has a user interface. >>Ops of the new devs. >>That's correct. Yeah. There we go. >>Talk about layers. Talk about layers on layers on >>Layers. It's not confusing at all John. >>Well, you know, when they have the architecture architectural list product that's coming. Yeah. But this is what's, I mean the Debs are got so much DevOps in the front and the C I C D pipeline, the ops teams are now retrofitting themselves to be data and security mainly. And that's just guardrails, automation policy, seeing a lot of that kind of network. Like exactly. >>Function. >>Yep. And they're, they're composing, not maybe coding a little bit, but they not, they're not >>Very much. They're in the composition, you know that as a daily thing. They're, they're writing compositions, they're building things, they're putting them together and making them work. >>How new is this in your mind? Cause you, you've watching this progress, you're in the middle of it, you're in the front wave of this. Is it adopting faster now than ever before? I mean, if we talked five years ago, we were kind of saying this might happen, but it wasn't happening today. It kind, it is, >>It's kind of, it's kind of amazing. Like, like everybody's writing these cloud services now. Everybody's authoring things that look like API services that do things on top of the structure. That move is very much, has a ton of momentum right now and it's happening mainstream. It, it's becoming mainstream. >>Speaking of momentum, but some I saw both on your LinkedIn as well as on your badge today that you are hiring. This is your opportunity to shamelessly plug. What are you looking for? What can people expect in terms of your company culture? >>Yeah, so we're obviously hiring, we're hiring both on the go to market side or we're hiring on the product and engineering side. If you want to build, well a new cloud platform, I won't say the word super cloud again, but if you want to, if you're excited about building a cloud platform that literally sits on top of, you know, the other cloud platforms and offers services on top of this, come talk to us. We're building something amazing. >>You're creating a super cloud tool kit. I'll say it >>On that note, think John Farer has now managed to get seven uses of the word super cloud into this broadcast. We sawm tomorrow. Thank you so much for joining us today. It's been a pleasure. I can't wait to see more of you throughout the course of Cuban. My name is Savannah Peterson, everyone, and thank you so much for joining us here on the Cube where we'll be live from Detroit, Michigan all week.

(inspirational music) >> The history of high performance computing is unique and storied. You know, it's generally accepted that the first true supercomputer was shipped in the mid 1960s by Controlled Data Corporations, CDC, designed by an engineering team led by Seymour Cray, the father of Supercomputing. He left CDC in the 70's to start his own company, of course, carrying his own name. Now that company Cray, became the market leader in the 70's and the 80's, and then the decade of the 80's saw attempts to bring new designs, such as massively parallel systems, to reach new heights of performance and efficiency. Supercomputing design was one of the most challenging fields, and a number of really brilliant engineers became kind of quasi-famous in their little industry. In addition to Cray himself, Steve Chen, who worked for Cray, then went out to start his own companies. Danny Hillis, of Thinking Machines. Steve Frank of Kendall Square Research. Steve Wallach tried to build a mini supercomputer at Convex. These new entrants, they all failed, for the most part because the market at the time just wasn't really large enough and the economics of these systems really weren't that attractive. Now, the late 80's and the 90's saw big Japanese companies like NEC and Fujitsu entering the fray and governments around the world began to invest heavily in these systems to solve societal problems and make their nations more competitive. And as we entered the 21st century, we saw the coming of petascale computing, with China actually cracking the top 100 list of high performance computing. And today, we're now entering the exascale era, with systems that can complete a billion, billion calculations per second, or 10 to the 18th power. Astounding. And today, the high performance computing market generates north of $30 billion annually and is growing in the high single digits. Supercomputers solve the world's hardest problems in things like simulation, life sciences, weather, energy exploration, aerospace, astronomy, automotive industries, and many other high value examples. And supercomputers are expensive. You know, the highest performing supercomputers used to cost tens of millions of dollars, maybe $30 million. And we've seen that steadily rise to over $200 million. And today we're even seeing systems that cost more than half a billion dollars, even into the low billions when you include all the surrounding data center infrastructure and cooling required. The US, China, Japan, and EU countries, as well as the UK, are all investing heavily to keep their countries competitive, and no price seems to be too high. Now, there are five mega trends going on in HPC today, in addition to this massive rising cost that we just talked about. One, systems are becoming more distributed and less monolithic. The second is the power of these systems is increasing dramatically, both in terms of processor performance and energy consumption. The x86 today dominates processor shipments, it's going to probably continue to do so. Power has some presence, but ARM is growing very rapidly. Nvidia with GPUs is becoming a major player with AI coming in, we'll talk about that in a minute. And both the EU and China are developing their own processors. We're seeing massive densities with hundreds of thousands of cores that are being liquid-cooled with novel phase change technology. The third big trend is AI, which of course is still in the early stages, but it's being combined with ever larger and massive, massive data sets to attack new problems and accelerate research in dozens of industries. Now, the fourth big trend, HPC in the cloud reached critical mass at the end of the last decade. And all of the major hyperscalers are providing HPE, HPC as a service capability. Now finally, quantum computing is often talked about and predicted to become more stable by the end of the decade and crack new dimensions in computing. The EU has even announced a hybrid QC, with the goal of having a stable system in the second half of this decade, most likely around 2027, 2028. Welcome to theCUBE's preview of SC22, the big supercomputing show which takes place the week of November 13th in Dallas. theCUBE is going to be there. Dave Nicholson will be one of the co-hosts and joins me now to talk about trends in HPC and what to look for at the show. Dave, welcome, good to see you. >> Hey, good to see you too, Dave. >> Oh, you heard my narrative up front Dave. You got a technical background, CTO chops, what did I miss? What are the major trends that you're seeing? >> I don't think you really- You didn't miss anything, I think it's just a question of double-clicking on some of the things that you brought up. You know, if you look back historically, supercomputing was sort of relegated to things like weather prediction and nuclear weapons modeling. And these systems would live in places like Lawrence Livermore Labs or Los Alamos. Today, that requirement for cutting edge, leading edge, highest performing supercompute technology is bleeding into the enterprise, driven by AI and ML, artificial intelligence and machine learning. So when we think about the conversations we're going to have and the coverage we're going to do of the SC22 event, a lot of it is going to be looking under the covers and seeing what kind of architectural things contribute to these capabilities moving forward, and asking a whole bunch of questions. >> Yeah, so there's this sort of theory that the world is moving toward this connectivity beyond compute-centricity to connectivity-centric. We've talked about that, you and I, in the past. Is that a factor in the HPC world? How is it impacting, you know, supercomputing design? >> Well, so if you're designing an island that is, you know, tip of this spear, doesn't have to offer any level of interoperability or compatibility with anything else in the compute world, then connectivity is important simply from a speeds and feeds perspective. You know, lowest latency connectivity between nodes and things like that. But as we sort of democratize supercomputing, to a degree, as it moves from solely the purview of academia into truly ubiquitous architecture leverage by enterprises, you start asking the question, "Hey, wouldn't it be kind of cool if we could have this hooked up into our ethernet networks?" And so, that's a whole interesting subject to explore because with things like RDMA over converged ethernet, you now have the ability to have these supercomputing capabilities directly accessible by enterprise computing. So that level of detail, opening up the box of looking at the Nix, or the storage cards that are in the box, is actually critically important. And as an old-school hardware knuckle-dragger myself, I am super excited to see what the cutting edge holds right now. >> Yeah, when you look at the SC22 website, I mean, they're covering all kinds of different areas. They got, you know, parallel clustered systems, AI, storage, you know, servers, system software, application software, security. I mean, wireless HPC is no longer this niche. It really touches virtually every industry, and most industries anyway, and is really driving new advancements in society and research, solving some of the world's hardest problems. So what are some of the topics that you want to cover at SC22? >> Well, I kind of, I touched on some of them. I really want to ask people questions about this idea of HPC moving from just academia into the enterprise. And the question of, does that mean that there are architectural concerns that people have that might not be the same as the concerns that someone in academia or in a lab environment would have? And by the way, just like, little historical context, I can't help it. I just went through the upgrade from iPhone 12 to iPhone 14. This has got one terabyte of storage in it. One terabyte of storage. In 1997, I helped build a one terabyte NAS system that a government defense contractor purchased for almost $2 million. $2 million! This was, I don't even know, it was $9.99 a month extra on my cell phone bill. We had a team of seven people who were going to manage that one terabyte of storage. So, similarly, when we talk about just where are we from a supercompute resource perspective, if you consider it historically, it's absolutely insane. I'm going to be asking people about, of course, what's going on today, but also the near future. You know, what can we expect? What is the sort of singularity that needs to occur where natural language processing across all of the world's languages exists in a perfect way? You know, do we have the compute power now? What's the interface between software and hardware? But really, this is going to be an opportunity that is a little bit unique in terms of the things that we typically cover, because this is a lot about cracking open the box, the server box, and looking at what's inside and carefully considering all of the components. >> You know, Dave, I'm looking at the exhibitor floor. It's like, everybody is here. NASA, Microsoft, IBM, Dell, Intel, HPE, AWS, all the hyperscale guys, Weka IO, Pure Storage, companies I've never heard of. It's just, hundreds and hundreds of exhibitors, Nvidia, Oracle, Penguin Solutions, I mean, just on and on and on. Google, of course, has a presence there, theCUBE has a major presence. We got a 20 x 20 booth. So, it's really, as I say, to your point, HPC is going mainstream. You know, I think a lot of times, we think of HPC supercomputing as this just sort of, off in the eclectic, far off corner, but it really, when you think about big data, when you think about AI, a lot of the advancements that occur in HPC will trickle through and go mainstream in commercial environments. And I suspect that's why there are so many companies here that are really relevant to the commercial market as well. >> Yeah, this is like the Formula 1 of computing. So if you're a Motorsports nerd, you know that F1 is the pinnacle of the sport. SC22, this is where everybody wants to be. Another little historical reference that comes to mind, there was a time in, I think, the early 2000's when Unisys partnered with Intel and Microsoft to come up with, I think it was the ES7000, which was supposed to be the mainframe, the sort of Intel mainframe. It was an early attempt to use... And I don't say this in a derogatory way, commodity resources to create something really, really powerful. Here we are 20 years later, and we are absolutely smack in the middle of that. You mentioned the focus on x86 architecture, but all of the other components that the silicon manufacturers bring to bear, companies like Broadcom, Nvidia, et al, they're all contributing components to this mix in addition to, of course, the microprocessor folks like AMD and Intel and others. So yeah, this is big-time nerd fest. Lots of academics will still be there. The supercomputing.org, this loose affiliation that's been running these SC events for years. They have a major focus, major hooks into academia. They're bringing in legit computer scientists to this event. This is all cutting edge stuff. >> Yeah. So like you said, it's going to be kind of, a lot of techies there, very technical computing, of course, audience. At the same time, we expect that there's going to be a fair amount, as they say, of crossover. And so, I'm excited to see what the coverage looks like. Yourself, John Furrier, Savannah, I think even Paul Gillin is going to attend the show, because I believe we're going to be there three days. So, you know, we're doing a lot of editorial. Dell is an anchor sponsor, so we really appreciate them providing funding so we can have this community event and bring people on. So, if you are interested- >> Dave, Dave, I just have- Just something on that point. I think that's indicative of where this world is moving when you have Dell so directly involved in something like this, it's an indication that this is moving out of just the realm of academia and moving in the direction of enterprise. Because as we know, they tend to ruthlessly drive down the cost of things. And so I think that's an interesting indication right there. >> Yeah, as do the cloud guys. So again, this is mainstream. So if you're interested, if you got something interesting to talk about, if you have market research, you're an analyst, you're an influencer in this community, you've got technical chops, maybe you've got an interesting startup, you can contact David, david.nicholson@siliconangle.com. John Furrier is john@siliconangle.com. david.vellante@siliconangle.com. I'd be happy to listen to your pitch and see if we can fit you onto the program. So, really excited. It's the week of November 13th. I think November 13th is a Sunday, so I believe David will be broadcasting Tuesday, Wednesday, Thursday. Really excited. Give you the last word here, Dave. >> No, I just, I'm not embarrassed to admit that I'm really, really excited about this. It's cutting edge stuff and I'm really going to be exploring this question of where does it fit in the world of AI and ML? I think that's really going to be the center of what I'm really seeking to understand when I'm there. >> All right, Dave Nicholson. Thanks for your time. theCUBE at SC22. Don't miss it. Go to thecube.net, go to siliconangle.com for all the news. This is Dave Vellante for theCUBE and for Dave Nicholson. Thanks for watching. And we'll see you in Dallas. (inquisitive music)

(upbeat music) >> Okay, we're back. I'm Dave Vellante with The Cube and you're watching Evolving InfluxDB into the smart data platform made possible by influx data. Anais Dotis-Georgiou is here. She's a developer advocate for influx data and we're going to dig into the rationale and value contribution behind several open source technologies that InfluxDB is leveraging to increase the granularity of time series analysis and bring the world of data into realtime analytics. Anais welcome to the program. Thanks for coming on. >> Hi, thank you so much. It's a pleasure to be here. >> Oh, you're very welcome. Okay, so IOx is being touted as this next gen open source core for InfluxDB. And my understanding is that it leverages in memory, of course for speed. It's a kilometer store, so it gives you compression efficiency it's going to give you faster query speeds, it's going to see you store files and object storages so you got very cost effective approach. Are these the salient points on the platform? I know there are probably dozens of other features but what are the high level value points that people should understand? >> Sure, that's a great question. So some of the main requirements that IOx is trying to achieve and some of the most impressive ones to me the first one is that it aims to have no limits on cardinality and also allow you to write any kind of event data that you want whether that's lift tag or a field. It also wants to deliver the best in class performance on analytics queries. In addition to our already well served metric queries we also want to have operator control over memory usage. So you should be able to define how much memory is used for buffering caching and query processing. Some other really important parts is the ability to have bulk data export and import, super useful. Also, broader ecosystem compatibility where possible we aim to use and embrace emerging standards in the data analytics ecosystem and have compatibility with things like SQL, Python and maybe even Pandas in the future. >> Okay, so a lot there. Now we talked to Brian about how you're using Rust and which is not a new programming language and of course we had some drama around Rust during the pandemic with the Mozilla layoffs but the formation of the Rust Foundation really addressed any of those concerns and you got big guns like Amazon and Google and Microsoft throwing their collective weights behind it. It's really adoption is really starting to get steep on the S-curve. So lots of platforms, lots of adoption with Rust but why Rust as an alternative to say C++ for example? >> Sure, that's a great question. So Rust was chosen because of his exceptional performance and reliability. So while Rust is syntactically similar to C++ and it has similar performance it also compiles to a native code like C++ But unlike C++ it also has much better memory safety. So memory safety is protection against bugs or security vulnerabilities that lead to excessive memory usage or memory leaks. And Rust achieves this memory safety due to its like innovative type system. Additionally, it doesn't allow for dangling pointers and dangling pointers are the main classes of errors that lead to exploitable security vulnerabilities in languages like C++. So Rust like helps meet that requirement of having no limits on cardinality, for example, because it's we're also using the Rust implementation of Apache Arrow and this control over memory and also Rust's packaging system called Crates IO offers everything that you need out of the box to have features like async and await to fix race conditions to protect against buffering overflows and to ensure thread safe async caching structures as well. So essentially it's just like has all the control all the fine grain control, you need to take advantage of memory and all your resources as well as possible so that you can handle those really, really high cardinality use cases. >> Yeah, and the more I learn about the new engine and the platform IOx et cetera, you see things like the old days not even to even today you do a lot of garbage collection in these systems and there's an inverse, impact relative to performance. So it looks like you're really, the community is modernizing the platform but I want to talk about Apache Arrow for a moment. It's designed to address the constraints that are associated with analyzing large data sets. We know that, but please explain why, what is Arrow and what does it bring to InfluxDB? >> Sure. Yeah. So Arrow is a a framework for defining in memory column data. And so much of the efficiency and performance of IOx comes from taking advantage of column data structures. And I will, if you don't mind, take a moment to kind of illustrate why column data structures are so valuable. Let's pretend that we are gathering field data about the temperature in our room and also maybe the temperature of our store. And in our table we have those two temperature values as well as maybe a measurement value, timestamp value maybe some other tag values that describe what room and what house, et cetera we're getting this data from. And so you can picture this table where we have like two rows with the two temperature values for both our room and the store. Well, usually our room temperature is regulated so those values don't change very often. So when you have calm oriented storage essentially you take each row each column and group it together. And so if that's the case and you're just taking temperature values from the room and a lot of those temperature values are the same then you'll, you might be able to imagine how equal values will then enable each other and when they neighbor each other in the storage format this provides a really perfect opportunity for cheap compression. And then this cheap compression enables high cardinality use cases. It also enables for faster scan rates. So if you want to define like the min and max value of the temperature in the room across a thousand different points you only have to get those a thousand different points in order to answer that question and you have those immediately available to you. But let's contrast this with a row oriented storage solution instead so that we can understand better the benefits of column oriented storage. So if you had a row oriented storage, you'd first have to look at every field like the temperature in the room and the temperature of the store. You'd have to go across every tag value that maybe describes where the room is located or what model the store is. And every timestamp you then have to pluck out that one temperature value that you want at that one time stamp and do that for every single row. So you're scanning across a ton more data and that's why row oriented doesn't provide the same efficiency as column and Apache Arrow is in memory column data column data fit framework. So that's where a lot of the advantages come from. >> Okay. So you've basically described like a traditional database a row approach, but I've seen like a lot of traditional databases say, okay, now we've got we can handle Column format versus what you're talking about is really kind of native is it not as effective as the former not as effective because it's largely a bolt on? Can you like elucidate on that front? >> Yeah, it's not as effective because you have more expensive compression and because you can't scan across the values as quickly. And so those are, that's pretty much the main reasons why row oriented storage isn't as efficient as column oriented storage. >> Yeah. Got it. So let's talk about Arrow data fusion. What is data fusion? I know it's written in Rust but what does it bring to to the table here? >> Sure. So it's an extensible query execution framework and it uses Arrow as its in memory format. So the way that it helps InfluxDB IOx is that okay it's great if you can write unlimited amount of cardinality into InfluxDB, but if you don't have a query engine that can successfully query that data then I don't know how much value it is for you. So data fusion helps enable the query process and transformation of that data. It also has a Pandas API so that you could take advantage of Pandas data frames as well and all of the machine learning tools associated with Pandas. >> Okay. You're also leveraging Par-K in the platform course. We heard a lot about Par-K in the middle of the last decade cuz as a storage format to improve on Hadoop column stores. What are you doing with Par-K and why is it important? >> Sure. So Par-K is the column oriented durable file format. So it's important because it'll enable bulk import and bulk export. It has compatibility with Python and Pandas so it supports a broader ecosystem. Par-K files also take very little disc space and they're faster to scan because again they're column oriented, in particular I think Par-K files are like 16 times cheaper than CSV files, just as kind of a point of reference. And so that's essentially a lot of the benefits of Par-K. >> Got it. Very popular. So and these, what exactly is Influx data focusing on as a committer to these projects? What is your focus? What's the value that you're bringing to the community? >> Sure. So InfluxDB first has contributed a lot of different things to the Apache ecosystem. For example, they contribute an implementation of Apache Arrow and go and that will support clearing Influx. Also, there has been a quite a few contributions to data fusion for things like memory optimization and supportive additional SQL features like support for timestamp, arithmetic and support for exist clauses and support for memory control. So yeah, Influx has contributed a lot to the Apache ecosystem and continues to do so. And I think kind of the idea here is that if you can improve these upstream projects and then the long term strategy here is that the more you contribute and build those up then the more you will perpetuate that cycle of improvement and the more we will invest in our own project as well. So it's just that kind of symbiotic relationship and appreciation of the open source community. >> Yeah. Got it. You got that virtuous cycle going people call it the flywheel. Give us your last thoughts and kind of summarize, what the big takeaways are from your perspective. >> So I think the big takeaway is that, Influx data is doing a lot of really exciting things with InfluxDB IOx and I really encourage if you are interested in learning more about the technologies that Influx is leveraging to produce IOx the challenges associated with it and all of the hard work questions and I just want to learn more then I would encourage you to go to the monthly Tech talks and community office hours and they are on every second Wednesday of the month at 8:30 AM Pacific time. There's also a community forums and a community Slack channel. Look for the InfluxDB underscore IOx channel specifically to learn more about how to join those office hours and those monthly tech talks as well as ask any questions they have about IOx what to expect and what you'd like to learn more about. I as a developer advocate, I want to answer your questions. So if there's a particular technology or stack that you want to dive deeper into and want more explanation about how InfluxDB leverages it to build IOx, I will be really excited to produce content on that topic for you. >> Yeah, that's awesome. You guys have a really rich community collaborate with your peers, solve problems and you guys super responsive, so really appreciate that. All right, thank you so much Anais for explaining all this open source stuff to the audience and why it's important to the future of data. >> Thank you. I really appreciate it. >> All right, you're very welcome. Okay, stay right there and in a moment I'll be back with Tim Yoakam. He's the director of engineering for Influx Data and we're going to talk about how you update a SaaS engine while the plane is flying at 30,000 feet. You don't want to miss this. (upbeat music)

>> From every ISV to solve the problems. You want there to be tools in place that you can use, either open source tools or whatever it is that help you build it. And slowly over time, that building will become easier and easier. So my question to you was, where do you see you playing? Do you see yourself playing to ISVs as a set of tools, which will make their life a lot easier and provide that work? >> Absolutely. >> If they don't have, so they don't have to do it. Or you're providing this for the end users? Or both? >> So it's a progression. If you go to the ISVs first, you're doomed to starved before you have time for that other option. >> Yeah. >> Right? So it's a question of phase, the phasing of it. And also if you go directly to end users, you can demonstrate the power of it and get the attention of the ISVs. I believe that the ISVs, especially those with the biggest footprints and the most, you know, coveted estates, they have already made massive investments at trying to solve decentralization of their software stack. And I believe that they have used it as a hook to try to move to a software as a service model and rope people into leasing their infrastructure. So if you look at the clouds that have been propped up by Autodesk or by Adobe, or you name the company, they are building proprietary makeshift solutions for decentralizing or hybrid clouding. Or maybe they're not even doing that at all and all they're is saying hey, if you want to get location agnosticness, then what you should just, is just move into our cloud. >> Right. >> And then they try to solve on the background how to decentralize it between different regions so they can have decent offerings in each region. But those who are more advanced have already made larger investments and will be more averse to, you know, throwing that stuff away, all of their makeshift machinery away, and using a platform that gives them high performance parallel, low level file system access, while at the same time having metadata-driven, you know, policy-based, intent-based orchestration to manage the diffusion of data across a decentralized infrastructure. They are not going to be as open because they've made such an investment and they're going to look at how do they monetize it. So what we have found with like the movie studios who are using us already, many of the app they're using, many of those software offerings, the ISVs have their own cloud that offers that software for the cloud. But what we got when I asked about this, 'cause I was dealt specifically into this question because I'm very interested to know how we're going to make that leap from end user upstream into the ISVs where I believe we need to, and they said, look, we cannot use these software ISV-specific SAS clouds for two reasons. Number one is we lose control of the data. We're giving it to them. That's security and other issues. And here you're talking about we're doing work for Disney, we're doing work for Netflix, and they're not going to let us put our data on those software clouds, on those SAS clouds. Secondly, in any reasonable pipeline, the data is shared by many different applications. We need to be agnostic as to the application. 'Cause the inputs to one application, you know, the output for one application provides the input to the next, and it's not necessarily from the same vendor. So they need to have a data platform that lets them, you know, go from one software stack, and you know, to run it on another. Because they might do the rendering with this and yet, they do the editing with that, and you know, et cetera, et cetera. So I think the further you go up the stack in the structured data and dedicated applications for specific functions in specific verticals, the further up the stack you go, the harder it is to justify a SAS offering where you're basically telling the end users you need to park all your data with us and then you can run your application in our cloud and get this. That ultimately is a dead end path versus having the data be open and available to many applications across this supercloud layer. >> Okay, so-- >> Is that making any sense? >> Yes, so if I could just ask a clarifying question. So, if I had to take Snowflake as an example, I think they're doing exactly what you're saying is a dead end, put everything into our proprietary system and then we'll figure out how to distribute it. >> Yeah. >> And and I think if you're familiar with Zhamak Dehghaniis' data mesh concept. Are you? >> A little bit, yeah. >> But in her model, Snowflake, a Snowflake warehouse is just a node on the mesh and that mesh is-- >> That's right. >> Ultimately the supercloud and you're an enabler of that is what I'm hearing. >> That's right. What they're doing up at the structured level and what they're talking about at the structured level we're doing at the underlying, unstructured level, which by the way has implications for how you implement those distributed database things. In other words, implementing a Snowflake on top of Hammerspace would have made building stuff like in the first place easier. It would allow you to easily shift and run the database engine anywhere. You still have to solve how to shard and distribute at the transaction layer above, so I'm not saying we're a substitute for what you need to do at the app layer. By the way, there is another example of that and that's Microsoft Office, right? It's one thing to share that, to have a file share where you can share all the docs. It's something else to have Word and PowerPoint, Excel know how to allow people to be simultaneously editing the same doc. That's always going to happen in the app layer. But not all applications need that level of, you know, in-app decentralization. You know, many of them, many workflows are pipelined, especially the ones that are very data intensive where you're doing drug discovery or you're doing rendering, or you're doing machine learning training. These things are human in the loop with large stages of processing across tens of thousands of cores. And I think that kind of data processing pipeline is what we're focusing on first. Not so much the Microsoft Office or the Snowflake, you know, parking a relational database because that takes a lot of application layer stuff and that's what they're good at. >> Right. >> But I think... >> Go ahead, sorry. >> Later entrance in these markets will find Hammerspace as a way to accelerate their work so they can focus more narrowly on just the stuff that's app-specific, higher level sharing in the app. >> Yes, Snowflake founders-- >> I think it might be worth mentioning also, just keep this confidential guys, but one of our customers is Blue Origin. And one of the things that we have found is kind of the point of what you're talking about with our customers. They're needing to build this and since it's not commercially available or they don't know where to look for it to be commercially available, they're all building themselves. So this layer is needed. And Blue is just one of the examples of quite a few we're now talking to. And like manufacturing, HPC, research where they're out trying to solve this problem with their own scripting tools and things like that. And I just, I don't know if there's anything you want to add, David, but you know, but there's definitely a demand here and customers are trying to figure out how to solve it beyond what Hammerspace is doing. Like the need is so great that they're just putting developers on trying to do it themselves. >> Well, and you know, Snowflake founders, they didn't have a Hammerspace to lean on. But, one of the things that's interesting about supercloud is we feel as though industry clouds will emerge, that as part of company's digital transformations, they will, you know, every company's a software company, they'll begin to build their own clouds and they will be able to use a Hammerspace to do that. >> A super pass layer. >> Yes. It's really, I don't know if David's speaking, I don't want to speak over him, but we can't hear you. May be going through a bad... >> Well, a regional, regional talks that make that possible. And so they're doing these render farms and editing farms, and it's a cloud-specific to the types of workflows in the median entertainment world. Or clouds specifically to workflows in the chip design world or in the drug and bio and life sciences exploration world. There are large organizations that are kind of a blend of end users, like the Broad, which has their own kind of cloud where they're asking collaborators to come in and work with them. So it starts to even blur who's an end user versus an ISV. >> Yes. >> Right? When you start talking about the massive data is the main gravity is to having lots of people participate. >> Yep, and that's where the value is. And that's where the value is. And this is a megatrend that we see. And so it's really important for us to get to the point of what is and what is not a supercloud and, you know, that's where we're trying to evolve. >> Let's talk about this for a second 'cause I want to, I want to challenge you on something and it's something that I got challenged on and it has led me to thinking differently than I did at first, which Molly can attest to. Okay? So, we have been looking for a way to talk about the concept of cloud of utility computing, run anything anywhere that isn't addressed in today's realization of cloud. 'Cause today's cloud is not run anything anywhere, it's quite the opposite. You park your data in AWS and that's where you run stuff. And you pretty much have to. Same with with Azure. They're using data gravity to keep you captive there, just like the old infrastructure guys did. But now it's even worse because it's coupled back with the software to some degree, as well. And you have to use their storage, networking, and compute. It's not, I mean it fell back to the mainframe era. Anyhow, so I love the concept of supercloud. By the way, I was going to suggest that a better term might be hyper cloud since hyper speaks to the multidimensionality of it and the ability to be in a, you know, be in a different dimension, a different plane of existence kind of thing like hyperspace. But super and hyper are somewhat synonyms. I mean, you have hyper cars and you have super cars and blah, blah, blah. I happen to like hyper maybe also because it ties into the whole Hammerspace notion of a hyper-dimensional, you know, reality, having your data centers connected by a wormhole that is Hammerspace. But regardless, what I got challenged on is calling it something different at all versus simply saying, this is what cloud has always meant to be. This is the true cloud, this is real cloud, this is cloud. And I think back to what happened, you'll remember, at Fusion IO we talked about IO memory and we did that because people had a conceptualization of what an SSD was. And an SSD back then was low capacity, low endurance, made to go military, aerospace where things needed to be rugged but was completely useless in the data center. And we needed people to imagine this thing as being able to displace entire SAND, with the kind of capacity density, performance density, endurance. And so we talked IO memory, we could have said enterprise SSD, and that's what the industry now refers to for that concept. What will people be saying five and 10 years from now? Will they simply say, well this is cloud as it was always meant to be where you are truly able to run anything anywhere and have not only the same APIs, but you're same data available with high performance access, all forms of access, block file and object everywhere. So yeah. And I wonder, and this is just me throwing it out there, I wonder if, well, there's trade offs, right? Giving it a new moniker, supercloud, versus simply talking about how cloud is always intended to be and what it was meant to be, you know, the real cloud or true cloud, there are trade-offs. By putting a name on it and branding it, that lets people talk about it and understand they're talking about something different. But it also is that an affront to people who thought that that's what they already had. >> What's different, what's new? Yes, and so we've given a lot of thought to this. >> Right, it's like you. >> And it's because we've been asked that why does the industry need a new term, and we've tried to address some of that. But some of the inside baseball that we haven't shared is, you remember the Web 2.0, back then? >> Yep. >> Web 2.0 was the same thing. And I remember Tim Burners Lee saying, "Why do we need Web 2.0? "This is what the Web was always supposed to be." But the truth is-- >> I know, that was another perfect-- >> But the truth is it wasn't, number one. Number two, everybody hated the Web 2.0 term. John Furrier was actually in the middle of it all. And then it created this groundswell. So one of the things we wrote about is that supercloud is an evocative term that catalyzes debate and conversation, which is what we like, of course. And maybe that's self-serving. But yeah, HyperCloud, Metacloud, super, meaning, it's funny because super came from Latin supra, above, it was never the superlative. But the superlative was a convenient byproduct that caused a lot of friction and flack, which again, in the media business is like a perfect storm brewing. >> The bad thing to have to, and I think you do need to shake people out of their, the complacency of the limitations that they're used to. And I'll tell you what, the fact that you even have the terms hybrid cloud, multi-cloud, private cloud, edge computing, those are all just referring to the different boundaries that isolate the silo that is the current limited cloud. >> Right. >> So if I heard correctly, what just, in terms of us defining what is and what isn't in supercloud, you would say traditional applications which have to run in a certain place, in a certain cloud can't run anywhere else, would be the stuff that you would not put in as being addressed by supercloud. And over time, you would want to be able to run the data where you want to and in any of those concepts. >> Or even modern apps, right? Or even modern apps that are siloed in SAS within an individual cloud, right? >> So yeah, I guess it's twofold. Number one, if you're going at the high application layers, there's lots of ways that you can give the appearance of anything running anywhere. The ISV, the SAS vendor can engineer stuff to have the ability to serve with low enough latency to different geographies, right? So if you go too high up the stack, it kind of loses its meaning because there's lots of different ways to make due and give the appearance of omni-presence of the service. Okay? As you come down more towards the platform layer, it gets harder and harder to mask the fact that supercloud is something entirely different than just a good regionally-distributed SAS service. So I don't think you, I don't think you can distinguish supercloud if you go too high up the stack because it's just SAS, it's just a good SAS service where the SAS vendor has done the hard work to give you low latency access from different geographic regions. >> Yeah, so this is one of the hardest things, David. >> Common among them. >> Yeah, this is really an important point. This is one of the things I've had the most trouble with is why is this not just SAS? >> So you dilute your message when you go up to the SAS layer. If you were to focus most of this around the super pass layer, the how can you host applications and run them anywhere and not host this, not run a service, not have a service available everywhere. So how can you take any application, even applications that are written, you know, in a traditional legacy data center fashion and be able to run them anywhere and have them have their binaries and their datasets and the runtime environment and the infrastructure to start them and stop them? You know, the jobs, the, what the Kubernetes, the job scheduler? What we're really talking about here, what I think we're really talking about here is building the operating system for a decentralized cloud. What is the operating system, the operating environment for a decentralized cloud? Where you can, and that the main two functions of an operating system or an operating environment are the process scheduler, the thing that's scheduling what is running where and when and so forth, and the file system, right? The thing that's supplying a common view and access to data. So when we talk about this, I think that the strongest argument for supercloud is made when you go down to the platform layer and talk of it, talk about it as an operating environment on which you can run all forms of applications. >> Would you exclude--? >> Not a specific application that's been engineered as a SAS. (audio distortion) >> He'll come back. >> Are you there? >> Yeah, yeah, you just cut out for a minute. >> I lost your last statement when you broke up. >> We heard you, you said that not the specific application. So would you exclude Snowflake from supercloud? >> Frankly, I would. I would. Because, well, and this is kind of hard to do because Snowflake doesn't like to, Frank doesn't like to talk about Snowflake as a SAS service. It has a negative connotation. >> But it is. >> I know, we all know it is. We all know it is and because it is, yes, I would exclude them. >> I think I actually have him on camera. >> There's nothing in common. >> I think I have him on camera or maybe Benoit as saying, "Well, we are a SAS." I think it's Slootman. I think I said to Slootman, "I know you don't like to say you're a SAS." And I think he said, "Well, we are a SAS." >> Because again, if you go to the top of the application stack, there's any number of ways you can give it location agnostic function or you know, regional, local stuff. It's like let's solve the location problem by having me be your one location. How can it be decentralized if you're centralizing on (audio distortion)? >> Well, it's more decentralized than if it's all in one cloud. So let me actually, so the spectrum. So again, in the spirit of what is and what isn't, I think it's safe to say Hammerspace is supercloud. I think there's no debate there, right? Certainly among this crowd. And I think we can all agree that Dell, Dell Storage is not supercloud. Where it gets fuzzy is this Snowflake example or even, how about a, how about a Cohesity that instantiates its stack in different cloud regions in different clouds, and synchronizes, however magic sauce it does that. Is that a supercloud? I mean, so I'm cautious about having too strict of a definition 'cause then only-- >> Fair enough, fair enough. >> But I could use your help and thoughts on that. >> So I think we're talking about two different spectrums here. One is the spectrum of platform to application-specific. As you go up the application stack and it becomes this specific thing. Or you go up to the more and more structured where it's serving a specific application function where it's more of a SAS thing. I think it's harder to call a SAS service a supercloud. And I would argue that the reason there, and what you're lacking in the definition is to talk about it as general purpose. Okay? Now, that said, a data warehouse is general purpose at the structured data level. So you could make the argument for why Snowflake is a supercloud by saying that it is a general purpose platform for doing lots of different things. It's just one at a higher level up at the structured data level. So one spectrum is the high level going from platform to, you know, unstructured data to structured data to very application-specific, right? Like a specific, you know, CAD/CAM mechanical design cloud, like an Autodesk would want to give you their cloud for running, you know, and sharing CAD/CAM designs, doing your CAD/CAM anywhere stuff. Well, the other spectrum is how well does the purported supercloud technology actually live up to allowing you to run anything anywhere with not just the same APIs but with the local presence of data with the exact same runtime environment everywhere, and to be able to correctly manage how to get that runtime environment anywhere. So a Cohesity has some means of running things in different places and some means of coordinating what's where and of serving diff, you know, things in different places. I would argue that it is a very poor approximation of what Hammerspace does in providing the exact same file system with local high performance access everywhere with metadata ability to control where the data is actually instantiated so that you don't have to wait for it to get orchestrated. But even then when you do have to wait for it, it happens automatically and so it's still only a matter of, well, how quick is it? And on the other end of the spectrum is you could look at NetApp with Flexcache and say, "Is that supercloud?" And I would argue, well kind of because it allows you to run things in different places because it's a cache. But you know, it really isn't because it presumes some central silo from which you're cacheing stuff. So, you know, is it or isn't it? Well, it's on a spectrum of exactly how fully is it decoupling a runtime environment from specific locality? And I think a cache doesn't, it stretches a specific silo and makes it have some semblance of similar access in other places. But there's still a very big difference to the central silo, right? You can't turn off that central silo, for example. >> So it comes down to how specific you make the definition. And this is where it gets kind of really interesting. It's like cloud. Does IBM have a cloud? >> Exactly. >> I would say yes. Does it have the kind of quality that you would expect from a hyper-scale cloud? No. Or see if you could say the same thing about-- >> But that's a problem with choosing a name. That's the problem with choosing a name supercloud versus talking about the concept of cloud and how true up you are to that concept. >> For sure. >> Right? Because without getting a name, you don't have to draw, yeah. >> I'd like to explore one particular or bring them together. You made a very interesting observation that from a enterprise point of view, they want to safeguard their store, their data, and they want to make sure that they can have that data running in their own workflows, as well as, as other service providers providing services to them for that data. So, and in in particular, if you go back to, you go back to Snowflake. If Snowflake could provide the ability for you to have your data where you wanted, you were in charge of that, would that make Snowflake a supercloud? >> I'll tell you, in my mind, they would be closer to my conceptualization of supercloud if you can instantiate Snowflake as software on your own infrastructure, and pump your own data to Snowflake that's instantiated on your own infrastructure. The fact that it has to be on their infrastructure or that it's on their, that it's on their account in the cloud, that you're giving them the data and they're, that fundamentally goes against it to me. If they, you know, they would be a pure, a pure plate if they were a software defined thing where you could instantiate Snowflake machinery on the infrastructure of your choice and then put your data into that machinery and get all the benefits of Snowflake. >> So did you see--? >> In other words, if they were not a SAS service, but offered all of the similar benefits of being, you know, if it were a service that you could run on your own infrastructure. >> So did you see what they announced, that--? >> I hope that's making sense. >> It does, did you see what they announced at Dell? They basically announced the ability to take non-native Snowflake data, read it in from an object store on-prem, like a Dell object store. They do the same thing with Pure, read it in, running it in the cloud, and then push it back out. And I was saying to Dell, look, that's fine. Okay, that's interesting. You're taking a materialized view or an extended table, whatever you're doing, wouldn't it be more interesting if you could actually run the query locally with your compute? That would be an extension that would actually get my attention and extend that. >> That is what I'm talking about. That's what I'm talking about. And that's why I'm saying I think Hammerspace is more progressive on that front because with our technology, anybody who can instantiate a service, can make a service. And so I, so MSPs can use Hammerspace as a way to build a super pass layer and host their clients on their infrastructure in a cloud-like fashion. And their clients can have their own private data centers and the MSP or the public clouds, and Hammerspace can be instantiated, get this, by different parties in these different pieces of infrastructure and yet linked together to make a common file system across all of it. >> But this is data mesh. If I were HPE and Dell it's exactly what I'd be doing. I'd be working with Hammerspace to create my own data. I'd work with Databricks, Snowflake, and any other-- >> Data mesh is a good way to put it. Data mesh is a good way to put it. And this is at the lowest level of, you know, the underlying file system that's mountable by the operating system, consumed as a real file system. You can't get lower level than that. That's why this is the foundation for all of the other apps and structured data systems because you need to have a data mesh that can at least mesh the binary blob. >> Okay. >> That hold the binaries and that hold the datasets that those applications are running. >> So David, in the third week of January, we're doing supercloud 2 and I'm trying to convince John Furrier to make it a data slash data mesh edition. I'm slowly getting him to the knothole. I would very much, I mean you're in the Bay Area, I'd very much like you to be one of the headlines. As Zhamak Dehghaniis going to speak, she's the creator of Data Mesh, >> Sure. >> I'd love to have you come into our studio as well, for the live session. If you can't make it, we can pre-record. But you're right there, so I'll get you the dates. >> We'd love to, yeah. No, you can count on it. No, definitely. And you know, we don't typically talk about what we do as Data Mesh. We've been, you know, using global data environment. But, you know, under the covers, that's what the thing is. And so yeah, I think we can frame the discussion like that to line up with other, you know, with the other discussions. >> Yeah, and Data Mesh, of course, is one of those evocative names, but she has come up with some very well defined principles around decentralized data, data as products, self-serve infrastructure, automated governance, and and so forth, which I think your vision plugs right into. And she's brilliant. You'll love meeting her. >> Well, you know, and I think.. Oh, go ahead. Go ahead, Peter. >> Just like to work one other interface which I think is important. How do you see yourself and the open source? You talked about having an operating system. Obviously, Linux is the operating system at one level. How are you imagining that you would interface with cost community as part of this development? >> Well, it's funny you ask 'cause my CTO is the kernel maintainer of the storage networking stack. So how the Linux operating system perceives and consumes networked data at the file system level, the network file system stack is his purview. He owns that, he wrote most of it over the last decade that he's been the maintainer, but he's the gatekeeper of what goes in. And we have leveraged his abilities to enhance Linux to be able to use this decentralized data, in particular with decoupling the control plane driven by metadata from the data access path and the many storage systems on which the data gets accessed. So this factoring, this splitting of control plane from data path, metadata from data, was absolutely necessary to create a data mesh like we're talking about. And to be able to build this supercloud concept. And the highways on which the data runs and the client which knows how to talk to it is all open source. And we have, we've driven the NFS 4.2 spec. The newest NFS spec came from my team. And it was specifically the enhancements needed to be able to build a spanning file system, a data mesh at a file system level. Now that said, our file system itself and our server, our file server, our data orchestration, our data management stuff, that's all closed source, proprietary Hammerspace tech. But the highways on which the mesh connects are actually all open source and the client that knows how to consume it. So we would, honestly, I would welcome competitors using those same highways. They would be at a major disadvantage because we kind of built them, but it would still be very validating and I think only increase the potential adoption rate by more than whatever they might take of the market. So it'd actually be good to split the market with somebody else to come in and share those now super highways for how to mesh data at the file system level, you know, in here. So yeah, hopefully that answered your question. Does that answer the question about how we embrace the open source? >> Right, and there was one other, just that my last one is how do you enable something to run in every environment? And if we take the edge, for example, as being, as an environment which is much very, very compute heavy, but having a lot less capability, how do you do a hold? >> Perfect question. Perfect question. What we do today is a software appliance. We are using a Linux RHEL 8, RHEL 8 equivalent or a CentOS 8, or it's, you know, they're all roughly equivalent. But we have bundled and a software appliance which can be instantiated on bare metal hardware on any type of VM system from VMware to all of the different hypervisors in the Linux world, to even Nutanix and such. So it can run in any virtualized environment and it can run on any cloud instance, server instance in the cloud. And we have it packaged and deployable from the marketplaces within the different clouds. So you can literally spin it up at the click of an API in the cloud on instances in the cloud. So with all of these together, you can basically instantiate a Hammerspace set of machinery that can offer up this file system mesh. like we've been using the terminology we've been using now, anywhere. So it's like being able to take and spin up Snowflake and then just be able to install and run some VMs anywhere you want and boom, now you have a Snowflake service. And by the way, it is so complete that some of our customers, I would argue many aren't even using public clouds at all, they're using this just to run their own data centers in a cloud-like fashion, you know, where they have a data service that can span it all. >> Yeah and to Molly's first point, we would consider that, you know, cloud. Let me put you on the spot. If you had to describe conceptually without a chalkboard what an architectural diagram would look like for supercloud, what would you say? >> I would say it's to have the same runtime environment within every data center and defining that runtime environment as what it takes to schedule the execution of applications, so job scheduling, runtime stuff, and here we're talking Kubernetes, Slurm, other things that do job scheduling. We're talking about having a common way to, you know, instantiate compute resources. So a global compute environment, having a common compute environment where you can instantiate things that need computing. Okay? So that's the first part. And then the second is the data platform where you can have file block and object volumes, and have them available with the same APIs in each of these distributed data centers and have the exact same data omnipresent with the ability to control where the data is from one moment to the next, local, where all the data is instantiate. So my definition would be a common runtime environment that's bifurcate-- >> Oh. (attendees chuckling) We just lost them at the money slide. >> That's part of the magic makes people listen. We keep someone on pin and needles waiting. (attendees chuckling) >> That's good. >> Are you back, David? >> I'm on the edge of my seat. Common runtime environment. It was like... >> And just wait, there's more. >> But see, I'm maybe hyper-focused on the lower level of what it takes to host and run applications. And that's the stuff to schedule what resources they need to run and to get them going and to get them connected through to their persistence, you know, and their data. And to have that data available in all forms and have it be the same data everywhere. On top of that, you could then instantiate applications of different types, including relational databases, and data warehouses and such. And then you could say, now I've got, you know, now I've got these more application-level or structured data-level things. I tend to focus less on that structured data level and the application level and am more focused on what it takes to host any of them generically on that super pass layer. And I'll admit, I'm maybe hyper-focused on the pass layer and I think it's valid to include, you know, higher levels up the stack like the structured data level. But as soon as you go all the way up to like, you know, a very specific SAS service, I don't know that you would call that supercloud. >> Well, and that's the question, is there value? And Marianna Tessel from Intuit said, you know, we looked at it, we did it, and it just, it was actually negative value for us because connecting to all these separate clouds was a real pain in the neck. Didn't bring us any additional-- >> Well that's 'cause they don't have this pass layer underneath it so they can't even shop around, which actually makes it hard to stand up your own SAS service. And ultimately they end up having to build their own infrastructure. Like, you know, I think there's been examples like Netflix moving away from the cloud to their own infrastructure. Basically, if you're going to rent it for more than a few months, it makes sense to build it yourself, if it's at any kind of scale. >> Yeah, for certain components of that cloud. But if the Goldman Sachs came to you, David, and said, "Hey, we want to collaborate and we want to build "out a cloud and essentially build our SAS system "and we want to do that with Hammerspace, "and we want to tap the physical infrastructure "of not only our data centers but all the clouds," then that essentially would be a SAS, would it not? And wouldn't that be a Super SAS or a supercloud? >> Well, you know, what they may be using to build their service is a supercloud, but their service at the end of the day is just a SAS service with global reach. Right? >> Yeah. >> You know, look at, oh shoot. What's the name of the company that does? It has a cloud for doing bookkeeping and accounting. I forget their name, net something. NetSuite. >> NetSuite. NetSuite, yeah, Oracle. >> Yeah. >> Yep. >> Oracle acquired them, right? Is NetSuite a supercloud or is it just a SAS service? You know? I think under the covers you might ask are they using supercloud under the covers so that they can run their SAS service anywhere and be able to shop the venue, get elasticity, get all the benefits of cloud in the, to the benefit of their service that they're offering? But you know, folks who consume the service, they don't care because to them they're just connecting to some endpoint somewhere and they don't have to care. So the further up the stack you go, the more location-agnostic it is inherently anyway. >> And I think it's, paths is really the critical layer. We thought about IAS Plus and we thought about SAS Minus, you know, Heroku and hence, that's why we kind of got caught up and included it. But SAS, I admit, is the hardest one to crack. And so maybe we exclude that as a deployment model. >> That's right, and maybe coming down a level to saying but you can have a structured data supercloud, so you could still include, say, Snowflake. Because what Snowflake is doing is more general purpose. So it's about how general purpose it is. Is it hosting lots of other applications or is it the end application? Right? >> Yeah. >> So I would argue general purpose nature forces you to go further towards platform down-stack. And you really need that general purpose or else there is no real distinguishing. So if you want defensible turf to say supercloud is something different, I think it's important to not try to wrap your arms around SAS in the general sense. >> Yeah, and we've kind of not really gone, leaned hard into SAS, we've just included it as a deployment model, which, given the constraints that you just described for structured data would apply if it's general purpose. So David, super helpful. >> Had it sign. Define the SAS as including the hybrid model hold SAS. >> Yep. >> Okay, so with your permission, I'm going to add you to the list of contributors to the definition. I'm going to add-- >> Absolutely. >> I'm going to add this in. I'll share with Molly. >> Absolutely. >> We'll get on the calendar for the date. >> If Molly can share some specific language that we've been putting in that kind of goes to stuff we've been talking about, so. >> Oh, great. >> I think we can, we can share some written kind of concrete recommendations around this stuff, around the general purpose, nature, the common data thing and yeah. >> Okay. >> Really look forward to it and would be glad to be part of this thing. You said it's in February? >> It's in January, I'll let Molly know. >> Oh, January. >> What the date is. >> Excellent. >> Yeah, third week of January. Third week of January on a Tuesday, whatever that is. So yeah, we would welcome you in. But like I said, if it doesn't work for your schedule, we can prerecord something. But it would be awesome to have you in studio. >> I'm sure with this much notice we'll be able to get something. Let's make sure we have the dates communicated to Molly and she'll get my admin to set it up outside so that we have it. >> I'll get those today to you, Molly. Thank you. >> By the way, I am so, so pleased with being able to work with you guys on this. I think the industry needs it very bad. They need something to break them out of the box of their own mental constraints of what the cloud is versus what it's supposed to be. And obviously, the more we get people to question their reality and what is real, what are we really capable of today that then the more business that we're going to get. So we're excited to lend the hand behind this notion of supercloud and a super pass layer in whatever way we can. >> Awesome. >> Can I ask you whether your platforms include ARM as well as X86? >> So we have not done an ARM port yet. It has been entertained and won't be much of a stretch. >> Yeah, it's just a matter of time. >> Actually, entertained doing it on behalf of NVIDIA, but it will absolutely happen because ARM in the data center I think is a foregone conclusion. Well, it's already there in some cases, but not quite at volume. So definitely will be the case. And I'll tell you where this gets really interesting, discussion for another time, is back to my old friend, the SSD, and having SSDs that have enough brains on them to be part of that fabric. Directly. >> Interesting. Interesting. >> Very interesting. >> Directly attached to ethernet and able to create a data mesh global file system, that's going to be really fascinating. Got to run now. >> All right, hey, thanks you guys. Thanks David, thanks Molly. Great to catch up. Bye-bye. >> Bye >> Talk to you soon.

>>Hey everyone. Welcome to the cubes presentation of the AWS startup showcase. This is season two, episode four of our ongoing series. That's featuring exciting startups within the AWS ecosystem. This theme, cybersecurity protect and detect against threats. I'm your host. Lisa Martin. I've got two guests here with me. Please. Welcome back to the program. Sam Kam, a COO and co-founder of security scorecard and bar Roth. Charri team lead solutions marketing at confluent guys. It's great to have you on the program talking about cybersecurity. >>Thanks for having us, Lisa, >>Sam, let's go ahead and kick off with you. You've been on the queue before, but give the audience just a little bit of context about security scorecard or SSC as they're gonna hear it referred to. >>Yeah. AB absolutely. Thank you for that. Well, the easiest way to, to put it is when people wanna know about their credit risk, they consult one of the major credit scoring companies. And when companies wanna know about their cybersecurity risk, they turn to security scorecard to get that holistic view of, of, of the security posture. And the way it works is SSC is continuously 24 7 collecting signals from across the entire internet. I entire IPV four space and they're doing it to identify vulnerable and misconfigured digital assets. And we were just looking back over like a three year period. We looked from 2019 to 2022. We, we, we assessed through our techniques over a million and a half organizations and found that over half of them had at least one open critical vulnerability exposed to the internet. What was even more shocking was 20% of those organizations had amassed over a thousand vulnerabilities each. >>So SSC we're in the business of really building solutions for customers. We mine the data from dozens of digital sources and help discover the risks and the flaws that are inherent to their business. And that becomes increasingly important as companies grow and find new sources of risk and new threat vectors that emerge on the internet for themselves and for their vendor and business partner ecosystem. The last thing I'll mention is the platform that we provide. It relies on data collection and processing to be done in an extremely accurate and real time way. That's a key for that's allowed us to scale. And in order to comp, in order for us to accomplish this security scorecard engineering teams, they used a really novel combination of confluent cloud and confluent platform to build a really, really robust data for streaming pipelines and the data streaming pipelines enabled by confluent allow us at security scorecard to collect the data from a lot of various sources for risk analysis. Then they get feer further analyzed and provided to customers as a easy to understand summary of analytics. >>Rob, let's bring you into the conversation, talk about confluent, give the audience that overview and then talk about what you're doing together with SSC. >>Yeah, and I wanted to say Sam did a great job of setting up the context about what confluent is. So, so appreciate that, but a really simple way to think about it. Lisa is confident as a data streaming platform that is pioneering a fundamentally new category of data infrastructure that is at the core of what SSE does. Like Sam said, the key is really collect data accurately at scale and in real time. And that's where our cloud native offering really empowers organizations like SSE to build great customer experiences for their customers. And the other thing we do is we also help organizations build a sophisticated real time backend operations. And so at a high level, that's the best way to think about comfort. >>Got it. But I'll talk about data streaming, how it's being used in cyber security and what the data streaming pipelines enable enabled by confluent allow SSE to do for its customers. >>Yeah, I think Sam can definitely share his thoughts on this, but one of the things I know we are all sort of experiencing is the, is the rise of cyber threats, whether it's online from a business B2B perspective or as consumers just be our data and, and the data that they're generating and the companies that have access to it. So as the, the need to protect the data really grows companies and organizations really need to effectively detect, respond and protect their environments. And the best way to do this is through three ways, scale, speed, and cost. And so going back to the points I brought up earlier with conference, you can really gain real time data ingestion and enable those analytics that Sam talked about previously while optimizing for cost scale. So those are so doing all of this at the same time, as you can imagine, is, is not easy and that's where we Excel. >>And so the entire premise of data streaming is built on the concepts. That data is not static, but constantly moving across your organization. And that's why we call it data streams. And so at its core, we we've sort of built or leveraged that open source foundation of APA sheet Kafka, but we have rearchitected it for the cloud with a totally new cloud native experience. And ultimately for customers like SSE, we have taken a away the need to manage a lot of those operational tasks when it comes to Apache Kafka. The other thing we've done is we've added a ton of proprietary IP, including security features like role based access control. I mean, some prognosis talking about, and that really allows you to securely connect to any data no matter where it resides at scale at speed. And it, >>Can you talk about bar sticking with you, but some of the improvements, and maybe this is a actually question for Sam, some of the improvements that have been achieved on the SSC side as a result of the confluent partnership, things are much faster and you're able to do much more understand, >>Can I, can Sam take it away? I can maybe kick us off and then breath feel, feel free to chime in Lisa. The, the, the, the problem that we're talking about has been for us, it was a longstanding challenge. We're about a nine year old company. We're a high growth startup and data collection has always been in, in our DNA. It's at it's at the core of what we do and getting, getting the insights, the, and analytics that we synthesize from that data into customer's hands as quickly as possible is the, is the name of the game because they're trying to make decisions and we're empowering them to make those decisions faster. We always had challenges in, in the arena because we, well partners like confluent didn't didn't exist when we started scorecard when, when we we're a customer. But we, we, we think of it as a partnership when we found confluent technology and you can hear it from Barth's description. >>Like we, we shared a common vision and they understood some of the pain points that we were experiencing on a very like visceral and intimate level. And for us, that was really exciting, right? Just to have partners that are there saying, we understand your problem. This is exactly the problem that we're solving. We're, we're here to help what the technology has done for us since then is it's not only allowed us to process the data faster and get the analytics to the customer, but it's also allowed us to create more value for customers, which, which I'll talk about in a bit, including new products and new modules that we didn't have the capabilities to deliver before. >>And we'll talk about those new products in a second exciting stuff coming out there from SSC, bro. Talk about the partnership from, from confluence perspective, how has it enabled confluence to actually probably enhance its technology as a result of seeing and learning what SSC is able to do with the technology? >>Yeah, first of all, I, I completely agree with Sam it's, it's more of a partnership because like Sam said, we sort of shared the same vision and that is to really make sure that organizations have access to the data. Like I said earlier, no matter where it resides so that you can scan and identify the, the potential security security threads. I think from, from our perspective, what's really helped us from the perspective of partnering with SSE is just looking at the data volumes that they're working with. So I know a stat that we talked about recently was around scanning billions of records, thousands of ports on a daily basis. And so that's where, like I, like I mentioned earlier, our technology really excels because you can really ingest and amplify the volumes of data that you're processing so that you can scan and, and detect those threats in real time. >>Because I mean, especially the amount of volume, the data volume that's increasing on a year by basis, that aspect in order to be able to respond quickly, that is paramount. And so what's really helped us is just seeing what SSE is doing in terms of scanning the, the web ports or the data systems that are at are at potential risk. Being able to support their use cases, whether it's data sharing between their different teams internally are being able to empower customers, to be able to detect and scan their data systems. And so the learning for us is really seeing how those millions and billions of records get processed. >>Got it sounds like a really synergistic partnership that you guys have had there for the last year or so, Sam, let's go back over to you. You mentioned some new products. I see SSC just released a tax surface intelligence product. That's detecting thousands of vulnerabilities per minute. Talk to us about that, the importance of that, and another release that you're making. >>There are some really exciting products that we have released recently and are releasing at security scorecard. When we think about, when we think about ratings and risk, we think about it not just for our companies or our third parties, but we think about it in a, in a broader sense of an, of an ecosystem, because it's important to have data on third parties, but we also want to have the data on their third parties as well. No, nobody's operating in a vacuum. Everybody's operating in this hyper connected ecosystem and the risk can live not just in the third parties, but they might be storing processing data in a myriad of other technological solutions, which we want to understand, but it's really hard to get that visibility because today the way it's done is companies ask their third parties. Hey, send me a list of your third parties, where my data is stored. >>It's very manual, it's very labor intensive, and it's a trust based exercise that makes it really difficult to validate. What we've done is we've developed a technology called a V D automatic vendor detection. And what a V D does is it goes out and for any company, your own company or another business partner that you work with, it will go detect all of the third party connections that we see that have a live network connection or data connection to an organization. So that's like an awareness and discovery tool because now we can see and pull the veil back and see what the bigger ecosystem and connectivity looks like. Thus allowing the customers to go hold accountable, not just the third parties, but their fourth parties, fifth parties really end parties. And they, and they can only do that by using scorecard. The attack surface intelligence tool is really exciting for us because well, be before security scorecard people thought what we were doing was fairly, I impossible. >>It was really hard to get instant visibility on any company and any business partner. And at the same time, it was of critical importance to have that instant visibility into the risk because companies are trying to make faster decisions and they need the risk data to steer those decisions. So when I think about, when I think about that problem in, in managing sort of this evolving landscape, what it requires is it requires insightful and actionable, real time security data. And that relies on a couple things, talent and tech on the talent side, it starts with people. We have an amazing R and D team. We invest heavily. It's the heartbeat of what we do. That team really excels in areas of data collection analysis and scaling large data sets. And then we know on the tech side, well, we figured out some breakthrough techniques and it also requires partners like confluent to help with the real time streaming. >>What we realized was those capabilities are very desired in the market. And we created a new product from it called the tech surface intelligence. A tech surface intelligence focuses less on the rating. There's, there's a persona on users that really value the rating. It's easy to understand. It's a bridge language between technical and non-technical stakeholders. That's on one end of the spectrum on the other end of the spectrum. There's customers and users, very technical customers and users that may not have as much interest in a layman's rating, but really want a deep dive into the strong threat Intel data and capabilities and insights that we're producing. So we produced ASI, which stands for attack surface intelligence that allows customers to look at the surface area of attack all of the digital assets for any organization and see all of the threats, vulnerabilities, bad actors, including sometimes discoveries of zero day vulnerabilities that are, that are out in the wild and being exploited by bad guys. So we have a really strong pulse on what's happening on the internet, good and bad. And we created that product to help service a market that was interested in, in going deep into the data. >>So it's >>So critical. Go >>Ahead to jump in there real quick, because I think the points that Sam brought up, we had a great, great discussion recently while we were building on the case study that I think brings this to life, going back to the AVD product that Sam talked about and, and Sam can probably do a better job of walking through the story, but the way I understand it, one of security scorecards customers approached them and told them that they had an issue to resolve and what they ended up. So this customer was using an AVD product at the time. And so they said that, Hey, the car SSE, they said, Hey, your product shows that we used, you were using HubSpot, but we stopped using that age server. And so I think when SSE investigated, they did find a very recent HubSpot ping being used by the marketing team in this instance. And as someone who comes from that marketing background, I can raise my hand and said, I've been there, done that. So, so yeah, I mean, Sam can probably share his thoughts on this, but that's, I think the great story that sort of brings this all to life in terms of how actually customers go about using SSCs products. >>And Sam, go ahead on that. It sounds like, and one of the things I'm hearing that is a benefit is reduction in shadow. It, I'm sure that happens so frequently with your customers about Mar like a great example that you gave of, of the, the it folks saying we don't use HubSpot, have it in years marketing initiates an instance. Talk about that as some of the benefits in it for customers reducing shadow it, there's gotta be many more benefits from a security perspective. >>Yeah, the, there's a, there's a big challenge today because the market moved to the cloud and that makes it really easy for anybody in an organization to go sign, sign up, put in a credit card, or get a free trial to, to any product. And that product can very easily connect into the corporate system and access the data. And because of the nature of how cloud products work and how easy they are to sign up a byproduct of that is they sort of circumvent a traditional risk assessment process that, that organizations go through and organizations invest a, a lot of money, right? So there's a lot of time and money and energy that are invested in having good procurement risk management life cycles, and making sure that contracts are buttoned up. So on one side you have companies investing loads of energy. And then on the other side, any employee can circumvent that process by just going and with a few clicks, signing up and purchasing a product. >>And that's, and, and, and then that causes a, a disparity and Delta between what the technology and security team's understanding is of the landscape and, and what reality is. And we're trying to close that gap, right? We wanna close and reduce any windows of time or opportunity where a hacker can go discover some misconfigured cloud asset that somebody signed up for and maybe forgot to turn off. I mean, it's a lot of it is just human error and it, and it happens the example that Barra gave, and this is why understanding the third parties are so important. A customer contacted us and said, Hey, you're a V D detection product has an error. It's showing we're using a product. I think it was HubSpot, but we stopped using that. Right. And we don't understand why you're still showing it. It has to be a false positive. >>So we investigated and found that there was a very recent live HubSpot connection, ping being made. Sure enough. When we went back to the customer said, we're very confident the data's accurate. They looked into it. They found that the marketing team had started experimenting with another instance of HubSpot on the side. They were putting in real customer data in that instance. And it, it, you know, it triggered a security assessment. So we, we see all sorts of permutations of it, large multinational companies spin up a satellite office and a contractor setting up the network equipment. They misconfigure it. And inadvertently leave an administrator portal to the Cisco router exposed on the public internet. And they forget to turn off the administrative default credentials. So if a hacker stumbles on that, they can ha they have direct access to the network. We're trying to catch those things and surface them to the client before the hackers find it. >>So we're giving 'em this, this hacker's eye view. And without the continuous data analysis, without the stream processing, the customer wouldn't have known about those risks. But if you can automatically know about the risks as they happen, what that does is that prevents a million shoulder taps because the customer doesn't have to go tap on the marketing team's shoulder and go tap on employees and manually interview them. They have the data already, and that can be for their company. That can be for any company they're doing business with where they're storing and processing data. That's a huge time savings and a huge risk reduction, >>Huge risk reduction. Like you're taking blinders off that they didn't even know were there. And I can imagine Sam tune in the last couple of years, as SAS skyrocketed the use of collaboration tools, just to keep the lights on for organizations to be able to communicate. There's probably a lot of opportunity in your customer base and perspective customer base to engage with you and get that really full 360 degree view of their entire organization. Third parties, fourth parties, et cetera. >>Absolutely. Absolutely. CU customers are more engaged than they've ever been because that challenge of the market moving to the cloud, it hasn't stopped. We've been talking about it for a long time, but there's still a lot of big organizations that are starting to dip their toe in the pool and starting to cut over from what was traditionally an in-house data center in the basement of the headquarters. They're, they're moving over to the cloud. And then on, on top of that cloud providers like Azure, AWS, especially make it so easy for any company to go sign up, get access, build a product, and launch that product to the market. We see more and more organizations sitting on AWS, launching products and software. The, the barrier to entry is very, very low. And the value in those products is very, very high. So that's drawing the attention of organizations to go sign up and engage. >>The challenge then becomes, we don't know who has control over this data, right? We don't have know who has control and visibility of our data. We're, we're bringing that to surface and for vendors themselves like, especially companies that sit in AWS, what we see them doing. And I think Lisa, this is what you're alluding to. When companies engage in their own scorecard, there's a bit of a social aspect to it. When they look good in our platform, other companies are following them, right? So now all of the sudden they can make one motion to go look good, make their scorecard buttoned up. And everybody who's looking at them now sees that they're doing the right things. We actually have a lot of vendors who are customers, they're winning more competitive bakeoffs and deals because they're proving to their clients faster that they can trust them to store the data. >>So it's a bit of, you know, we're in a, two-sided kind of market. You have folks that are assessing other folks. That's fun to look at others and see how they're doing and hold them accountable. But if you're on the receiving end, that can be stressful. So what we've done is we've taken the, that situation and we've turned it into a really positive and productive environment where companies, whether they're looking at someone else or they're looking at themselves to prove to their clients, to prove to the board, it turns into a very productive experience for them >>One. Oh >>Yeah. That validation. Go ahead, bro. >>Really. I was gonna ask Sam his thoughts on one particular aspect. So in terms of the industry, Sam, that you're seeing sort of really moving to the cloud and like this need for secure data, making sure that the data can be trusted. Are there specific like verticals that are doing that better than the others? Or do you see that across the board? >>I think some industries have it easier and some industries have it harder, definitely in industries that are, I think, health, healthcare, financial services, a absolutely. We see heavier activity there on, on both sides, right? They they're, they're certainly becoming more and more proactive in their investments, but the attacks are not stopping against those, especially healthcare because the data is so valuable and historically healthcare was under, was an underinvested space, right. Hospitals. And we're always strapped for it folks. Now, now they're starting to wake up and pay very close attention and make heavier investments. >>That's pretty interesting. >>Tremendous opportunity there guys. I'm sorry. We are out of time, but this is such an interesting conversation. You see, we keep going, wanna ask you both where can, can prospective interested customers go to learn more on the SSC side, on the confluence side, through the AWS marketplace? >>I let some go first. >>Sure. Oh, thank thank, thank you. Thank you for on the security scorecard side. Well look, security scorecard is with the help of Colu is, has made it possible to instantly rate the security posture of any company in the world. We have 12 million organizations rated today and, and that, and that's going up every day. We invite any company in the world to try security scorecard for free and experience how, how easy it is to get your rating and see the security rating of, of any company and any, any company can claim their score. There's no, there's no charge. They can go to security, scorecard.com and we have a special, actually a special URL security scorecard.com/free-account/aws marketplace. And even better if someone's already on AWS, you know, you can view our security posture with the AWS marketplace, vendor insights, plugin to quickly and securely procure your products. >>Awesome. Guys, this has been fantastic information. I'm sorry, bro. Did you wanna add one more thing? Yeah. >>I just wanted to give quick call out leads. So anyone who wants to learn more about data streaming can go to www confluent IO. There's also an upcoming event, which has a separate URL. That's coming up in October where you can learn all about data streaming and that URL is current event.io. So those are the two URLs I just wanted to quickly call out. >>Awesome guys. Thanks again so much for partnering with the cube on season two, episode four of our AWS startup showcase. We appreciate your insights and your time. And for those of you watching, thank you so much. Keep it right here for more action on the, for my guests. I am Lisa Martin. We'll see you next time.

(upbeat music) >> Hello, and welcome to this startup showcase. It's great to be here and talk about some of the innovations we are doing at AWS, how we work with our partner community, especially our open source partners. My name is Deepak Singh. I run our compute services organization, which is a very vague way of saying that I run a number of things that are connected together through compute. Very specifically, I run a container services organization. So for those of you who are into containers, ECS, EKS, fargate, ECR, App Runner Those are all teams that are within my org. I also run the Amazon Linux and BottleRocketing. So anything AWS does with Linux, both externally and internally, as well as our high-performance computing team. And perhaps very relevant to this discussion, I run the Amazon open source program office. Serving at AWS for over 13 years, almost 14, involved with compute in various ways, including EC2. What that has done has given me a vantage point of seeing how our customers use the services that we build for them, how they leverage various partner solutions, and along the way, how AWS itself has gotten involved with opensource. And I'll try and talk to you about some of those factors and how they impact, how you consume our services. So why don't we get started? So for many of you, you know, one of the things, there's two ways to look at AWS and open-source and Amazon in general. One is the number of contributors you may have. And the number of repositories that contribute to. Those are just a couple of measures. There are people that I work with on a regular basis, who will remind you that, those are not perfect measures. Sometimes you could just contribute to one thing and have outsized impact because of the nature of that thing. But it address being what it is, increasingly we'll look at different ways in which we can help contribute and enhance open source 'cause we consume a lot of it as well. I'll talk about it very specifically from the space that I work in the container space in particular, where we've worked a lot with people in the Kubernetes community. We've worked a lot with people in the broader CNCF community, as well as, you know, small projects that our customers might have got started off with. For example, I want to like talking about is Argo CD from Intuit. We were very actively involved with helping them figure out what to do with it. And it was great to see how into it. And we worked, etc, came together to think about get-ups at the Kubernetes level. And while those are their projects, we've always been involved with them. So we try and figure out what's important to our customers, how we can help and then take because of that. Well, let's talk about a little bit more, here's some examples of the kinds of open source projects that Amazon and AWS contribute to. They arranged from the open JDK. I think we even now have our own implementation of Java, the Corretto open source project. We contribute to projects like rust, where we are very active in the rest foundation from a leadership role as well, the robot operating system, just to pick some, we collaborate with Facebook and actively involved with the pirates project. And there's many others. You can see all the logos in here where we participate either because they're important to us as AWS in the services that we run or they're important to our customers and the services that they consume or the open source projects they care about and how we get to those. How we get and make those decisions is often depends on the importance of that particular project. At that point in time, how much impact they're having to AWS customers, or sometimes very feel that us contributing to that project is super critical because it helps us build more robust services. I'll talk about it in a completely, you know, somewhat different basis. You may have heard of us talk about our new next generation of Amazon Linux 2022, which is based on fedora as its sub stream. One of the reasons we made this decision was it allows us to go and participate in the preneurial project and make sure that the upstream project is robust, stays robust. And that, that what that ends up being is that Amazon Linux 2022 will be a robust operating system with the kinds of capabilities that our customers are asking for. That's just one example of how we think about it. So for example, you know, the Python software foundation is something that we work with very closely because so many of our customers use Python. So we help run something like PyPy which is many, you know, if you're a Python developer, I happened to be a Ruby one, but lots of our customers use Python and helping the Python project be robust by making sure PyPy is available to everybody is something that we help provide credits for help support in other ways. So it's not just code. It can mean many different ways of contributing as well, but in the end code and operations is where we hang our happens. Good examples of this is projects that we will create an open source because it makes sense to make sure that we open source some of the core primitives or foundations that are part of our own services. A great example of that, whether this be things that we open source or things that we contribute to. And I'll talk about both and I'll talk about things near and dear to my heart. There's many examples I've picked the two that I like talking about. The first of these is firecracker. Many of you have heard about it, a firecracker for those of you who don't know is a very lightweight virtual machine manager, which allows you to run these micro VMs. And why was this important many years ago when we started Lambda and quite honestly, Fugate and foggy, it still runs quite a bit in that mode, we used to have to run on VMs like everything else and finding the right VM for the size of tasks that somebody asks for the size of function that somebody asks for is requires us to provision capacity ahead of time. And it also wastes a lot of capacity because Lambda function is small. You won't even if you find the smallest VM possible, those can be a little that can be challenging. And you know, there's a lot of resources that are being wasted. VM start at a particular speed because they have to do a whole bunch of things before the operating system spins up and the virtual machine spins up and we asked ourselves, can we do better? come up with something that allows us to create right size, very lightweight, very fast booting. What's your machines, micro virtual machine that we ended up calling them. That's what led to firecracker. And we open source the project. And today firecrackers use, not just by AWS Lambda or foggy, but by a number of other folks, there's companies like fly IO that are using it. We know people using firecracker to run Kubernetes on prem on bare metal as an example. So we've seen a lot of other folks embrace it and use it as the foundation for building their own serverless services, their own container services. And we think there's a lot of value and learnings that we can bring to the table because we get the experience of operating at scale, but other people can bring to the table cause they may have specific requirements that we may not find it as important from an AWS perspective. So that's firecracker an example of a project where we contribute because we feel it's fundamentally important to us as continually. We were found, you know, we've been involved with continuity from the beginning. Today, we are a whole team that does nothing else, but contribute to container D because container D underlies foggy. It underlies our Kubernetes offerings. And it's increasingly being used by customers directly by their placement. You know, where they're running container D instead of running a full on Docker or similar container engine, what it has allowed us to do is focus on what's important so that we can operate continuously at scale, keep it robust and secure, add capabilities to it that AWS customers need manifested often through foggy Kubernetes, but in the end, it's a win-win for everybody. It makes continuously better. If you want to use containers for yourself on AWS, that's a great way to you. You know, you still, you still benefit from all the work that we're doing. The decision we took was since it's so important to us and our customers, we wanted a team that lived in breathed container D and made sure a super robust and there's many, many examples like that. No, that we ended up participating in, either by taking a project that exists or open sourcing our own. Here's an example of some of the open source projects that we have done from an AWS on Amazon perspective. And there's quite a few when I was looking at this list, I was quite surprised, not quite surprised I've seen the reports before, but every time I do, I have to recount and say, that's a lot more than one would have thought, even though I'd been looking at it for such a long time, examples of this in my world alone are things like, you know, what work had to do with Amazon Linux BottleRocket, which is a container host operating system. That's been open-sourced from day one. Firecracker is something we talked about. We have a project called AWS peril cluster, which allows you to spin up high performance computing clusters on AWS using the kind of schedulers you may use to use like slum. And that's an open source project. We have plenty of source projects in the web development space, in the security space. And more recently things like the open 3d engine, which is something that we are very excited about and that'd be open sourced a few months ago. And so there's a number of these projects that cover everything from tooling to developer, application frameworks, all the way to database and analytics and machine learning. And you'll notice that in a few areas, containers, as an example, machine learning as an example, our default is to go with open source option is where we can open source. And it makes sense for us to do so where we feel the product community might benefit from it. That's our default stance. The CNCF, the cloud native computing foundation is something that we've been involved with quite a bit. You know, we contribute to Kubernetes, be contribute to Envoy. I talked about continuity a bit. We've also contributed projects like CDK 8, which marries the AWS cloud development kit with Kubernetes. It's now a sandbox project in Kubernetes, and those are some of the areas. CNCF is such a wide surface area. We don't contribute to everything, but we definitely participate actively in CNCF with projects like HCB that are critical to eat for us. We are very, very active in just how the project evolves, but also try and see which of the projects that are important to our customers who are running Kubernetes maybe by themselves or some other project on AWS. Envoy is a good example. Kubernetes itself is a good example because in the end, we want to make sure that people running Kubernetes on AWS, even if they are not using our services are successful and we can help them, or we can work on the projects that are important to them. That's kind of how we think about the world. And it's worked pretty well for us. We've done a bunch of work on the Kubernetes side to make sure that we can integrate and solve a customer problem. We've, you know, from everything from models to work that we have done with gravity on our arm processor to a virtual GPU plugin that allows you to share and media GPU resources to the elastic fabric adapter, which are the network device for high performance computing that it can use at Kubernetes on AWS, along with things that directly impact Kubernetes customers like the CDKs project. I talked about work that we do with the container networking interface to the Amazon control of a Kubernetes, which is an open source project that allows you to use other AWS services directly from Kubernetes clusters. Again, you notice success, Kubernetes, not EKS, which is a managed Kubernetes service, because if we want you to be successful with Kubernetes and AWS, whether using our managed service or running your own, or some third party service. Similarly, we worked with premetheus. We now have a managed premetheus service. And at reinvent last year, we announced the general availability of this thing called carpenter, which is a provisioning and auto-scaling engine for Kubernetes, which is also an open source project. But here's the beauty of carpenter. You don't have to be using EKS to use it. Anyone running Kubernetes on AWS can leverage it. We focus on the AWS provider, but we've built it in such a way that if you wanted to take carpenter and implemented on prem or another cloud provider, that'd be completely okay. That's how it's designed and what we anticipated people may want to do. I talked a little bit about BottleRocket it's our Linux-based open-source operating system. And the thing that we have done with BottleRocket is make sure that we focus on security and the needs of customers who want to run orchestrated container, very focused on that problem. So for example, BottleRocket only has essential software needed to run containers, se Linux. I just notice it says that's the lineups, but I'm sure that, you know, Lena Torvalds will be pretty happy. And seeing that SE linux is enabled by default, we use things like DM Verity, and it has a read only root file system, no shell, you can assess it. You can install it if you wanted to. We allowed it to create different bill types, variants as we call them, you can create a variant for a non AWS resource as well. If you have your own homegrown container orchestrator, you can create a variant for that. It's designed to be used in many different contexts and all of that is open sourced. And then we use the update framework to publish and secure repository and kind of how this transactional system way of updating the software. And it's something that we didn't invent, but we have embraced wholeheartedly. It's a bottle rockets, completely open source, you know, have partners like Aqua, where who develop security tools for containers. And for them, you know, something I bought in rocket is a natural partnership because people are running a container host operating system. You can use Aqua tooling to make sure that they have a secure Indiana environment. And we see many more examples like that. You may think so over us, it's all about AWS proprietary technology because Lambda is a proprietary service. But you know, if you look peek under the covers, that's not necessarily true. Lambda runs on top of firecracker, as we've talked about fact crackers and open-source projects. So the foundation of Lambda in many ways is open source. What it also allows people to do is because Lambda runs at such extreme scale. One of the things that firecracker is really good for is running at scale. So if you want to build your own firecracker base at scale service, you can have most of the confidence that as long as your workload fits the design parameters, a firecracker, the battle hardening the robustness is being proved out day-to-day by services at scale like Lambda and foggy. For those of you who don't know service support services, you know, in the end, our goal with serverless is to make sure that you don't think about all the infrastructure that your applications run on. We focus on business logic as much as you can. That's how we think about it. And serverless has become its own quote-unquote "Sort of environment." The number of partners and open-source frameworks and tools that are spun up around serverless. In which case mostly, I mean, Lambda, API gateway. So it says like that is pretty high. So, you know, number of open source projects like Zappa server serverless framework, there's so many that have come up that make it easier for our customers to consume AWS services like Lambda and API gateway. We've also done some of our own tooling and frameworks, a serverless application model, AWS jealous. If you're a Python developer, we have these open service runtimes for Lambda, rust dot other options. We have amount of number of tools that we opened source. So in general, you'll find that tooling that we do runtime will tend to be always be open-sourced. We will often take some of the guts of the things that we use to build our systems like firecracker and open-source them while the control plane, etc, AWS services may end up staying proprietary, which is the case in Lambda. Increasingly our customers build their applications and leverage the broader AWS partner network. The AWS partner network is a network of partnerships that we've built of trusted partners. when you go to the APN website and find a partner, they know that that partner meets a certain set of criteria that AWS has developed, and you can rely on those partners for your own business. So whether you're a little tiny business that wants some function fulfill that you don't have the resources for or large enterprise that wants all these applications that you've been using on prem for a long time, and want to keep leveraging them in the cloud, you can go to APN and find that partner and then bring their solution on as part of your cloud infrastructure and could even be a systems integrator, for example, to help you solve this specific development problem that you may have a need for. Increasingly, you know, one of the things we like to do is work with an apartment community that is full of open-source providers. So a great one, there's so many, and you have, we have a panel discussion with many other partners as well, who make it easier for you to build applications on AWS, all open source and built on open source. But I like to call it a couple of them. The first one of them is TIDELIFT. TIDELIFT, For those of you who don't know is a company that provides SAS based tools to curate track, manage open source catalogs. You know, they have a whole network of maintainers and providers. They help, if you're an independent open developer, or a smart team should probably get to know TIDELIFT. They provide you benefits and, you know, capabilities as a developer and maintainer that are pretty unique and really help. And I've seen a number of our open source community embraced TIDELIFT quite honestly, even before they were part of the APN. But as part of the partner network, they get to participate in things like ISP accelerate and they get to they're officially an advanced tier partner because they are, they migrated the SAS offering onto AWS. But in the end, if you're part of the open source supply chain, you're a maintainer, you are a developer. I would recommend working with TIDELIFT because their goal is making all of you who are developing open source solutions, especially on AWS, more successful. And that's why I enjoy this partnership with them. And I'm looking to do a lot more because I think as a company, we want to make sure that open source developers don't feel like they are not supported because all you have to do is read various forums. It's challenging often to be a maintainer, especially of a small project. So I think with helping with licensing license management, security identification remediation, helping these maintainers is a big part of what TIDELIFT to us and it was great to see them as part of a partner network. Another partner that I like to call sysdig. I actually got introduced to them many years ago when they first launched. And one of the things that happened where they were super interested in some of our serverless stuff. And we've been trying to figure out how we can work together because all of our customers are interested in the capabilities that cystic provides. And over the last few years, he found a number of areas where we can collaborate. So sysdig, I know them primarily in a security company. So people use cystic to secure the bills, detect, you know, do threat response, threat detection, completely continuously validate their posture, get this continuous analytics signal on how they're doing and monitor performance. At the end of it, it's a SAS platform. They have a very nice open source security stack. The one I'm most familiar with. And I think most of you are probably familiar with is Falco. You know, sysdig, a CNCF project has been super popular. It's just to go SSS what 3, 37, 40 million downloads by now. So that's pretty, pretty cool. And they have been a great partner because we've had to do make sure that their solution works at target, which is not a natural place for their software to run, but there was enough demand and interest from our customers that, you know, or both companies leaned in to make sure they can be successful. So last year sister got a security competency. We have a number of specific competencies that we for our partners, they have integration and security hub is great. partners are lean in the way cystic has onto making our customer successful. And working with us are the best partners that we have. And there's a number of open source companies out there built on open source where their entire portfolio is built on open source software or the active participants like we are that we love working with on a day to day basis. So, you know, I think the thing I would like to, as we wind this out in this presentation is, you know, AWS is constantly looking for partnerships because our partners enable our customers. They could be with companies like Redis with Mongo, confluent with Databricks customers. Your default reaction might be, "Hey, these are companies that maybe compete with AWS." but no, I mean, I think we are partners as well, like from somebody at the lower end of the spectrum where people run on top of the services that I own on Linux and containers are SE 2, For us, these partners are just as important customers as any AWS service or any third party, 20 external customer. And so it's not a zero sum game. We look forward to working with all these companies and open source projects from an AWS perspective, a big part of how, where my open source program spends its time is making it easy for our developers to contribute, to open source, making it easy for AWS teams to decide when to open source software or participate in open source projects. Over the last few years, we've made significant changes in how we reduce the friction. And I think you can see it in the results that I showed you earlier in this stock. And the last one is one of the most important things that I say and I'll keep saying that, that we do as AWS is carry the pager. There's a lot of open source projects out there, operationalizing them, running them at scale is not easy. It's not all for whatever reason. It may not have anything to do with the software itself. But our core competency is taking that and being really good at operating it and becoming experts at operating it. And then ideally taking that expertise and experience and operating that project, that software and contributing back upstream. Cause that makes it better for everybody. And I think you'll see us do a lot more of that going forward. We've been doing that for the last few years, you know, in the container space, we do it every day. And I'm excited about the possibilities. With that. Thank you very much. And I hope you enjoy the rest of the showcase. >> Okay. Welcome back. We have Deepak sing here. We just had the keynote closing keynote vice-president of compute services. Deepak. Great to a great keynote, great wisdom and insight from that session. A very notable highlights and cutting edge trends and product information. Thanks for sharing. >> No, anytime it's always good to be here. It's too bad that we still doing this virtually, but always good to talk to you, John. >> We'll get hopefully through this way pretty quickly, I want to jump right in. Cause we don't have a lot of time. I want to get some quick question. You've brought up a good things. Open source innovation. Okay. Going next level. You've seen the rise of super clouds and super apps developing at open source. You're seeing big companies contributing, you know, you mentioned Argo into it. You're seeing that dynamic where companies are forming around this. This is a rising tide. This is, this is actually real. It's not the old school of, okay, here's a project. And then someone manages support and commercialization of it. It's actually platform in cloud scale. This is next gen. >> Yeah. And actually I think it started a few years ago. We can talk about a company that, you know, you're very familiar with as part of this event, which is armory many years ago, Netflix spun off this project called Spinnaker. A Spinnaker is CISED you know, CSED system that was developed at Netflix for their own purposes, but they chose to open solicit. And since then, it's become very popular with customers who want to use it even on prem. And you have a company that spun up on it. I think what's making this world very unique is you have very large companies like Facebook that will build things for themselves like VITAS or Netflix with Spinnaker and open source them. And you can have a lot of discussion about why they chose to do so, etc. But increasingly that's becoming the default when Amazon or Netflix or Facebook or Mehta, I guess you call them these days, build something for themselves for their own needs. The first question we ask ourselves is, should it be opensource? And increasingly we are all saying yes. And here's what happens because of that. It gives an opportunity depending on how you open source it for innovation through commercial deployments, so that you get SaaS companies, you know, that are going to take that product and make it relevant and useful to a very broad number of customers. You build partnerships with cloud providers like AWS, because our customers love this open source project and they need help. And they may choose an AWS managed service, or they may end up working with this partner on a day-to-day basis. And we want to work with that partner because they're making our customers successful, which is one reason all of us are here. So you're having this set of innovation from large companies from, you know, whether they are just consumer companies like Metta infrastructure companies like us, or just random innovation that's happening in an open source project that which ends up in companies being spun up and that foster that innovative innovation and that flywheel that's happening right now. And I think you said that like, this is unique. I mean, you never saw this happen before from so many different directions. >> It really is a nice progression on the business model side as well. You mentioned Argo, which is a great organic thing that was Intuit developed. We just interviewed code fresh. They just presented here in the showcase as well. You seeing the formation around these projects develop now in the community at a different scale. I mean, look at code fresh. I mean, Intuit did it Argo and they're not just supporting it. They're building a platform. So you seeing the dynamics of tools and now emerging the platforms, you mentioned Lambda, okay. Which is proprietary for AWS and your talk powered by open source. So again, open source combined with cloud scale allows for new potential super applications or super clouds that are developing. This is a new phenomenon. This isn't just lift and shift and host on the cloud. This is actually a construction production developer workflow. >> Yeah. And you are seeing consumers, large companies, enterprises, startups, you know, it used to be that startups would be comfortable adopting some of these solutions, but now you see companies of all sizes doing so. And I said, it's not just software it's software, the services increasingly becoming the way these are given, delivered to customers. I actually think the innovation is just getting going, which is why we have this. We have so many partners here who are all in inventing and innovating on top of open source, whether it's developed by them or a broader community. >> Yeah. I liked, I liked the represent container. Do you guys have, did that drove that you've seen a lot of changes and again, with cloud scale and open source, you seeing the dynamics change, whether you're enabling that, and then you see kind of like real big change. So let's take snowflake, a big customer of AWS. They started out as a startup too, but they weren't a data warehouse. They were bringing data warehouse like functionality and then changing everything differently and making it consumable for the cloud. And hence they're huge. So that's a disruption into an incumbent leader or sector. Then you've got new capabilities emerging. What's your thoughts, Deepak? Can you share your vision on how you have the disruption to existing leaders, old guard, if you will, as you guys call them and then new capabilities as these new platforms emerge at a net new functionality, how do you see that emerging? >> Yeah. So I speak from my side of the world. I've lived in over the last few years, which has containers and serverless, right? There's a lot of, if you go to any enterprise and ask them, do you want to modernize the infrastructure? Do you want to take advantage of automated software delivery, continuous delivery infrastructure as code modern observability, all of them will say yes, but they also are still a large enterprise, which has these enterprise level requirements. I'm using the word enterprise a lot. And I usually it's a trigger word for me because so many customers have similar requirements, but I'm using it here as large company with a lot of existing software and existing practices. I think the innovation that's coming and I see a lot of companies doing that is saying, "Hey, we understand the problems you want to solve. We understand the world where you live in, which could be regulated." You want to use all these new modalities. How do we allow you to use all of them? Keep the advantages of switching to a Lambda or switching to, and a service running on far gate, but give you the same capabilities. And I think I'll bring up cystic here because we work so closely with them on Falco. As an example, I just talked about them in my keynote. They could have just said, "Oh no, we'll just support the SE2 and be done with it." They said, "No, we're going to make sure that serverless containers in particular are something that you're going to be really good at because our customers want to use them, but requires us to think differently. And then they ended up developing new things like Falco that are born in this new world, but understand the requirements of the old world. If you get what I'm saying. And I think that a real example. >> Yeah. Oh, well, I mean, first of all, they're smart. So that was pretty obvious for most people that know, sees that you can connect the dots on serverless, which is a great point, but not everyone can see that again, this is what's new and and systig was just found in his backyard. As I found out on my interview, a great, great founder, they would do a new thing. So it was a very easy to connect the dots there again, that's the trend. Well, I got to ask if they're doing that for serverless, you mentioned graviton in your speech and what came out of you mentioned graviton in your speech and what came out of re-invent this past year was all the innovation going on at the compute level with gravitron at many levels in the Silicon. How should companies and open source developers think about how to innovate with graviton? >> Yeah, I mean, you've seen examples from people blogging and tweeting about how fast their applications run and grab it on the price performance benefits that they get, whether it's on, you know, whether it's an observability or other places. something that AWS is going to embrace across a compute something that AWS is going to embrace across a compute portfolio. Obviously you can go find EC2 instances, the gravitron two instances and run on them and that'll be great. But we know that most of our customers, many of our customers are building new applications on serverless containers and serveless than even as containers increasingly with things like foggy, where they don't want to operate the underlying infrastructure. A big part of what we're doing is to make sure that graviton is available to you on every compute modality. You can run it on a C2 forever. You've been running, being able to use ECS and EKS and run and grab it on almost since launch. What do you want me to take it a step further? You elastic Beanstalk customers, elastic Beanstalk has been around for a decade, but you can now use it with graviton. people running ECS on for gate can now use graviton. Lambda customers can pick graviton as well. So we're taking this price performance benefits that you get So we're taking this price performance benefits that you get from graviton and basically putting it across the entire compute portfolio. What it means is every high level service that gets built on compute infrastructure. And you get the price performance benefits, you get the price performance benefits of the lower power consumption of arm processes. So I'm personally excited like crazy. And you know, this has graviton 2 graviton 3 is coming. >> That's incredible. It's an opportunity like serverless was it's pretty obvious. And I think hopefully everyone will jump on that final question as the time's ticking here. I want to get your thoughts quickly. If you look at what's happened with containers over the past say eight years since the original founding of the first Docker instance, if you will, to how that's evolved and then the introduction of Kubernetes and the cloud native wave we're seeing now, what is, how would you describe the relationship between the success Docker, seeing now with Kubernetes in the cloud native construct what's different and why is this combination so successful? >> Yeah. I often say that containers would have, let me rephrase that. what I say is that people would have adopted sort of the modern way of running applications, whether containers came around or not. But the fact that containers came around made that migration and that journey is so much more efficient for people. So right from, I still remember the first doc that Solomon gave Billy announced DACA and starting to use it on customers, starting to get interested all the way to the more sort of advanced orchestration that we have now for containers across the board. And there's so many examples of the way you can do that. Kubernetes being the most, most well-known one. Here's the thing that I think has changed. I think what Kubernetes or Docker, or the whole sort of modern way of building applications has done is it's taken people who would have taken years adopting these practices and by bringing it right to the fingertips and rebuilding it into the APIs. And in the case of Kubernetes building an entire sort of software world around it, the number of, I would say number of decisions people have to take has gone smaller in many ways. There's so many options, the number of decisions that become higher, but the com the speed at which they can get to a result and a production version of an application that works for them is way low. I have not seen anything like what I've seen in the last 6, 7, 8 years of how quickly the most you know, the most I would say is, you know, a company that you would think would never adopt modern technology has been able to go from, this is interesting to getting a production really quickly. And I think it's because the tooling makes it So, and the fact that you see the adoption that you see right and the fact that you see the adoption that you see right from the fact that you could do Docker run Docker, build Docker, you know, so easily back in the day, all the way to all the advanced orchestration you can do with container orchestrator is today. sort of taking all of that away as well. there's never been a better time to be a developer independent of whatever you're trying to build. And I think containers are a big central part of why that's happened. >> Like the recipe, the combination of cloud-scale, the timing of Kubernetes and the containerization concepts just explode as a beautiful thing. And it creates more opportunities and will challenges, which are opportunities that are net new, but it solves the automation piece that we're seeing this again, it's only makes things go faster. >> Yes. >> And that's the key trend. Deepak, thank you so much for coming on. We're seeing tons of open cloud innovations, thanks to the success of your team at AWS and being great participants in the community. We're seeing innovations from startups. You guys are helping enabling that. Of course, they want to live on their own and be successful and build their super clouds and super app. So thank you for spending the time with us. Appreciate. >> Yeah. Anytime. And thank you. And you know, this is a great event. So I look forward to people running software and building applications, using AWS services and all these wonderful partners that we have. >> Awesome, great stuff. Great startups, great next generation leaders emerging. When you see startups, when they get successful, they become the modern software applications platforms out there powering business and changing the world. This is the cube you're watching the AWS startup showcase. Season two episode one open cloud innovations on John Furrier your host, see you next time.

(bright music) >> Hi, everyone. Welcome to the CUBE's presentation of the AWS Startup Showcase around open cloud innovations. It's the season two episode one of the ongoing series covering exciting startups from the AWS ecosystem and talking about open source and innovation. I'm John Furrier, your host. Today, we're joined by two great guests. Dan Garfield, chief open source officer and co-founder of Codefresh IO, and Raziel Tabib, CEO and co-founder. Two co-founders in the middle of all the innovation. Gentlemen thanks for coming on. >> Thank you. >> So you guys have a great platform and as cloud native goes mainstream in the enterprise and for developers, the big topic is unification, end-to-end, horizontally scalable, leveraging data. All these things around agile that I call agile cloud next level. This is kind of what we're seeing. The CNCF is growing. You've seen KubeCon every year is more about these kinds of things. Words like orchestration, Kubernetes, container, security. All of those complexities are now at the center of making things easier for developers. This is a key value proposition and you guys at Codefresh are offering really the first enterprise delivery solution powered by Argo, which is an open source project. Again, open source driving really big changes. So let's get into it. And first of all, congratulations, and thanks for working on this project. What's so special about- >> Thank you for that. >> Argo the project, and why have you guys decided to build a platform on it, and where is this coming together? Take us through why this is so important. >> I think Argo has been a very fast growing open source project for multiple reasons. A, it has been built for the new way of building and deploying an application. It's cloud native. You mentioned Kubernetes becoming kind of the de facto way of running application. It's the de facto way to run automation and pipeline. But also Argo has been built from the ground up to the latest practices of how we deploy software. We deploy software now differently. We deploy it using a GitOps practice. We're deploying it using canary blue-green progressive deployment. And Argo has been built around these practices, around these technologies, and has been very much widely adopted by the community. In the past, the KubeCon you've mentioned, Argo was all over the place. And we were very glad to be working with the community to talk about what the next steps with Argo. >> Yeah, it's a really good point. I would like to just follow up on that because you see this being talked about. It always comes up, where is open source really outside of a pure contributors matter? And when you have corporations contributing, you seeing this has been the trend. You saw it with Lyft, with Envoy, companies doing more and more open source. This is part of a big collaboration. And again, this comes back down to this whole why it's relevant and why it's so special with Argo. Continue to talk about relationship because it's not just you guys, it's now community. >> Yeah, I can speak to that. The Argo project is something that we maintain in partnership with several other companies and really our relationship with it is that this is something that we're actively contributing to. This is something that we're helping build the roadmap on and planning the events around and all those kinds of things. And we're doing that because we really believe in this technology and we've built our platform on it. So when you deploy Codefresh, you're deploying technology that's built directly on Argo and is designed specifically to solve that problem that you spoke to at the top of the hour. We all want to deliver software faster. We all want to have fewer regressions. We want to have fewer breaking changes. We want software to be super reliable. We want to be comfortable with what we're doing. That's really why we picked Argo because that technology that we have it is to Raziel's point delivered in this new way. It's delivered using GitOps. And that's a whole revolution and change in the way that people build and deploy software. And bringing cohesion into that experience is so critical to building the confidence that lets you actually deploy often and frequently and more. >> Dan, if you don't mind just expanding on that one point about the problem you solve, because to me, this has been kind of that evolution. It's almost like, yeah, there's been problems, plural, and opportunities that you saw with those in growing markets like this with DevOps and DevSecOps and now cloud native. What is the catalyst behind all of this? What was the epiphany behind it? How did it get so much momentum? What was it really doing under the covers? >> Well, it's a very simple and easy to use set of tools. And that's one of the big things is that if you look at the ideas of GitOps and there's actually a foundation around this that were part of called open GitOps to GitOps working group under the CNCF. And those principles of, I want to, yes, do my software defined as code. I want to do my infrastructure defined as code and I need something monitoring by production run times and making sure that the declared desired state is always matching the actual state. Those principles have actually been around for a number of years. And with Kubernetes, we really unlocked an API that allowed us to start doing GitOps and this is why we bring in Argo and you see the rise of Argo CD and other workflows and what we've been doing is really because that technology has been unlocked now. So the ability to define how your software is supposed to run and now your entire software delivery stack should run, all defined and then monitored and then kept in check using the GitOps operator. That critical unlock is what's really driving the massive adoption. And like Raziel said, Argo is the fastest growing and most popular open source project for delivering software. And it's not even close. >> Yeah, this is really great point. And I want to get into that 'cause I want to know why, what you guys do on your platform versus the open source and get that relationship settled? Before we get there, though, I want to get your reaction to some of the commentary in the industry 'cause GitOps trend has been exploding into new directions. I mean, it used to be a term about 10 years ago called big data. And at the beginning where data was all big data. Now it was DevOps revolution around data as well. But now you're hearing people talk about big code. Like, I mean, the code bases are becoming so huge. So as a developer, you're leveraging large open source code. This idea of the software delivery with existing code and new code just adds to more code. There's more code being developed every day. >> There is more code delivered every day. And I think that organization realize today, almost in every industry that they have to pace up how fast and how frequent they update their software delivery. We're living in a world in which every aspect of our life has been disrupted by software and organization realize that they have to keep up and figure out how to deploy software more frequent and more lively. And I think, you mentioned that really Kubernetes, the cloud native became the de facto way of running application. I think most of organization has made that decision to move into cloud native. The second question is after, is okay, now we have all applications running, how fast and how more frequent we can deploy applications to the cloud native? And that's the stage in which we're super excited about Argo and our up platform because that's basically streamline the building application for these cloud native, deploying applications for the cloud native, and so on. >> Yeah, and I think that highlights the business value. You getting a lot of the conversations with businesses that say they want the modern application on the cloud scale. And at the end of the day, it comes down to speed and security. So how fast can I get the app out? How well does it work? Does it run performance? And does it have security? And I don't want a slow. >> Exactly. Exactly. It kind of oversimplifies it, but that's kind of the net net. So when you look at Argo open source, what's that's done and kind of where you guys are taking it. Can you talk about the differences between your enterprise version and the open source version and the interplay there, the relationship, the business model health customers can play on both sides or understand the difference? >> Sure. >> Go ahead. >> Go ahead, Raziel. Okay, so I think Argo, as you mentioned, is probably the most advanced technology today to both run pipelines. They're like events to trigger pipelines and Argo work for the one that pipelines, the Argo CD for GitOps and Rollout, for Canary blue-green strategies. And the adoption is really exploding. Just as an Advocate that we had in December, we have worked with the community and organized ArgoCon events in which we had initially kind of thought about 500 attendees. And so we have more than 4,000 registrants and majority of them are coming from enterprise. Now as we have talked to the community during this conference and figure out, okay, so what are the things that you're still missing? And that will help you take the benefit that you get from Argo to the next level. The few things that came up. One is Argo is a great technology. However, Argo now is fragmented into four projects. There is an advance. There is workflow. There is Argo CD. And there is Argo Rollout. And there is a need to bring them all together into a solid platform, solid one run time that can be easily installed, monitor all of these in a single UI, in a single control plane. That's one aspect. The second is the scalability. Really being able to manage it centrally across multiple clusters, not in one cluster. And what we bring in with the new one, we're so excited about this platform, is we're bringing that big. The first to get all of these four projects in one runtime, and one control plane, but also allow the community to run it across multiple cluster from one place getting into the solution, not just as a technology. >> If I may add to that, the value of bringing these projects together, it provides so many insights. So when you're trying to figure out, there's some breaking change that has been made, but you don't necessarily know where it is because you have a lot of microservices that are out there. You have a lot of teams working on it. By bringing all of these things together, we're able to look at all of the commits, all of the deployments, all of the Jira issues. All of these components combined together, so you really get a single view where you can see everything that's going on. And this is another element where when you're trying to deploy software at scale, you're trying to deliver it faster. People are getting a little bit overwhelmed because there are so many updates and so many different services and so many teams working that they're starting to miss that visibility. So this is what we want to bring into the ecosystem is we really want them that visibility to be super clear. And by bringing all of the Argo components, the Argo tools together, we're able to do that in a single dashboard. >> Yeah, so if I get this right, let me just double click on that because it sounds like, yeah, Argo's great. It's been organically growing, a lot of different components to it, but when you start getting into pushing code in an organization, you have, I call the old-school version control kind of vibe going on where it's like you don't know what's out there and how that affects the system as it's a distributed system, which cloud is. There are consequences when stuff breaks. So we all know that. Is that kind of where you guys are getting at? The challenge is actually the opportunity at the same time where it's all goodness, but then when you start looking at scale and the system impact, is that kind of where the open source and you guys pick up, is that right? >> This is one aspect. I think the second one is that again, when you look at each individual component of Argo, each provide a lot of value by itself. But when you sum it, the value of the sum is greater than the value of the individual. So when you're taking, really the events and workflow, Argo CD and Argo Rollout, and you bring them all together into single runtime. The value of its time is really automation all the way from code to cloud. It's not breaking into, there is like an automation for CI, there's an automation for CD, there's information for progressive delivery. It's actually automated all the way from the Git commit through the GitOps through the deployment strategy, and so on. And being able to monitor it and scale it in the enterprise scale. So, of course, it's helping enterprise and make Argo to some level more crucial for enterprise, if I may say, but second is really bringing all of these components together and get the outcome be greater than the individual parts. >> Yeah, that's a good point. Yeah, make it make a commercial grade, if you will, for enterprise who wants to have support and consistency and whatnot. What other problems are you solving? Dan, can you chime in on the whole, how you guys resolve some of these challenges for the enterprise? Because, again, some stability is key as well, but also the business benefit has got to be there for the development teams. >> Yeah. So there's several. One aspect is that the way that most people operate today is they essentially do a bunch of commands and engage with systems. And then hopefully at the end, they write those things to Git. And this is a little bit backwards if you think about it because there's a situation where you can end up with things in production that were never checked in, or maybe somebody is operating and they're making a change. If we look at most of the downtime that's occurred over the last two years, it's because people have flubbed a key when they were typing in a command or something like that. The way that this system works is that we provide an interface, both the CLI and the GUI, where those operations interactions actually end with a Git commit. So rather than doing an operation and then hopefully committing to Git, most of the operations are actually done first in Git, or if there is something that can't be done first in Git, it's maybe bootstrapped and then committed to Git as part of a single command. So this means you have end-to-end traceability. It also means your auditability is way better. And then the second, the other component that we're adding is that security and scale layer. So we are securing these things, we're building in single sign-on, and all those robust security things you would expect to have across all these instances. So many organizations, when they're building their software delivery tools, they have to deploy instances in many locations. And so this is how you end up with companies that have 5,000 instances that are all out of date and insecure. Well with Codefresh, if you need to deploy a component onto this end cluster or something like that, you may have thousands of them. All of those are monitored and taken care of in a centralized way, so I can do all of my updates at once. I can make sure they're all up to date. I'm not running with a bunch of known CVEs or something like that and it's clear. The components are also designed in an architectural way. So that only the information that is needed is ever passed out. So I can have a cluster that is remotely managed, that checks out code, that the control plane never has access to. So this hybrid model has been really popular with our customers. We have customers in healthcare, we have customers in defense and in financial services, all these regulated industries. The flow of information is really critical. So this hybrid model allows you to deploy something that has the ease of a SaaS solution, but has the security of an on-prem solution while being centrally managed and easy to take care of. >> Yeah, it's a platform. It's what it is. It's not a tool. It's not a tool anymore. It's a platform. >> Exactly. >> I think the foundational aspect of this is critical. And you mentioned automation before. If you're going to go end-to-end automation, you have some stuff in the system that whether it hasn't been checked in yet. I mean, we know what this leads to. Disaster or a lot of troubleshooting and disruption. That's what it seems to solve. Am I getting that right? Is that right? >> Yeah. >> Go ahead. >> Yeah, it helps automate the whole process. But as you say, it's really like identify what needs not to be going all the way to production and really kind of avoid vulnerabilities or any flaws in the software. So it automates everything, but in a way that the automation can identify issues and avoid them from coming into the production. >> Well, great stuff here. I've got to ask you guys now that you've got that settled. It's really, I see the value there, how you guys are letting it grow organically and with Argo and then building that platform for businesses and developers. It's really cool. And I see the foundational value there. It just only gets better. How you guys contributing back to open source and helping the wider GitOps and Argo communities? Because this is, again, the rising tide that's bringing all the boats into the harbor, so to speak. So this is a good trend and people will acknowledge that. So how's this going to work as you guys work back into the open source community? >> So we work closely with both myself and the other maintainers worked closely with the community on the roadmap and making sure that we're addressing issues. I think if you look in the last quarter, we probably have upwards of 40 or 50 different issues that we've solved in terms of fixing a bug or adding features or things like that. So making sure that these tools, which are really the undergirding components of our platform, they have to be really robust. They have to be really strong. And so we're contributing those things back. And then when it comes to the scalability side, these are things that we can build into the platform. So the value should be really clear. I can deploy this, I can manage it myself, I can build tools on top of it. And if I want to start doing it at scale, maybe I want support. That's when I really am going to go to Codefresh and start saying, let's get the enterprise little platform. >> Awesome. GitOps, a lot of people like some naysayers may say, Hey, it's the latest fad. Is it here to stay? We were talking about big code earlier. GitOps, obviously seeing open source. Just every year, just get better and better and growth. I mean, I remember when I was breaking into the business, you have to sell under the table. Now it's all free and open and getting better every year. Just the growth of code. Is GitOps a fad? How do you talk to people who say that? I mean, besides slapping around saying wake up. I mean, how do you guys address that when people say it's just the latest fad? >> So if I may comment here and Dan feel free to chime in, I think that the GitOps is a continuation of a trend that everything is a source code. As a developer, many years ago myself and still writing code, always both code and code was the source of tool that's where we write the code. But now code actually is also describing how our application is running in production. And we've already seen kind of where it's get next. We also hear about infrastructure as a code. So now actually we storing the code the way the infrastructure should be. And I think that the benefit of storing all this configuration in a source code, which has been built to track changes, to be enabled to roll back, that is just going to be here to stay. And I think that's the new way of doing things. >> All right, gentlemen, great. Closing statements. Please share an update on the company. What it's all about? What event you got coming? I know you got a big launch. Can you take us through? Take us home. >> Join on February 1st, we're going to be launching the Codefresh software delivery platform. Raziel and I will be hosting the event. We've got a number of customers, a number of members of the community who are going to be joining us to show off that platform. So you're going to be able to see it in action, see how the features work, and understand the value of it. And you'll see how it works with GitOps. You'll see how it helps you deliver software at scale. That's February 1st. You can get information at codefresh.io. >> Raziel, Dan, thanks for coming on. >> Thank you. >> Pretty good showcase. Thanks for sharing. Congratulations. Great venture. Loved the approach. Love the growth in cloud native and you guys sure on the cutting edge. Fresh code, people love fresh code, codefresh.io. Thanks for coming on. >> Thank you. Thank you. >> Okay, this is the AWS Startup Showcase Open Cloud Innovations. Cloud scale, software, data. That's the future of modern applications being developed, changing the game to the next level. This is the CUBE's coverage season two episode one of the ongoing AWS Startup series here in theCUBE.

(upbeat music) >> Welcome back to theCUBE's continuous coverage of AWS re:Invent 2021 I'm Lisa Martin. This is our third day here on set We've got two live sets, two remote studios, over a hundred guests on the program and a lot going on with AWS and its ecosystem of partners am pleased to welcome back one of our Cube alumni, Buddy Brewer, the GVP & GM of product partnerships at New Relic. Welcome back, Buddy. Good to have you. >> Thanks it's great to be here >> Great to be in an in-person event isn't? >> No kidding it's really amazing to see everybody out here and after spending so much time on zoom calls, we had a lot of really great moments among the team and the booth playing the game of seeing if people's height matched up with >> (laughs) >> What your expectation was because so many of the people we work with >> Never mind. >> We've only known over zoom. >> Yes ,and zoom has been a savior for all of us we've been doing so much recording on zoom at the same time it's great to be here in person and seeing what a safe job AWS has done with getting I from hearing upwards of 30,000 people in here that are here in person. So talk to me about you lead the technology partnerships at New Relic. Talk to me about your role, and then we'll get into the partnership with AWS. >> Yeah, absolutely. Well, you know, the point about zoom, it's fascinating. Like you said, that just having the ability to communicate with people has been such a key enabler of being able to make progress and to continue to lead our personal and our professional lives despite the pandemic I mean, imagine what it would have been like if this had happened 10 years ago, even, but certainly 50 years ago >> Right. or something like that, right? Like everything would have ground to a halt and technology took on such an amazing, you know, critical role in allowing us to do all of these things and so at New Relic, we're all about helping people make sure that all of this software works correctly. And so observability helps people understand the detail level about everything from the front end, the end user experience to every single piece that happens along the path of delivering that experience all the way down to the infrastructure into the network. But my role at New Relic is also to help all of the other tools that software developers use every day to create those experiences that they connect into their observability platform so that they can understand all of those details and make sure that people are able to continue doing things that have become really so basic to life like ordering groceries or getting food, or, you know, communicating with a loved one over something like zoom. >> Yeah the things that to your point, if this had happened, you know, five, 10 years ago, it would have been a completely different story. We've been able to function really well and one of the things too, that, you know, I noticed yesterday and today, you probably did as well with the plethora, typical AWS the plethora of announcements, the amount of innovation that's going on, the customer flywheel that we've just seen this acceleration of technology and what it's enabling, but the observability portion is really key you talk about, you know, the developers need to the whole SDLC they need to be able to understand exactly what's going on because at the end of the day, whether it's a consumer or an enterprise of the other end of the spectrum, we need to know exactly what's going on because people's patience is far thinner these days the pandemic showed is that there is really no having access to real-time data. Isn't a luxury anymore it's really a necessity. >> Right, yeah, absolutely. >> Talk to me about some of these so a lot of announcements coming up from AWS, you guys talk to me about the partnership, what you guys are doing there. And some of the things that are exciting on that front. >> Yeah, AWS is a really key partner for us. We're big users of AWS ourselves for our observability platform and all of our infrastructure and, you know, we've had our own journey as a 13 year old business that started out pre cloud and moving our own infrastructure to the cloud. And then along that journey, we've worked closely with AWS and we've built a lot of joint solutions to help people who are moving to the cloud themselves or who are cloud native to understand all of the details about what's happening in that software so we have over 60 different integrations to all of the different tools with Amazon that you can use on the cloud from data storage, to EKS on Fargate and all of that stuff. And then we recently announced a five-year strategic agreement with Amazon to make it even easier for customers to adopt New Relic if they're building in Amazon AWS and so you know, we're in their marketplace, we have an offering for startups, for people who are just getting started that, you know, provides really simple and fast on-ramps with discounts and things like that. That's all designed to help people, software developers in particular, focus on what matters most to them, which is building great experiences for their customers. You know, you mentioned that the SDLC and this is one of the things that, you know, our mission at New Relic is to make observability a daily data-driven habit for developers across all phases of the software delivery life cycle. The problem with observability and how it's used today is that it's only used in the run phase by most people they use it when the software is on fire to put the fire out we believe that, that telemetry has tremendous strategic value in the plan, build and deploy phases of software development as well. And so partnerships like AWS allow us to unlock the accessibility of that data across all of those different phases for people who software developers are as a result in many ways that the things that we were talking about earlier with the expectations that the pandemic has placed on how software has to work, it's not an option they're busier, they're under more pressure than they've ever been before and so we want to help them relieve that pressure with tools that help them do their jobs better. >> Relieving that pressure is key there is so much pressure on developers I mean, these days from observability to security and that sort of thing, but it sounds like one of the things that you're also fundamentally doing is really shifting that observability left and helping them from a cultural perspective, it seems like almost a shift, but you're trying to make things easier for them giving them more tools and to unlock what they're not seeing right now. >> That's right and you know, the interesting thing about it is everyone realizes that observability is critical to, you know, successful software businesses so for example, we did a survey recently of 1300 software developers and IT decision makers and executives, and found that among the C-level executives that were surveyed 80% of them expected to increase their observability budget and 20% of those expected to increase it significantly. However, that same survey found that a very small percentage of those who we actually surveyed feel that they have a mature observability practice today. And when we unpack the reasons why in the survey, we found that most of them reduce down to basically this issue of they just don't have enough time to instrument all of the software, especially in a world where the shift to the cloud has driven a change in architecture where monoliths have been torn down and replaced by hundreds, or may be even thousands of microservices. >> Right. >> And we're in an era now where if observability isn't really, really easy and incredibly fast and simple to execute on then software developers can no longer instrument fast enough to keep up with the pace of the software that they're delivering and so what that leads to is visibility gaps, visibility gaps lead to poor customer experiences. And so what we're trying to do, and we've been on this massive simplification of our own platform to make it, you know, incredibly cost-effective at just 25 cents a gigabyte for ingestion and really simple licensing seat based licensing, where you get access to all of our tools to make it really simple and to take simply minutes to get observability on all those different pieces. >> If simplicity is a word that we throw around a lot, but it's really critical element and it's interesting to understand how do you actually facilitate that? You talked about, you know, kind of the 80 20 rule there. >> Yeah. >> A lot of the organization's not on that maturity curve with observability, how does New Relic and its ecosystem of partners like AWS how do you help have those conversations within organizations in any industry tell them, understand how you can actually simplify that and unlock that visibility, knowing that it's not only a matter of software development, but it's a competitive differentiator. It's also something that can damage a brand if they're not top of it. >> Yeah, we launched a re-imagined version of our partner ecosystem really our entire integration ecosystem about six weeks ago on October 13th called New Relic Instant Observability. And one of the central goals of New Relic IO, which we call it for short is to make it take just like five minutes for people to instrument something. So in the old way, what people had to do is if they wanted observability, they had to go learn about an observability vendor then they had to go install it, figure out how all that works and then they could get to solving their problem, which might've just been simply instrumenting a Kafka you know and so what we want to do is just keep people in that mode if all you wanted to do is instrument Kafka, then go find the Kafka instrumentation tile on New Relic and observability and then there's a guided install process that takes you through that and at the end you've instrumented Kafka and if you want to add something else like EKS Fargate from Amazon, or if you want to add something else like a Java service, you can simply click more of those guidance installs and add within minutes in an incremental way without having to stop and do a whole vendor evaluation to do so in fact, one of the other things that we launched recently is a free tier that's free forever. So there's no trial process or anything you don't have to put in a credit card if all you want to do is instrument this one thing right now, you can go through this process provision a free account you get access to all of our functionality for one user and ingest up to a hundred gigabytes of telemetry data for free within minutes. And so what we're trying to do is take all of that adoption friction out so that people aren't fighting with their instrumentation so much, and again, they can get back to doing what they really want to do in the first place, which has built great experiences for their end users. >> Great experiences for the end users but that translates to employee experience that translates to an end user customer experience, which translates back to brand reputation. I'm just wondering, you know, you're focused on the developers and we've been hearing a lot about the last two and a half days, a big focus on developers has observability kind of escalated up and its evolution up the stack within organizations is this a C-suite concern? Is this a board level concern? where does this fit now? and what's the vision of New Relic to deliver on that? >> With observability? >> Yes. >> Yeah, 90% of those in the survey that I was talking about felt that observability was not just a tool that they needed to use, but strategically critical to their business and, you know, this goes back to, as we know, and especially as a result of the intensity on the importance of software coming out of the pandemic, your digital business is your business these days. And so if you don't understand what's happening in that software and you can't move quickly, then you know you're really in trouble in terms of trying to succeed in a highly competitive environment and that goes back to again, one of our core beliefs is that all of this telemetry data that people have been collecting about how their software operates is so useful in contexts outside of just when there's a problem in production. Imagine if you could take that information and you could actually put it inside the IDE, which is something that we did with a recent acquisition of a company called CodeStream. We can take this telemetry data and put it inside the IDE so that as developers are writing the software, they know where those issues are. You can click straight from a stack frame, for example, inside of our, where we show all of our errors in a capability called Error's inbox and shoot right into your IDE and go see where the line of code is that caused that error, shortening that feedback loop and unlocking this really big investment that a lot of companies make in telemetry data earlier in the software life cycle, we believe is the future of observability and we want to help people get there. >> Well, the observability is really key for organizations these days because we've been hearing every company these days has to be a data company. >> Yeah. >> And it's one thing to say that it's a whole other thing to be able to implement it and observability is absolutely critical to that as being able to take that data and apply it in different contexts to really enable that business to be digital which is absolutely table-stakes these days to be successful and to deliver that customer experience ultimately. >> Yeah. >> That's what it all do. >> Yeah, absolutely. And you know, the other thing is really hard about this problem when I talk with our customers and we found this in the survey as well, is that, you know, software developers, don't just use one tool to create software they use a lot of tools in fact, 13% of those that we surveyed use 10 or more tools. >> Whoa. >> Just for the observability piece. And so, you know, obviously we're always trying to expand organically what we do inside of our platform to cover more and more use cases, but an equally important part of our strategy, if we really want to make observability a data-driven daily habit for people is to find all of those other, you know, really well-built amazing tools that those developers use and find valuable ways to integrate with them. And so that's the other part of our ecosystem that we've built out is this ability to take all of the other tools that you use and wire them into New Relic so that, for example, if you're using, let's say Lacework for security then you can, you know, if someone's installed a Bitcoin miner on your infrastructure somewhere, you can quickly navigate because of that integration from a poor customer experience through the infrastructure that's suffering may be with, you know, a lot of memory pressure, and a lot of CPU being used for this Bitcoin miner and then find out that, you know, through the integration where the miner was installed, how it got installed so that you can remediate those types of issues and connecting those pieces together, making software truly interoperable is another thing that's really critical to our mission at New Relic. >> It is critical to not only to the developers, but to the organizations and their success as businesses these days Buddy thank you for joining me, talking about what's going on at New Relic What's new, how you're really empowering those developers and all of the downstream positive effects that, that leads to we appreciate your time. >> Thank you ,thanks for having me. >> All right, you are Buddy Brewer I'm Lisa Martin you're watching theCUBE, the global leader in live tech coverage. (soft music)

>> Welcome everybody to this cube conversation. My name is Dave Vellante and we're joined today by Richard Goodwin, who's the group director of IT at Ultraleap and Avishek Kumar, who manages Dell's Power Store, product line, he directs that product line along with several other lines for the company. Gentlemen, welcome to the cube. >> (Avishek) Hi Dave. >> (Richard) Hi >> (Dave) So Richard, Ultraleap, very cool company tracks hand movements, and so forth. Tell us about the company and the technology I'm really interested in how it's used. >> Yeah, we've had many product lines, obviously. We're very innovative, and the organization was spun up from a PhD, a number of PhD students who were the co-founders for Ultraleap, and initially with mid-air haptics, as you, as many people may have seen, but also hand tracking, mid-air touch, sense and feel. So, yeah, it's, it's, it's quite impressive what we have produced and the number of sectors and markets that we were in. And obviously to, to push us to where we are, we have relied upon lots of the Dao technology, both software and hardware. >> (Dave) And what's your role at the company? >> I'm the group IT director, I'm responsible for the IT and business platforms, all infrastructure, network, hardware, software, and also the transition of those platforms to ensure that we're scalable. And we are able to develop our software and hardware as rapidly as possible. >> (Dave) Awesome. Yeah, a lot of data behind that too I bet. Okay Avishek, you direct a number of products at Dell across the portfolio, Unity, Extreme IO, the SC series, and of course power vault. It's quite the portfolio that you look after. So let's get into the case study, if we can, a bit, Richard, maybe you could paint a picture of, of your environment, some of the key applications that you're supporting and maybe what your infrastructure looks like. Give us a high level view. >> Sure. So, pre Power Store, we had quite a disparate architecture, so a fairly significant split and siding on the side of the cloud, not as hybrid as we would like, and not, not as much as on-prem, as we would have liked, and hey, but that's changed quite significantly. So we now have a number of servers and storage and storage arrays that we have on, on-premise, and then we host ourselves. So we are moving quite rapidly, you know as a startup and then moving to a scale-up, we needed that, that scalability and that versatility, and also the whole OPEX versus CAPEX, and also not being driven by lots of SaaS products and architecture and infrastructure, where we needed to be in control because of our development cycles and our products, product development. >> (Dave) So wait, Okay, So, so, too much cloud. I'm hearing you wanted a little bit a dose of on-prem, explain that a little bit more, the cloud wasn't doing it for you in terms of your development cycle, your control. Can you double click on that? >> Yeah. Some of the, some of the control and you know, there's always a balance because there's certain elements of our development cycles and our engineering, software engineering, where we need a very high parallelism for some of the work that we're doing, which then, you know, the CAPEX investment makes things very, very challenging, not commercially the right thing to do. However, there are some of our information, some of IP, some of the secure things that we do, we also do not want upgrades as an example, or any advantages or certain types of server and spec that we need to be quite and unique and that needs to be within our control. >> (Dave) Got it, Okay. Thank you for that. Avishek, we're going to talk about Power Store today. So set it up, please, tell us about Power Store, what it is, you know, why it's important to this conversation. >> Sure. So Power Store is a product that we launched may of 2020, roughly a little bit more than a year now. And it's a brand new architecture that Dell technologies released. And at the end of the day, I'll talk about a few unique aspects of the product, but at the end of the day, where we start with, it's a storage platform, right? So where we see similar to what Richard is saying here, in terms of being able to consolidate the customer's environment, whether it is blog, file, WeVaults, physical, virtual environments, and, and it's, as I said, it's a brand new architecture where we leveraged pieces of existing products, where it made sense, we are using all the latest and greatest technologies delivering the best performance based data reduction. And where we see a lot of traction is the options that it brings to the table for our customers in terms of flexibility, whether they want to add capacity, compute, whether in fact, we have apps on the deployment model where customers can consolidate their compute as well on the static storage platform with needed. So a lot of innovation from a platform perspective itself, and it's not just about the platform itself, but what comes along with it, right? So we refer to it as an ecosystem, part of it, where we work with Ansible playbooks, CSI plugin, you name it, right. And it's the storage platform by itself, doesn't stand by itself in a customer's environment, there are other aspects of the infrastructure that it needs to integrate with as well. Right? So if they are using Ansible playbooks, we want to make sure the integration is there. >> (Dave) Got it. >> And last, but perhaps not the least is the intelligence built into the platform, right? So as we are building these capabilities into the product, there is intelligence built into the product, as well as outside the product where things like Cloud IQ, things like technologies built into power suit itself makes it that much easier for the customers to manage the infrastructure and go from there. >> (Dave) Thank you for that, So, Richard, what was the workload? So it actually, you started with the sort of a Greenfield on-prem. If I understand it correctly, what was the workload that you were sort of building around or workloads? >> So, we had a, a number of different applications. Some of which we cannot really talk about too much, but we had, we had a VxRail, we had a a smaller doubt array and we have lots of what we class as runners, Kubernetes cluster that we run and quite a few different VMs that run on our, on-prem server infrastructure and storage arrays and the issues that we began to hit because of the high IO, from some of our workloads, that we were hitting very high latency, which rapidly stopped, began to cause us issues, especially with some of our software engineering teams. And that is when we embarked upon a competitive RFP for Dell Power Store, Dell were already engaged from an end-user compute where they'd been selected as the end-user compute provider from a previous competitive RFP. And then we engaged them regarding the storage issue that we had and we engaged the, our account lead and count exec, and a number of solution architects were working with us to ensure that we have the optimal solution. Dell were selected over the competitors because of many reasons, you know, the new technology, the de-duplication, the compression, the data, overall data reduction, and the guarantee that also came, came with that, the four-to-one data reduction guarantee, which was significant to us because of their amounts of data that we hold. And we have, you know, as I've mentioned, we're pulling further, further data of ours back into our hosted environments, which will end up on the Power Store, especially with the de-duplication that we're now getting. We've actually hit nine-to-one, which is significant. We were expecting four-to-one, maybe five-to-one with some of the data types. And what was excellent that we were that confident that they did not even review our data types prior, and they were willing to stand by that guarantee of four-to-one. And we've excelled that, we've got significant different data types on, on that array, and we've hit nine-to-one and that's gradually grown over the last nine months, you know, we were kind of at the six then we moved to seven and now we're hitting nine-to-one ratio. >> (Dave) That's great. So you get a little free storage. That's interesting what you're saying, Richard, cause I just assumed that a company that guaranteed four-to-one is going to say okay, let us, let us inspect your workload first and then we'll do the deal. So Avishek, what's the tech behind that data reduction that you're able to, with such confidence, not have to pre inspect the workload in this case anyway. >> Yeah. So, it goes back to the technologies that goes behind the product, right? So, so we, we stand behind the technology and we want to make it simpler for our customers as well where, again we don't want to spend weeks looking at all the data, scanning all the data before giving the guarantee. So we stand behind the technology where we understand that as the data is coming in, we are always going to be de-duplicate it. We are always going to compress it. There is technology within the product where we are offloading some of that to the outside the CPU, so it is not impacting the performance that the applications are going to see. So a data reduction by itself is not good enough, performance by itself is not good enough. Both of them have to be together, right? So, and that's what Power Store brings to the table. >> (Dave) Thank you. So Richard, I'm interested. I mean, I remember the Power Store announcement of, sort of, saw it leading up to it. And one of the big thrusts from Dell was the way I phrase it is essentially trying to create a cloud like experience on-prem. So really focused on simplicity. So my question to you is, let's start with just the deployment. You know, how complicated was it to install? What was that process like? How many clicks, I mean, not that you have to tell me how many clicks, but you know, what I'm asking is, is how difficult was it to get from zero to, you know, up and running? >> Well, we actually stepped our very difficult challenge. We were in quite a difficult situation where we'd pretty much gone off the cliff in terms of our IOPS performance. So the RFP was quite rapid, and then we needed to get whoever which vendor was successful, we needed to get that deployed rather rapidly and on the floor in our data center and server rooms, which we did. And it was very very simplistic, within three weeks of placing the order, we had that array in our server rack and we'd begun the migration, it was very simple to set up. And the management of that array has been, we've seen say 40% reduction in terms of effort to be able to manage our storage because it is very self-contained, you know, even from a reporting perspective, the deployment, the migration was all very, very, very simplistic, and you know, we we've done some work recently where we had to also do some work on the array and some other migrations that we were doing and the resilience came, came to, came to the forefront of where the Juul architecture and no single point of failure enabled us to do some things that we needed to do quite rapidly because of the, the Juul norms and the resilience within, within the unit and within the Power Store itself was considerable where we, we kept performance up, it also prioritize any discreet rebuilds, keeps the incoming ingest rates high, and prioritizes the, you know, the workloads, which is really impressive, especially when we are moving so quickly with our technology. We don't really have much time to, you know, micromanage the estate. >> (Dave) Can you, can you just repeat what you said on the percent reduction? I think I heard you cut out there a little bit, a percent reduction on, on, on management, on, on, on the labor side. >> So our lead storage engineer is estimated around 40% less management. >> (Dave) Wow. Okay. So that's, that's good. So actually, I love this conversation because, you know, in the early days of automation, people like, ah, that's my job, provisioning LUNs. I'm really good at it, but I think people are realizing that it's actually not something that you want to be really good at. It's something that you want to eliminate. So, it now maybe it's that storage engineer got his or her nights and weekends back, but, but what do they do now when they get that extra time, what do you, what do you put them on? You know, no more strategic initiatives or, you know, other, other tech things on the to-do list. What's that like?. >> The last thing that, you know, any of my team, whether it's the storage leads or some of the infrastructure team that were also involved in engaged, cause you know, the organization, we have to be quite versatile as a team in our skillsets. We don't want to be doing those BAU mundane tasks. Even the storage engineer does not want to be allocating LUNs and allocating storage to physical servers, Vms, etc. We want all of that to be automated. And, you know, those engineers, they're working on some of the cutting edge things that we're trying to do with machine learning as an example, which is much more interesting. It's what they want to be doing. You know, that aides, the obvious things like retention, interest and personal development, we don't want to be, you know, that base IT infrastructure management, is not where any of the engineers wants to be. >> (Dave) In terms of the decision to go with Dell Power Store. I'm definitely hearing there was a relationship. There was an existing relationship with Dell. I'm sure that played into it. >> There were many things. So the relationship wasn't really part of this, even though I've mentioned the end-user compute in any sets or anything that we're procuring, we want best of breed, you know, best of sets. And that was done on, the cost is definitely a driver. The technology, you know, is a big trust to us, We're a tech company, new technology to us is also fascinating, not only our own, but also the storage guarantee, the simplicity, the resilience within, within the unit. Also the ability, which was key to us because of what we're trying to do with our hybrid model and bring, bring back repatriate some of the data as it were from the client. We needed that ability to, with ease, to be able to scale up and scale high, and the Power Store gave us that. >> (Dave) When you say cost, I want to dig into that price or you know, the price tag or the, the cost, I mean, when you do the business case. And I wonder if we could add a little color to that. >> (Richard) There's two elements to this, so they're not only the cost of the price tag, but then also cost of ownership and the comparisons that we were running against the other vendors, but also the comparisons that we were running from a CAPEX investment against OPEX and what we have in the cloud, and also the performance, performance that we get from the cloud and our cloud storage and the resilience within that. And then also the initial price tag, and then comparing the CapEx investments to the OPEX where all elements that were key to us making our decision. And I know that there has to be some credit taken by the Dell account team and that their relationship towards the final phrase of that RFP, you know, were key initially, not all, we were just looking for the best possible storage solution for Ultraleap. >> (Dave) And to determine that on your end, was that like a feature, because it's sometimes fuzzy what the business impact is going to be like that 40% you mentioned, or the data reduction at nine to one, when there's a promise of four to one, did you, what did you do? Did you kind of do a feature function analysis and sort of line that up and, and say, okay, I'm going to map that to our business processes our IT processes and try to predict what the impact would be. Is that how you did it? or did you take a different approach? >> (Richard) We did. So we did that, obviously between vendors usually expected an RFP, but then also mapping to how that would impact the business. And that is not an easy process to go through. And we've seen more gains even comparing one vendor to another, some of that because of the technology, the terminology is very very different and sometimes you have to bring that upper level and also gain a much more detailed understanding, which at times can be challenging, but we did a very like-for-like comparison and, and also lots of research, but you're quite right. The business analysis to what we needed. We had quite a good forecast and from summarized stock information data, and also our engineering and business and strategic roadmap, we were able to map those two together, not the easiest of experiences, not one that I want to repeat, but we, we got it. (Dave laughing) >> (Dave)Yeah, a little bit of art and science involved. Avishek, maybe you could talk about Power Store, what, you know, give us the commercial. What makes it different from other products in the market of things like cloud IQ? Maybe you could talk about that a little bit. >> Sure. So, so again, from a, it's music to my ears, when Richard talks about the ease of deployment and the management, because there is a lot of focus on that. But even as I said earlier, from a man technology perspective, a lot of goodness built-in, in terms of being able to consolidate a customer's environment, onto the platform. So that's more from a storage point of view that give the best performance, give the best data reduction, storage efficiencies. The second part, of course, the flexibility, the options that Power Store gives to the customers in terms of sort of desegregating the storage and the compute aspects of it. So if, as a customer, I want to start with different points in terms of what our customer requirements are today, but going forward as the requirements change from a compute capacity perspective, you can use a scale up and scale out capabilities, and then the intelligence built in, right? So, as you scale out your cluster, being able to move storage around right, as needed being able to do that non-disruptively. So instead of saying that Mr. Customer, your, your storage is going to you're at 90% capacity, being able to say that based on your historical trending, we expect you run out of capacity in six months, some small things like that, right? And of course, if the, the dial home, the support assist capabilities that enabled, cloud IQ brings a lot of intelligence to the table as well. In addition to that, as they mentioned earlier, there is apps on capability that gives another level of flexibility to the customers to integrate your storage infrastructure into a virtual environment, if the customer chooses to do that. And last but not the least, it's not just about the product, right? So it's about the programs that we have put around it, anytime upgrade is a big differentiator for us, where it's an investment protection program for customers, where if they want to have the peace of mind, in terms of three months, nine months, three years down the line, if we come out with new technologies, being able to be upgrade to that non-disruptively is a big part of it as well. It's a peace of mind for the customers that, yes I'm getting into the Power Store architecture today, but going forward, I'm protected from that point of view. So anytime upgrade, it's a new business program that we put around leveraging the architectural benefits of Power Store, whether your compute requirement, your storage requirements change, you're covered from that point of view. So again, a very quick overview of, of what Power Store is, why it is different. And again, that's where that comes from. >> (Dave) Thank you for that. Richard, are you actively using cloud IQ? Do you get the, what kind of value do you get from it? >> Not currently. However, we have, we have had plans to do that. The uptake and BCR, our internal Workload is not allowed us, to do that. But one of the other key reasons for selecting Power Store was the non-disruptive element, you know, with other SaaS products, other providers, and other issues that we have experienced. That was one, that was a key decision for us from a Power Store perspective. One of the other, you know, to go back to the conversation slightly, in terms of performance, we are getting, getting there. You know, there's a 400% speed of improvement of publishing. We've got an 80% faster code coverage. Our firmware builds a 1300% quicker than they were previously. and the time savings of the storage engineer and, you know, as a director of IT, I often asked for certain reports from, from the storage array, we're working at, for storage forecast, performance forecast, you know, when we're coming close to product releases, code drops that we're trying to manage, the reporting or the Power Store is impressive. Whereas previously my storage engineer would not be the, the most happiest of people when I would be trying to pull, you know, monthly and quarterly reports, et cetera. Whereas now it's, it's ease and we have live dashboards running and we can easily extract that information. >> (Dave) I love that because, you know, so often we talk about the 40% reduction in IT labor, which okay, that's cool. But then your CFO's going to say, yeah, but it's not like we're getting rid of people. We, you know, we're still spending that money and you're like, okay. You're now into soft dollars, but when you talk about 400%, 80%, 1300% of what you're talking about business impact and that's telephone numbers to a CFO. So I love those metrics. Thank you for sharing. >> Yeah. But what would, they obviously, it's sort of like dashboards when they visualize that they are very hard hitting, you know, the impact. You're quite right the CFO does chase down you know, the availability and the resource profile, however, we're on a huge upward trajectory. So having the right resilience and infrastructure in places is exactly what we need. And as I mentioned before, those engineers are all reallocated to much more interesting work and, you know, the areas that will actually drive our business forward. >> (Dave) Speaking of resilience, are you doing any replication? >> Not currently. However, we've actually got a meeting regarding this today with some of the enterprise and some of their storage specialists, in a couple of hours time, actually, because that is a very high on the agenda for us to be able to replicate and have a high availability cluster and another potentially Power Store need. >> (Dave) Okay. So I was going to ask you where you want to take this thing. I'm hearing, you're looking at cloud IQ, really try to exploit that. So you got some headroom here in terms of the value that you can get out of this platform to do replication, faster recovery, et cetera, maybe protect against, you know, events. Guys, Thanks so much for your time. Really appreciate your insights. >> (Richard) No problem. >> (Avishek) Thank you. >> And thank you for watching this cube conversation. This is Dave Vellante and we'll see you next time.