(upbeat intro music) >> Hello, everyone. Welcome back to theCube's presentation of the AWS Startup Showcase. This is season two, episode four, of the ongoing series covering the exciting startups from the a AWS ecosystem. Talk about cybersecurity. I'm your host, John Furrier. Here, excited to have two great guests. Ed Casmer, Founder & CEO of Cloud Storage Security. Back, Cube alumni. And also James Johnson, AVP of Research & Development, iPipeline here. Here to talk about Cloud Storage Security, antivirus on S3. Gents, thanks for joining us today. >> Thank you, John. >> Thank you. >> So, the topic here is cloud security, storage security. Ed, we had a great Cube conversation previously, earlier in the month. You know, companies are modernizing their apps and migrating to the cloud. That's fact. Everyone kind of knows that. Been there, done that. You know, clouds have the infrastructure, they got the OS, they got protection. But, the end of the day, the companies are responsible and they're on the hook for their own security of their data. And this is becoming more preeminent now that you have hybrid cloud, cloud operations, cloud-native applications. This is the core focus right now. In the next five years. This is what everyone's talking about. Architecture, how to build apps, workflows, team formation. Everything's being refactored around this. Can you talk about how organizations are adjusting, and how they view their data security in light of how applications are being built and specifically, around the goodness of say, S3? >> Yep, absolutely. Thank you for that. So, we've seen S3 grow 20,000% over the last 10 years. And that's primarily because companies like James with iPipeline, are delivering solutions that are leveraging this object storage more and above the others. When we look at protection, we typically fall into a couple of categories. The first one is, we have folks that are worried about the access of the data. How are they dealing with it? So, they're looking at configuration aspects. But, the big thing that we're seeing is that customers are blind to the fact that the data itself must also be protected and looked at. And, so, we find these customers who do come to the realization that it needs to happen. Finding out like how asking themselves, "How do I solve for this?" And, so, they need lightweight, cloud-native built solutions to deliver that. >> So, what's the blind spot? You mentioned there's a blind spot. They're kind of blind to that. What specifically are you seeing? >> Well, so when we get into these conversations, the first thing that we see with customers is, "I need to predict how I access it." This is everyone's conversation. "Who are my users? How do they get into my data? How am I controlling that policy? Am I making sure there's no east-west traffic there, once I've blocked the north-south?" But, what we really find is that the data is the key packet of this whole process. It's what gets consumed by the downstream users. Whether that's an employee, a customer, a partner. And, so, it's really the blind spot is the fact that we find most customers not looking at whether that data is safe to use. >> It's interesting. You know, when you talk about that, I think about like all the recent breaches and incidents. "Incidents" they call them. >> Yeah. >> They're really been around user configurations. S3 buckets not configured properly. And this brings up what you're saying, is that the users and the customers have to be responsible for the configurations, the encryption, the malware aspect of it. Don't just hope that AWS has the magic to do it. Is that kind of what you're getting at here? Is that the similar? Am I correlating that properly? >> Absolutely. That's perfect. And, and we've seen it. We've had our own customers, luckily, iPipeline's not one of them, that have actually infected their end users, because they weren't looking at the data. >> Yeah. And that's a huge issue. So, James, let's get in, you're a customer-partner. Talk about your relationship with these guys and what's it all about? >> Yeah. Well, iPipeline is building a digital ecosystem for life insurance and wealth management industries to enable the sale of life insurance to underinsured and uninsured Americans, to make sure that they have the coverage that they need should something happen. And, our solutions have been around for many years in a traditional data center type of an implementation. And, we're in process now of migrating that to the cloud, moving it to AWS. In order to give our customers a better experience, better resiliency, better reliability. And, with that, we have to change the way that we approach file storage and how we approach scanning for vulnerabilities in those files that might come to us via feeds from third parties, or that are uploaded directly by end users that come to us from a source that we don't control. So, it was really necessary for us to identify a solution that both solved for these vulnerability scanning needs, as well as enabling us to leverage the capabilities that we get with other aspects of our move to the cloud. Being able to automatically scale based on load, based on need. To ensure that we get the performance that our customers are looking for. >> So, tell me about your journey to the cloud, migrating to the cloud, and how you're using S3. Specifically, what led you to determine the need for the cloud-based AV solution? >> Yeah. So, when we looked to begin moving our applications to the cloud, one of the realizations that we had is that our approach to storing certain types of data, was a bit archaic. We were storing binary files in a database, which is not the most efficient way to do things. And, we were scanning them with the traditional antivirus engines, that would've been scaled in traditional ways. So, as our need grew, we would need to spin up additional instances of those engines to keep up with load. And we wanted a solution that was cloud-native, and would allow us to scan more dynamically without having to manage the underlying details of how many engines do I need to have running for a particular load at a particular time, and being able to scan dynamically and also being able to move that out of the application layer, being able to scan those files behind the scenes. So, scanning in, when the file's been saved in S3. It allows us to scan and release the file once it's been deemed safe, rather than blocking the user while they wait for that scan to take place. >> Awesome. Well, thanks for sharing that. I got to ask Ed and James, same question. And next is, how does all this factor into audits and self-compliance? Because, when you start getting into this level of sophistication, I'm sure it probably impacts reporting, workflows. Can you guys share the impact on that piece of it? The reporting. >> Yeah, I'll start with a comment, and James will have more applicable things to say. But, we're seeing two things. One, is you don't want to be the vendor whose name is in the news for infecting your customer base. So, that's number one. so you have to put something like this in place and figure that out. The second part is, we do hear that under SOC 2, under PCI, different aspects of it, there are scanning requirements on your data. Traditionally, we've looked at that as endpoint data and the data that you see in your on-prem world. It doesn't translate as directly to cloud data, but, it's certainly applicable. And if you want to achieve SOC 2 or you want to achieve some of these other pieces, you have to be scanning your data as well. >> James, what's your take? As practitioner, you're living it. >> Yeah. That's exactly right. There are a number of audits that we go through, where this is a question that comes up both from a SOC perspective, as well as our individual customers, who reach out, and they want to know where we stand from a security perspective and a compliance perspective. And, very often, this is a question of "How are you ensuring that the data that is uploaded into the application is safe and doesn't contain any vulnerabilities?" >> James, if you don't mind me asking. I have to kind of inquire, because I can imagine that you have users on your system, but also you have third parties, relationships. How does that impact this? What's the connection? >> That's a good question. We receive data from a number of different locations. From our customers directly, from their users, and from partners that we have, as well as partners that our customers have. And, as we ingest that data, from an implementation perspective, the way we've approached this, there's minimal impact there in each one of those integrations, because everything comes into the S3 bucket and is scanned before it is available for consumption or distribution. But, this allows us to ensure that no matter where that data is coming from, that we are able to verify that it is safe before we allow it into our systems or allow it to continue on to another third party, whether that's our customer or somebody else. >> Yeah. I don't mean to get in the weeds there, but it's one of those things where, you know, this is what people are experiencing right now. You know, Ed, we talked about this before. It's not just siloed data anymore. It's interactive data. It's third party data from multiple sources. This is a scanning requirement. >> Agreed. I find it interesting, too. I think James brings it up. We've had it in previous conversations, that not all data's created equal. Data that comes from third parties that you're not in control of, you feel like you have to scan and other data you may generate internally. You don't, have to be as compelled to scan that, although it's a good idea. But it's, you can kind of, as long as you can sift through and determine which data is which, and process it appropriately, then you're in good shape. >> Well, James. You're living the cloud security storage security situation, here. I got to ask you if you zoom out, not get in the weeds, and look at kind of the boardroom or the management conversation. Tell me about how you guys view the data security problem. I mean, obviously it's important, right? So, can you give us a level of, you know, how important it is for iPipeline and with your customers and where does this S3 piece fit in? I mean, when you guys look at this holistically, for data security, what's the view? What's the conversation like? >> Yeah. Well, data security is critical. As Ed mentioned a few minutes ago, you don't want to be the company that's in the news because some data was exposed. That's something that nobody has the appetite for. And, so, data security is, first and foremost, in everything that we do. And that's really where this solution came into play and making sure that we had not only a solution, but, we had a solution that was the right fit for the technology that we're using. There are a number of options. Some of them have been around for a while. But this is focused on S3, which we were using to store these documents that are coming from many different sources. And, you know, we have to take all the precautions we can to ensure that something that is malicious doesn't make its way into our ecosystem or into our customers' ecosystems through us. >> What's the primary use case that you see the value here with these guys? What's the "aha" moment that you had? >> With the Cloud Storage Security, specifically, it was really, it goes beyond the security aspects of being able to scan for vulnerable files, which is there are a number of options and, and they're one of those. But for us, the key was being able to scale dynamically without committing to a particular load, whether that's under committing or over committing. As we move our applications from a traditional data center type of installation to AWS, we anticipated a lot of growth over time. And being able to scale up very dynamically, you know, literally moving a slider within the admin console was key to us, to be able to meet our customer's needs without overspending. By building up something that was, dramatically larger than we needed in our initial rollout. >> Not a bad testimonial there, Ed. I mean. >> I agree. >> This is really highlights the applications using S3 more in the file workflow for the application in real time. This is where you start to see the rise of ransomware, other issues and scale matters. Can you share your thoughts and reaction to what James just said? >> Yeah, I think it's critical. I mean, as the popularity of S3 has increased, so has the fact that it's an attack vector now, and people are going after it. Whether that's to plant bad, malicious files, whether it's to replace code segments that are downloaded and used in other applications, it is a very critical piece. And when you look at scale, and you look at the cloud-native capability, there are lots of ways to solve it. You can dig a hole with a spoon, but a shovel works a lot better. And, in this case, you know, we take a simple example like James. They did a weekend migration, so, they've got new data coming in all the time. But, we did a massive migration. 5,000 files a minute being ingested. And, like he said, with a couple of clicks, scale up, process that over a sustained period of time, and then scale back down. So, you know, I've said it before. I said it on the previous one. We don't want to get in the way of someone's workflow. We want to help them secure their data and do it in a timely fashion, that they can continue with their proper processing and their normal customer responses. >> Yeah. Friction always has to be key. I know you're in the marketplace with your antivirus, for S3 on AWS. People can just download it. So, people are interested, go check it out. James, I got to ask you, and maybe Ed can chime in over the top, but, it seems so obvious. Data. Secure the data. Why is it so hard? Why isn't this so obvious? What's the problem? Why is it so difficult? Why are there so many different solutions? It just seems so obvious. You know, you got ransomware, you got injection of different malicious payloads. There's a ton of things going around around the data. Why is this? This is so obvious. Why isn't it solved? >> Well, I think there have been solutions available for a long time. That the challenge, the difficulty that I see is, that it is a moving target. As bad actors learn new vulnerabilities, new approaches. And as new technology becomes available, that opens additional attack vectors. That's the challenge. Is keeping up on the changing world. Including keeping up on the new ways that people are finding to exploit vulnerabilities. >> Yeah. And you got sensitive data at iPipeline. You do a lot of insurance, wealth management, all kinds of sensitive data, super valuable. You know, just brings me up, reminds me of the Sony hack, Ed, years ago. You know, companies are responsible for their own militia. I mean, cybersecurity, there's no government help for sure. I mean, companies are on the hook, as we mentioned earlier at the top of this interview. This really is highlighted that, IT departments and are, have to evolve to large scale cloud, you know, cloud-native applications, automation, AI machine learning all built in, to keep up at the scale. But, also, from a defense standpoint, I mean, James, you're out there, you're in the front lines. You got to defend yourself, basically, and you got to engineer it. >> A hundred percent. And just to go on top of what James was saying is, I think they're one of the big factors, and we've seen this. There's skill shortages out there. There's also just a pure lack of understanding. When we look at Amazon S3 or object storage in general, it's not an executable file system. So, people sort of assume that, "Oh, I'm safe. It's not executable. So, I'm not worried about it traversing my storage network." And they also probably have the assumption that the cloud providers, Amazon, is taking care of this for 'em. And, so, it's this "aha" moment, like you mentioned earlier. That you start to think, "Oh, it's not about where the data is sitting, per se, it's about scanning it as close to the storage spot. So, when it gets to the end user, it's safe and secure. And you can't rely on the end users' environment and system to be in place and up to date to handle it. So, it's that really, that lack of understanding that drives some of these folks into this, but for a while, we'll walk into customers and they'll say the same thing you said, John. "Why haven't I been doing this for so long?" And, it's because they didn't understand that it was such a risk. That's where that blind spot comes in. >> James, it's just a final note on your environment. What's your goals for the next year? How's things going over there in your side? How do you look at the security posture? What's on your agenda for the next year? How do you guys looking at the next level? >> Yeah, well, our goal as it relates to this is, to continue to move our existing applications over to AWS, to run natively there, which includes moving more data into S3 and leveraging the cloud storage security solution to scan that and ensure that it's, that there are no vulnerabilities that are getting in. >> And the ingestion? Is there like a bottlenecks, log jams? How do you guys see that scaling up? I mean, what's the strategy there? More, just add more S3? >> Well, S3 itself scales automatically for us and, the Cloud Storage Solution gives us levers to pull to do that. As Ed mentioned, we ingested a large amount of data during our initial migration, which created a bottleneck for us, as we were preparing to move our users over. We were able to, you know, make an adjustment in the admin console and spin up additional processes entirely behind the scenes and broke the log jam. So, I don't see any immediate concerns there. Being able to handle the load. >> You know, the term cloud-native and, you know, hyperscale-native, cloud-native, OneCloud, it's hybrid. All these things are native. We have anti-virus native coming soon. And I mean, this is what we're. You're basically doing is making it native into the workflows. Security native, and soon there's going to be security clouds out there. We're starting to see the rise of these new solutions. Can you guys share any thoughts or vision around how you see the industry evolving and what's needed, what's working and what's needed? Ed, we'll start with you. What's your vision? >> So, I think the notion of being able to look at and view the management plane and control that, has been where we're at right now. that's what everyone seems to be doing and going after. I think there are niche plays coming up, storage is one of them. But, we're going to get to a point where storage is just a blanket term for where you put your stuff. I mean, it kind of already is that, but, in AWS, it's going to be less about S3, less about work docs, less about EVS. It's going to be just storage and you're going to need a solution that can span all of that, to go along with where we're already at at the management plane. We're going to keep growing the data plane. >> James, what's your vision for what's needed in the industry? What's the gaps? What's working? And where do you see things going? >> Yeah, well, I think on the security front, specifically, Ed's probably a little bit better equipped to speak to them than I am. Since that's his primary focus. But I see the need for just expanded solutions that are cloud-native, that fit and fit nicely with the Amazon technologies, Whether that comes from Amazon or other partners like Cloud Storage Security, to fill those gaps. We're focused on, you know, the financial services and insurance industries. That's our niche. And we look to other partners, like Ed, to help be the experts in these areas. And so that's really what I'm looking for is, you know, the experts that we can partner with that are going to help fill those gaps as they come up and as they change in the future. >> Well, James, I really appreciate you coming on sharing your story. Ed, I'll give you the final word. Put a quick, spend a minute to talk about the company. I know Cloud Storage Security is an AWS partner, with the Security Software Competency. And is one of, I think, 16 partners listed in the competency and data category. So, take a minute to explain, you know, what's going on with the company, where people can find more information, how they buy and consume the products. >> Okay. >> Put the plug in. >> Yeah, thank you for that. So, we are a fast growing startup. We we've been in business for two and a half years, now. We have achieved our Security Competency. As John indicated, we're one of 16 data protection, Security Competent ISV vendors, globally. And, our goal is to expand and grow a platform that spans all storage types that you're going to be dealing with. And answer basic questions. "What do I have and where is it? Is it safe to use?" And, "Am I in proper control of it? Am I being alerted appropriately?" You know, so we're building this storage security platform, very laser-focused on the storage aspect of it. And, if people want to find out more information, you're more than welcome to go and try the software out on Amazon Marketplace. That's basically where we do most of our transacting. So, find it there, start a free trial, reach out to us directly from our website. We are happy to help you in any way that you need it, whether that's storage assessments, figuring out what data is important to you, and how to protect it. >> All right, Ed, thank you so much. Ed Casmer. Founder & CEO of Cloud Storage Security and of course James Johnson, AVP Research & Development, iPipeline customer. Gentlemen, thank you for sharing your story and featuring the company and the value proposition. It's certainly needed. This is season two, episode four. Thanks for joining us. Appreciate it. >> Thanks, John. >> Okay. I'm John Furrier. That is a wrap for this segment of the cybersecurity, season two, episode four. The ongoing series covering the exciting startups from Amazon's ecosystem. Thanks for watching. (gentle outro music)

(upbeat music) >> Welcome back, everyone to CUBE Supercloud 22. I'm John Furrier, your host. Got a great influencer, Cloud Cloud RRT segment with Sarbjeet Johal, Cloud influencer, Cloud economist, Cloud consultant, Cloud advisor. Sarbjeet, welcome back, CUBE alumni. Good to see you. >> Thanks John and nice to be here. >> Now, what's your title? Cloud consultant? Analyst? >> Consultant, actually. Yeah, I'm launching my own business right now formally, soon. It's in stealth mode right now, we'll be (inaudible) >> Well, I'll just call you a Cloud guru, Cloud influencer. You've been great, friend of theCUBE. Really powerful on social. You share a lot of content. You're digging into all the trends. Supercloud is a thing, it's getting a lot of traction. We introduced that concept last reinvent. We were riffing before that. As we kind of were seeing the structural change that is now Supercloud, it really is kind of the destination or outcome of what we're seeing with hybrid cloud as a steady state into the what's now, they call multicloud, which is kind of awkward. It feels like it's default. Like multicloud, multi-vendor, but Supercloud has much more of a comprehensive abstraction around it. What's your thoughts? >> As you said, as Dave says that too, the Supercloud has that abstraction built into it. It's built on top of cloud, right? So it's being built on top of the CapEx which is being spent by likes of AWS and Azure and Google Cloud, and many others, right? So it's leveraging that infrastructure and building software stack on top of that, which is a platform. I see that as a platform being built on top of infrastructure as code. It's another platform which is not native to the cloud providers. So it's like a kind of cross-Cloud platform. That's what I said. >> Yeah, VMware calls it that cloud-cross cloud. I'm not a big fan of the name but I get what you're saying. We had a segment on earlier with Adrian Cockcroft, Laurie McVety and Chris Wolf, all part of the Cloud RRT like ourselves, and you've involved in Cloud from day one. Remember the OpenStack days Early Cloud, AWS, when they started we saw the trajectory and we saw the change. And I think the OpenStack in those early days were tell signs because you saw the movement of API first but Amazon just grew so fast. And then Azure now is catching up, their CapEx is so large that companies like Snowflake's like, "Why should I build my own? "I just sit on top of AWS, "move fast on one native cloud, then figure it out." Seems to be one of the playbooks of the Supercloud. >> Yeah, that is true. And there are reasons behind that. And I think number one reason is the skills gravity. What I call it, the developers and/or operators are trained on one set of APIs. And I've said that many times, to out compete your competition you have to out educate the market. And we know which cloud has done that. We know what traditional vendor has done that, in '90s it was Microsoft, they had VBS number one language and they were winning. So in the cloud era, it's AWS, their marketing efforts, their go-to market strategy, the micro nature of the releasing the micro sort of features, if you will, almost every week there's a new feature. So they have got it. And other two are trying to mimic that and they're having low trouble light. >> Yeah and I think GCP has been struggling compared to the three and native cloud on native as you're right, completely successful. As you're caught up and you see the Microsoft, I think is a a great selling point around multiple clouds. And the question that's on the table here is do you stay with the native cloud or you jump right to multicloud? Now multicloud by default is kind of what I see happening. We've been debating this, I'd love to get your thoughts because, Microsoft has a huge install base. They've converted to Office 365. They even throw SQL databases in there to kind of give it a little extra bump on the earnings but I've been super critical on their numbers. I think their shares are, there's clearly overstating their share, in my opinion, compared to AWS is a need of cloud, Azure though is catching up. So you have customers that are happy with Microsoft, that are going to run their apps on Azure. So if a customer has Azure and Microsoft that's technically multiple clouds. >> Yeah, true. >> And it's not a strategy, it's just an outcome. >> Yeah, I see Microsoft cloud as friendly to the internal developers. Internal developers of enterprises. but AWS is a lot more ISV friendly which is the software shops friendly. So that's what they do. They just build software and give it to somebody else. But if you're in-house developer and you have been a Microsoft shop for a long time, which enterprise haven't been that, right? So Microsoft is well entrenched into the enterprise. We know that, right? >> Yeah. >> For a long time. >> Yeah and the old joke was developers love code and just go with a lock in and then ops people don't want lock in because they want choice. So you have the DevOps movement that's been successful and they get DevSecOps. The real focus to me, I think, is the operating teams because the ops side is really with the pressure vis-a-vis. I want to get your reaction because we're seeing kind of the script flip. DevOps worked, infrastructure's code has worked. We don't yet see security as code yet. And you have things like cloud native services which is all developer, goodness. So I think the developers are doing fine. Give 'em a thumbs up and open source's booming. So they're shifting left, CI/CD pipeline. You have some issues around repo, monolithic repos, but devs are doing fine. It's the ops that are now have to level up because that seems to be a hotspot. What's your take? What's your reaction to that? Do you agree? And if you say you agree, why? >> Yeah, I think devs are doing fine because some of the devs are going into ops. Like the whole movement behind DevOps culture is that devs and ops is one team. The people who are building that application they're also operating that as well. But that's very foreign and few in enterprise space. We know that, right? Big companies like Google, Microsoft, Amazon, Twitter, those guys can do that. They're very tech savvy shops. But when it comes to, if you go down from there to the second tier of enterprises, they are having hard time with that. Once you create software, I've said that, I sound like a broken record here. So once you create piece of software, you want to operate it. You're not always creating it. Especially when it's inhouse software development. It's not your core sort of competency to. You're not giving that software to somebody else or they're not multiple tenants of that software. You are the only user of that software as a company, or maybe maximum to your employees and partners. But that's where it stops. So there are those differences and when it comes to ops, we have to still differentiate the ops of the big companies, which are tech companies, pure tech companies and ops of the traditional enterprise. And you are right, the ops of the traditional enterprise are having tough time to cope up with the changing nature of things. And because they have to run the old traditional stacks whatever they happen to have, SAP, Oracle, financial, whatnot, right? Thousands of applications, they have to run that. And they have to learn on top of that, new scripting languages to operate the new stack, if you will. >> So for ops teams do they have to spin up operating teams for every cloud specialized tooling, there's consequences to that. >> Yeah. There's economics involved, the process, if you are learning three cloud APIs and most probably you will end up spending a lot more time and money on that. Number one, number two, there are a lot more problems which can arise from that, because of the differences in how the APIs work. The rule says if you pick one primary cloud and then you're focused on that, and most of your workloads are there, and then you go to the secondary cloud number two or three on as need basis. I think that's the right approach. >> Well, I want to get your take on something that I'm observing. And again, maybe it's because I'm old school, been around the IT block for a while. I'm observing the multi-vendors kind of as Dave calls the calisthenics, they're out in the market, trying to push their wears and convincing everyone to run their workloads on their infrastructure. multicloud to me sounds like multi-vendor. And I think there might not be a problem yet today so I want to get your reaction to my thoughts. I see the vendors pushing hard on multicloud because they don't have a native cloud. I mean, IBM ultimately will probably end up being a SaaS application on top of one of the CapEx hyperscale, some say, but I think the playbook today for customers is to stay on one native cloud, run cloud native hybrid go in on OneCloud and go fast. Then get success and then go multiple clouds. versus having a multicloud set of services out of the gate. Because if you're VMware you'd love to have cross cloud abstraction layer but that's lock in too. So what's your lock in? Success in the marketplace or vendor access? >> It's tricky actually. I've said that many times, that you don't wake up in the morning and say like, we're going to do multicloud. Nobody does that by choice. So it falls into your lab because of mostly because of what MNA is. And sometimes because of the price to performance ratio is better somewhere else for certain kind of workloads. That's like foreign few, to be honest with you. That's part of my read is, that being a developer an operator of many sort of systems, if you will. And the third tier which we talked about during the VMworld, I think 2019 that you want vendor diversity, just in case one vendor goes down or it's broken up by feds or something, and you want another vendor, maybe for price negotiation tactics, or- >> That's an op mentality. >> Yeah, yeah. >> And that's true, they want choice. They want to get locked in. >> You want choice because, and also like things can go wrong with the provider. We know that, we focus on top three cloud providers and we sort of assume that they'll be there for next 10 years or so at least. >> And what's also true is not everyone can do everything. >> Yeah, exactly. So you have to pick the provider based on all these sort of three sets of high level criteria, if you will. And I think the multicloud should be your last choice. Like you should not be gearing up for that by default but it should be by design, as Chuck said. >> Okay, so I need to ask you what does Supercloud in my opinion, look like five, 10 years out? What's the outcome of a good Supercloud structure? What's it look like? Where did it come from? How did it get there? What's your take? >> I think Supercloud is getting born in the absence of having standards around cloud. That's what it is. Because we don't have standards, we long, or we want the services at different cloud providers, Which have same APIs and there's less learning curve or almost zero learning curve for our developers and operators to learn that stuff. Snowflake is one example and VMware Stack is available at different cloud providers. That's sort of infrastructure as a service example if you will. And snowflake is a sort of data warehouse example and they're going down the stack. Well, they're trying to expand. So there are many examples like that. What was the question again? >> Is Supercloud 10 years out? What does it look like? What's the components? >> Yeah, I think the Supercloud 10 years out will expand because we will expand the software stack faster than the hardware stack and hardware stack will be expanding of course, with the custom chips and all that. There was the huge event yesterday was happening from AWS. >> Yeah, the Silicon. >> Silicon Day. And that's an eyeopening sort of movement and the whole technology consumption, if you will. >> And yeah, the differentiation with the chips with supply chain kind of herding right now, we think it's going to be a forcing function for more cloud adoption. Because if you can't buy networking gear you going to go to the cloud. >> Yeah, so Supercloud to me in 10 years, it will be bigger, better in the likes of HashiCorp. Actually, I think we need likes of HashiCorp on the infrastructure as a service side. I think they will be part of the Supercloud. They are kind of sitting on the side right now kind of a good vendor lost in transition kind of thing. That sort of thing. >> It's like Kubernetes, we'll just close out here. We'll make a statement. Is Kubernetes a developer thing or an infrastructure thing? It's an ops thing. I mean, people are coming out and saying Kubernetes is not a developer issue. >> It's ops thing. >> It's an ops thing. It's in operation, it's under the hood. So you, again, this infrastructure's a service integrating this super pass layer as Dave Vellante and Wikibon call it. >> Yeah, it's ops thing, actually, which enables developers to get that the Azure service, like you can deploy your software in sort of different format containers, and then you don't care like what VMs are those? And, but Serverless is the sort of arising as well. It was hard for a while now it's like the lull state, but I think Serverless will be better in next three to five years on. >> Well, certainly the hyperscale is like AWS and Azure and others have had great CapEx and investments. They need to stay ahead, in your opinion, final question, how do they stay ahead? 'Cause, AWS is not going to stand still nor will Azure, they're pedaling as fast as they can. Google's trying to figure out where they fit in. Are they going to be a real cloud or a software stack? Same with Oracle. To me, it's really, the big race is now with AWS and Azure's nipping at their heels. Hyperscale, what do they need to do to differentiate going forward? >> I think they are in a limbo. They, on one side, they don't want to compete with their customers who are sitting on top of them, likes of Snowflake and others, right? And VMware as well. But at the same time, they have to keep expanding and keep innovating. And they're debating within their themselves. Like, should we compete with these guys? Should we launch similar sort of features and functionality? Or should we keep it open? And what I have heard as of now that internally at AWS, especially, they're thinking about keeping it open and letting people sort of (inaudible)- >> And you see them buying some the Cerner with Oracle that bought Cerner, Amazon bought a healthcare company. I think the likes of MongoDB, Snowflake, Databricks, are perfect examples of what we'll see I think on the AWS side. Azure, I'm not so sure, they like to have a little bit more control at the top of the stack with the SaaS, but I think Databricks has been so successful open source, Snowflake, a little bit more proprietary and closed than Databricks. They're doing well is on top of data, and MongoDB has got great success. All of these things compete with AWS higher level services. So, that advantage of those companies not having the CapEx investment and then going multiple clouds on other ecosystems that's a path of customers. Stay one, go fast, get traction, then go. >> That's huge. Actually the last sort comment I want to make is that, Also, that you guys include this in the definition of Supercloud, the likes of Capital One and Soner sort of vendors, right? So they are verticals, Capital One is in this financial vertical, and then Soner which Oracle bar they are in this healthcare vertical. And remember in the beginning of the cloud and when the cloud was just getting born. We used to say that we will have the community clouds which will be serving different verticals. >> Specialty clouds. >> Specialty clouds, community clouds. And actually that is happening now at very sort of small level. But I think it will start happening at a bigger level. The Goldman Sachs and others are trying to build these services on the financial front risk management and whatnot. I think that will be- >> Well, what's interesting, which you're bringing up a great discussion. We were having discussions around these vertical clouds like Goldman Sachs Capital One, Liberty Mutual. They're going all in on one native cloud then going into multiple clouds after, but then there's also the specialty clouds around functionality, app identity, data security. So you have multiple 3D dimensional clouds here. You can have a specialty cloud just on identity. I mean, identity on Amazon is different than Azure. Huge issue. >> Yeah, I think at some point we have to distinguish these things, which are being built on top of these infrastructure as a service, in past with a platform, a service, which is very close to infrastructure service, like the lines are blurred, we have to distinguish these two things from these Superclouds. Actually, what we are calling Supercloud maybe there'll be better term, better name, but we are all industry path actually, including myself and you or everybody else. Like we tend to mix these things up. I think we have to separate these things a little bit to make things (inaudible) >> Yeah, I think that's what the super path thing's about because you think about the next generation SaaS has to be solved by innovations of the infrastructure services, to your point about HashiCorp and others. So it's not as clear as infrastructure platform, SaaS. There's going to be a lot of interplay between this levels of services. >> Yeah, we are in this flasker situation a lot of developers are lost. A lot of operators are lost in this transition and it's just like our economies right now. Like I was reading at CNBC today, and here's sort of headline that people are having hard time understanding what state the economy is in. And so same is true with our technology economy. Like we don't know what state we are in. It's kind of it's in the transition phase right now. >> Well we're definitely in a bad economy relative to the consumer market. I've said on theCUBE publicly, Dave has as well, not as aggressive. I think the tech is still in a boom. I don't think there's tech bubble at all that's bursting, I think, the digital transformation from post COVID is going to continue. And this is the first recession downturn where the hyperscalers have been in market, delivering the economic value, almost like they're pumping on all cylinders and going to the next level. Go back to 2008, Amazon web services, where were they? They were just emerging out. So the cloud economic impact has not been factored into the global GDP relationship. I think all the firms that are looking at GDP growth and tech spend as a correlation, are completely missing the boat on the fact that cloud economics and digital transformation is a big part of the new economics. So refactoring business models this is continuing and it's just the early days. >> Yeah, I have said that many times that cloud works good in the bad economy and cloud works great in the good economy. Do you know why? Because there are different type of workloads in the good economy. A lot of experimentation, innovative solutions go into the cloud. You can do experimentation that you have extra money now, but in the bad economy you don't want to spend the CapEx because don't have money. Money is expensive at that point. And then you want to keep working and you don't need (inaudible) >> I think inflation's a big factor too right now. Well, Sarbjeet, great to see you. Thanks for coming into our studio for our stage performance for Supercloud 22, this is a pilot episode that we're going to get a consortium of experts Cloud RRT like yourselves, in the conversation to discuss what the architecture is. What is a taxonomy? What are the key building blocks and what things need to be in place for Supercloud capability? Because it's clear that if without standards, without defacto standards, we're at this tipping point where if it all comes together, not all one company can do everything. Customers want choice, but they also want to go fast too. So DevOps is working. It's going the next level. We see this as Supercloud. So thank you so much for your participation. >> Thanks for having me. And I'm looking forward to listen to the other sessions (inaudible) >> We're going to take it on A stickers. We'll take it on the internet. I'm John Furrier, stay tuned for more Supercloud 22 coverage, here at the Palo Alto studios in one minute. (bright music)