(bright upbeat music) >> Welcome back, everyone, to the "Supercloud 22." I'm John Furrier, host of "The Cube." This is the Cloud-erati panel, the distinguished experts who have been there from day one, watching the cloud grow, from building clouds, and all open source stuff as well. Just great stuff. Good friends of "The Cube," and great to introduce back on "The Cube," Adrian Cockcroft, formerly with Netflix, formerly AWS, retired, now commentating here in "The Cube," as well as other events. Great to see you back out there, Adrian. Lori MacVittie, Cloud Evangelist with F5, also wrote a great blog post on supercloud, as well as Dave Vellante as well, setting up the supercloud conversation, which we're going to get into, and Chris Hoff, who's the CTO and CSO of LastPass who's been building clouds, and we know him from "The Cube" before with security and cloud commentary. Welcome, all, back to "The Cube" and supercloud. >> Thanks, John. >> Hi. >> All right, Lori, we'll start with you to get things going. I want to try to sit back, as you guys are awesome experts, and involved from building, and in the trenches, on the front lines, and Adrian's coming out of retirement, but Lori, you wrote the post setting the table on supercloud. Let's start with you. What is supercloud? What is it evolving into? What is the north star, from your perspective? >> Well, I don't think there's a north star yet. I think that's one of the reasons I wrote it, because I had a clear picture of this in my mind, but over the past, I don't know, three, four years, I keep seeing, in research, my own and others', complexity, multi-cloud. "We can't manage it. They're all different. "We have trouble. What's going on? "We can't do anything right." And so digging into it, you start looking into, "Well, what do you mean by complexity?" Well, security. Migration, visibility, performance. The same old problems we've always had. And so, supercloud is a concept that is supposed to overlay all of the clouds and normalize it. That's really what we're talking about, is yet another abstraction layer that would provide some consistency that would allow you to do the same security and monitor things correctly. Cornell University actually put out a definition way back in 2016. And they said, "It's an architecture that enables migration "across different zones or providers," and I think that's important, "and provides interfaces to everything, "makes it consistent, and normalizes the network," basically brings it all together, but it also extends to private clouds. Sometimes we forget about that piece of it, and I think that's important in this, so that all your clouds look the same. So supercloud, big layer on top, makes everything wonderful. It's unicorns again. >> It's interesting. We had multiple perspectives. (mumbles) was like Snowflake, who built on top of AWS. Jerry Chan, who we heard from earlier today, Greylock Penn's "Castles in the Cloud" saying, "Hey, you can have a moat, "you can build an advantage and have differentiation," so startups are starting to build on clouds, that's the native cloud view, and then, of course, they get success and they go to all the other clouds 'cause they got customers in the ecosystem, but it seems that all the cloud players, Chris, you commented before we came on today, is that they're all fighting for the customer's workloads on their infrastructure. "Come bring your stuff over to here, "and we'll make it run better." And all your developers are going to be good. Is there a problem? I mean, or is this something else happening here? Is there a real problem? >> Well, I think the north star's over there, by the way, Lori. (laughing) >> Oh, there it is. >> Right there. The supercloud north star. So indeed I think there are opportunities. Whether you call them problems or not, John, I think is to be determined. Most companies have, especially if they're a large enterprise, whether or not they've got an investment in private cloud or not, have spent time really trying to optimize their engineering and workload placement on a single cloud. And that, regardless of your choice, as we take the big three, whether it's Amazon, Google, or Microsoft, each of them have their pros and cons for various types of workloads. And so you'll see a lot of folks optimizing for a particular cloud, and it takes a huge effort up and down the stack to just get a single cloud right. That doesn't take into consideration integrations with software as a service, instantiated, oftentimes, on top of infrastructure of the service that you need to supplement where the obstruction layer ends in infrastructure of the service. You've seen most IS players starting to now move up-chain, as we predicted years ago, to platform as a service, but platforms of various types. So I definitely see it as an opportunity. Previous employers have had multiple clouds, but they were very specifically optimized for the types of workloads, for example, in, let's say, AWS versus GCP, based on the need for different types and optimized compute platforms that each of those providers ran. We never, in that particular case, thought about necessarily running the same workloads across both clouds, because they had different pricing models, different security models, et cetera. And so the challenge is really coming down to the fact that, what is the cost benefit analysis of thinking about multi-cloud when you can potentially engineer the resiliency or redundancy, all the in-season "ilities" that you might need to factor into your deployments on a single cloud, if they are investing at the pace in which they are? So I think it's an opportunity, and it's one that continues to evolve, but this just reminds me, your comments remind me, of when we were talking about OpenStack versus AWS. "Oh, if there were only APIs that existed "that everybody could use," and you saw how that went. So I think that the challenge there is, what is the impetus for a singular cloud provider, any of the big three, deciding that they're going to abstract to a single abstraction layer and not be able to differentiate from the competitors? >> Yeah, and that differentiation's going to be big. I mean, assume that the clouds aren't going to stay still like AWS and just not stop innovating. We see the devs are doing great, Adrian, open source is bigger and better than ever, but now that's been commercialized into enterprise. It's an ops problem. So to Chris's point, the cost benefit analysis is interesting, because do companies have to spin up multiple operations teams, each with specialized training and tooling for the clouds that they're using, and does that open up a can of worms, or is that a good thing? I mean, can you design for this? I mean, is there an architecture or taxonomy that makes it work, or is it just the cart before the horse, the solution before the problem? >> Yeah, well, I think that if you look at any large vendor... Sorry, large customer, they've got a bit of everything already. If you're big enough, you've bought something from everybody at some point. So then you're trying to rationalize that, and trying to make it make sense. And I think there's two ways of looking at multi-cloud or supercloud, and one is that the... And practically, people go best of breed. They say, "Okay, I'm going to get my email "from Google or Microsoft. "I'm going to run my applications on AWS. "Maybe I'm going to do some AI machine learning on Google, "'cause those are the strengths of the platforms." So people tend to go where the strength is. So that's multi-cloud, 'cause you're using multiple clouds, and you still have to move data and make sure they're all working together. But then what Lori's talking about is trying to make them all look the same and trying to get all the security architectures to be the same and put this magical layer, this unicorn magical layer that, "Let's make them all look the same." And this is something that the CIOs have wanted for years, and they keep trying to buy it, and you can sell it, but the trouble is it's really hard to deliver. And I think, when I go back to some old friends of ours at Enstratius who had... And back in the early days of cloud, said, "Well, we'll just do an API that abstracts "all the cloud APIs into one layer." Enstratius ended up being sold to Dell a few years ago, and the problem they had was that... They didn't have any problem selling it. The problem they had was, a year later, when it came up for renewal, the developers all done end runs around it were ignoring it, and the CIOs weren't seeing usage. So you can sell it, but can you actually implement it and make it work well enough that it actually becomes part of your core architecture without, from an operations point of view, without having the developers going directly to their favorite APIs around them? And I'm not sure that you can really lock an organization down enough to get them onto a layer like that. So that's the way I see it. >> You just defined- >> You just defined shadow shadow IT. (laughing) That's pretty- (crosstalk) >> Shadow shadow IT, yeah. >> Yeah, shadow shadow it. >> Yeah. >> Yeah. >> I mean, this brings up the question, I mean, is there really a problem? I mean, I guess we'll just jump to it. What is supercloud? If you can have the magic outcome, what is it? Enstratius rendered in with automation? The security issues? Kubernetes is hot. What is the supercloud dream? I guess that's the question. >> I think it's got easier than it was five, 10 years ago. Kubernetes gives you a bunch of APIs that are common across lots of different areas, things like Snowflake or MongoDB Atlas. There are SaaS-based services, which are across multiple clouds from vendors that you've picked. So it's easier to build things which are more portable, but I still don't think it's easy to build this magic API that makes them all look the same. And I think that you're going to have leaky abstractions and security being... Getting the security right's going to be really much more complex than people think. >> What about specialty superclouds, Chris? What's your view on that? >> Yeah, I think what Adrian is alluding to, those leaky abstractions, are interesting, especially from the security perspective, 'cause I think what you see is if you were to happen to be able to thin slice across a set of specific types of workloads, there is a high probability given today that, at least on two of the three major clouds, you could get SaaS providers that sit on those same infrastructure of the service clouds for you, string them together, and have a service that technically is abstracted enough from the things you care about to work on one, two, or three, maybe not all of them, but most SaaS providers in the security space, or identity space, data space, for example, coexist on at least Microsoft and AWS, if not all three, with Google. And so you could technically abstract a service to the point that you let that level of abstract... Like Lori said, no computer science problem could not be... So, no computer science problem can't be solved with more layers of abstraction or misdirection... Or redirection. And in that particular case, if you happen to pick the right vendors that run on all three clouds, you could possibly get close. But then what that really talks about is then, if you built your seven-layer dip model, then you really have specialty superclouds spanning across infrastructure of the service clouds. One for your identity apps, one for data and data layers, to normalize that, one for security, but at what cost? Because you're going to be charged not for that service as a whole, but based on compute resources, based on how these vendors charge across each cloud. So again, that cost-benefit ratio might start being something that is rather imposing from a budgetary perspective. >> Lori, weigh in on this, because the enterprise people love to solve complexity with more complexity. Here, we need to go the other way. It's a commodity. So there has to be a better way. >> I think I'm hearing two fundamental assumptions. One, that a supercloud would force the existing big three to implement some sort of equal API. Don't agree with that. There's no business case for that. There's no reason that could compel them to do that. Otherwise, we would've convinced them to do that, what? 10, 15 years ago when we said we need to be interoperable. So it's not going to happen there. They don't have a good reason to do that. There's no business justification for that. The other presumption, I think, is that we would... That it's more about the services, the differentiated services, that are offered by all of these particular providers, as opposed to treating the core IaaS as the commodity it is. It's compute, it's some storage, it's some networking. Look at that piece. Now, pull those together by... And it's not OpenStack. That's not the answer, it wasn't the answer, it's not the answer now, but something that can actually pull those together and abstract it at a different layer. So cloud providers don't have to change, 'cause they're not going to change, but if someone else were to build that architecture to say, "all right, I'm going to treat all of this compute "so you can run your workloads," as Chris pointed out, "in the best place possible. "And we'll help you do that "by being able to provide those cost benefit analysis, "'What's the best performance, what are you doing,' "And then provide that as a layer." So I think that's really where supercloud is going, 'cause I think that's what a lot of the market actually wants in terms of where they want to run their workloads, because we're seeing that they want to run workloads at the edge, "a lot closer to me," which is yet another factor that we have to consider, and how are you going to be moving individual workloads around? That's the holy grail. Let's move individual workloads to where they're the best performance, the security, cost optimized, and then one layer up. >> Yeah, I think so- >> John Considine, who ultimately ran CloudSwitch, that sold to Verizon, as well as Tom Gillis, who built Bracket, are both rolling in their graves, 'cause what you just described was exactly that. (Lori laughing) Well, they're not even dead yet, so I can't say they're rolling in their graves. Sorry, Tom. Sorry, John. >> Well, how do hyperscalers keep their advantage with all this? I mean, to that point. >> Native services and managed services on top of it. Look how many flavors of managed Kubernetes you have. So you have a choice. Roll your own, or go with a managed service, and then differentiate based on the ability to take away and simplify some of that complexity. Doesn't mean it's more secure necessarily, but I do think we're seeing opportunities where those guys are fighting tooth and nail to keep you on a singular cloud, even though, to Lori's point, I agree, I don't think it's about standardized APIs, 'cause I think that's never going to happen. I do think, though, that SaaS-y supercloud model that we were talking about, layering SaaS that happens to span all the three infrastructure of the service are probably more in line with what Lori was talking about. But I do think that portability of workload is given to you today within lots of ways. But again, how much do you manage, and how much performance do you give up by running additional abstraction layers? And how much security do you give up by having to roll your own and manage that? Because the whole point was, in many cases... Cloud is using other people's computers, so in many cases, I want to manage as little of it as I possibly can. >> I like this whole SaaS angle, because if you had the old days, you're on Amazon Web Services, hey, if you build a SaaS application that runs on Amazon, you're all great, you're born in the cloud, just like that generations of startups. Great. Now when you have this super pass layer, as Dave Vellante was riffing on his analysis, and Lori, you were getting into this pass layer that's kind of like SaaS-y, what's the SaaS equation look like? Because that, to me, sounds like a supercloud version of saying, "I have a workload that runs on all the clouds equally." I just don't think that's ever going to happen. I agree with you, Chris, on that one. But I do see that you can have an abstraction that says, "Hey, I don't really want to get in the weeds. "I don't want to spend a lot of ops time on this. "I just want it to run effectively, and magic happens," or, as you said, some layer there. How does that work? How do you see this super pass layer, if anything, enabling a different SaaS game? >> I think you hit on it there. The last like 10 or so years, we've been all focused on developers and developer productivity, and it's all about the developer experience, and it's got to be good for them, 'cause they're the kings. And I think the next 10 years are going to be very focused on operations, because once you start scaling out, it's not about developers. They can deliver fast or slow, it doesn't matter, but if you can't scale it out, then you've got a real problem. So I think that's an important part of it, is really, what is the ops experience, and what is the best way to get those costs down? And this would serve that purpose if it was done right, which, we can argue about whether that's possible or not, but I don't have to implement it, so I can say it's possible. >> Well, are we going to be getting into infrastructure as code moves into "everything is code," security, data, (laughs) applications is code? I mean, "blank" is code, fill in the blank. (Lori laughing) >> Yeah, we're seeing more of that with things like CDK and Pulumi, where you are actually coding up using a real language rather than the death by YAML or whatever. How much YAML can you take? But actually having a real language so you're not trying to do things in parsing languages. So I think that's an interesting trend. You're getting some interesting templates, and I like what... I mean, the counterexample is that if you just go deep on one vendor, then maybe you can go faster and it is simpler. And one of my favorite vendor... Favorite customers right now that I've been talking to is Liberty Mutual. Went very deep and serverless first on AWS. They're just doing everything there, and they're using CDK Patterns to do it, and they're going extremely fast. There's a book coming out called "The Value Flywheel" by Dave Anderson, it's coming out in a few months, to just detail what they're doing, but that's the counterargument. If you could pick one vendor, you can go faster, you can get that vendor to do more for you, and maybe get a bigger discount so you're not splitting your discounts across vendors. So that's one aspect of it. But I think, fundamentally, you're going to find the CIOs and the ops people generally don't like sitting on one vendor. And if that single vendor is a horizontal platform that's trying to make all the clouds look the same, now you're locked into whatever that platform was. You've still got a platform there. There's still something. So I think that's always going to be something that the CIOs want, but the developers are always going to just pick whatever the best tool for building the thing is. And a analogy here is that the developers are dating and getting married, and then the operations people are running the family and getting divorced. And all the bad parts of that cycle are in the divorce end of it. You're trying to get out of a vendor, there's lawyers, it's just a big mess. >> Who's the lawyer in this example? (crosstalk) >> Well... (laughing) >> Great example. (crosstalk) >> That's why ops people don't like lock-in, because they're the ones trying to unlock. They aren't the ones doing the lock-in. They're the ones unlocking, when developers, if you separate the two, are the ones who are going, picking, having the fun part of it, going, trying a new thing. So they're chasing a shiny object, and then the ops people are trying to untangle themselves from the remains of that shiny object a few years later. So- >> Aren't we- >> One way of fixing that is to push it all together and make it more DevOps-y. >> Yeah, that's right. >> But that's trying to put all the responsibilities in one place, like more continuous improvement, but... >> Chris, what's your reaction to that? Because you're- >> No, that's exactly what I was going to bring up, yeah, John. And 'cause we keep saying "devs," "dev," and "ops" and I've heard somewhere you can glue those two things together. Heck, you could even include "sec" in the middle of it, and "DevSecOps." So what's interesting about what Adrian's saying though, too, is I think this has a lot to do with how you structure your engineering teams and how you think about development versus operations and security. So I'm building out a team now that very much makes use of, thanks to my brilliant VP of Engineering, a "Team Topologies" approach, which is a very streamlined and product oriented way of thinking about, for example, in engineering, if you think about team structures, you might have people that build the front end, build the middle tier, and the back end, and then you have a product that needs to make use of all three components in some form. So just from getting stuff done, their ability then has to tie to three different groups, versus building a team that's streamlined that ends up having front end, middleware, and backend folks that understand and share standards but are able to uncork the velocity that's required to do that. So if you think about that, and not just from an engineering development perspective, but then you couple in operations as a foundational layer that services them with embedded capabilities, we're putting engineers and operations teams embedded in those streamlined teams so that they can run at the velocity that they need to, they can do continuous integration, they can do continuous deployment. And then we added CS, which is continuously secure, continuous security. So instead of having giant, centralized teams, we're thinking there's a core team, for example, a foundational team, that services platform, makes sure all the trains are running on time, that we're doing what we need to do foundationally to make the environments fully dev and operator and security people functional. But then ultimately, we don't have these big, monolithic teams that get into turf wars. So, to Adrian's point about, the operators don't like to be paned in, well, they actually have a say, ultimately, in how they architect, deploy, manage, plan, build, and operate those systems. But at the same point in time, we're all looking at that problem across those teams and go... Like if one streamline team says, "I really want to go run on Azure, "because I like their services better," the reality is the foundational team has a larger vote versus opinion on whether or not, functionally, we can satisfy all of the requirements of the other team. Now, they may make a fantastic business case and we play rock, paper, scissors, and we do that. Right now, that hasn't really happened. We look at the balance of AWS, we are picking SaaS-y, supercloud vendors that will, by the way, happen to run on three platforms, if we so choose to expand there. So we have a similar interface, similar capability, similar processes, but we've made the choice at LastPass to go all in on AWS currently, with respect to how we deliver our products, for all the reasons we just talked about. But I do think that operations model and how you build your teams is extremely important. >> Yeah, and to that point- >> And has the- (crosstalk) >> The vendors themselves need optionality to the customer, what you're saying. So, "I'm going to go fast, "but I need to have that optionality." I guess the question I have for you guys is, what is today's trade-off? So if the decision point today is... First of all, I love the go-fast model on one cloud. I think that's my favorite when I look at all this, and then with the option, knowing that I'm going to have the option to go to multiple clouds. But everybody wants lock-in on the vendor side. Is that scale, is that data advantage? I mean, so the lock-in's a good question, and then also the trade-offs. What do people have to do today to go on a supercloud journey to have an ideal architecture and taxonomy, and what's the right trade-offs today? >> I think that the- Sorry, just put a comment and then let Lori get a word in, but there's a lot of... A lot of the market here is you're building a product, and that product is a SaaS product, and it needs to run somewhere. And the customers that you're going to... To get the full market, you need to go across multiple suppliers, most people doing AWS and Azure, and then with Google occasionally for some people. But that, I think, has become the pattern that most of the large SaaS platforms that you'd want to build out of, 'cause that's the fast way of getting something that's going to be stable at scale, it's got functionality, you'd have to go invest in building it and running it. Those platforms are just multi-cloud platforms, they're running across them. So Snowflake, for example, has to figure out how to make their stuff work on more than one cloud. I mean, they started on one, but they're going across clouds. And I think that that is just the way it's going to be, because you're not going to get a broad enough view into the market, because there isn't a single... AWS doesn't have 100% of the market. It's maybe a bit more than them, but Azure has got a pretty solid set of markets where it is strong, and it's market by market. So in some areas, different people in some places in the world, and different vertical markets, you'll find different preferences. And if you want to be across all of them with your data product, or whatever your SaaS product is, you're just going to have to figure this out. So in some sense, the supercloud story plays best with those SaaS providers like the Snowflakes of this world, I think. >> Lori? >> Yeah, I think the SaaS product... Identity, whatever, you're going to have specialized. SaaS, superclouds. We already see that emerging. Identity is becoming like this big SaaS play that crosses all clouds. It's not just for one. So you get an evolution going on where, yes, I mean, every vendor who provides some kind of specific functionality is going to have to build out and be multi-cloud, as it were. It's got to work equally across them. And the challenge, then, for them is to make it simple for both operators and, if required, dev. And maybe that's the other lesson moving forward. You can build something that is heaven for ops, but if the developers won't use it, well, then you're not going to get it adopted. But if you make it heaven for the developers, the ops team may not be able to keep it secure, keep everything. So maybe we have to start focusing on both, make it friendly for both, at least. Maybe it won't be the perfect experience, but gee, at least make it usable for both sides of the equation so that everyone can actually work in concert, like Chris was saying. A more comprehensive, cohesive approach to delivery and deployment. >> All right, well, wrapping up here, I want to just get one final comment from you guys, if you don't mind. What does supercloud look like in five years? What's the Nirvana, what's the steady state of supercloud in five to 10 years? Or say 10 years, make it easier. (crosstalk) Five to 10 years. Chris, we'll start with you. >> Wow. >> Supercloud, what's it look like? >> Geez. A magic pane, a single pane of glass. (laughs) >> Yeah, I think- >> Single glass of pain. >> Yeah, a single glass of pain. Thank you. You stole my line. Well, not mine, but that's the one I was going to use. Yeah, I think what is really fascinating is ultimately, to answer that question, I would reflect on market consolidation and market dynamics that happens even in the SaaS space. So we will see SaaS companies combining in focal areas to be able to leverage the positions, let's say, in the identity space that somebody has built to provide a set of compelling services that help abstract that identity problem or that security problem or that instrumentation and observability problem. So take your favorite vendors today. I think what we'll end up seeing is more consolidation in SaaS offerings that run on top of infrastructure of the service offerings to where a supercloud might look like something I described before. You have the combination of your favorite interoperable identity, observability, security, orchestration platforms run across them. They're sold as a stack, whether it be co-branded by an enterprise vendor that sells all of that and manages it for you or not. But I do think that... You talked about, I think you said, "Is this an innovator's dilemma?" No, I think it's an integrator's dilemma, as it has always ultimately been. As soon as you get from Genesis to Bespoke Build to product to then commoditization, the cycle starts anew. And I think we've gotten past commoditization, and we're looking at niche areas. So I see just the evolution, not necessarily a revolution, of what we're dealing with today as we see more consolidation in the marketplace. >> Lori, what's your take? Five years, 10 years, what does supercloud look like? >> Part of me wants to take the pie in the sky unicorn approach. "No, it will be beautiful. "One button, and things will happen," but I've seen this cycle many times before, and that's not going to happen. And I think Chris has got it pretty close to what I see already evolving. Those different kinds of super services, basically. And that's really what we're talking about. We call them SaaS, but they're... X is a service. Everything is a service, and it's really a supercloud that can run anywhere, but it presents a different interface, because, well, it's easier. And I think that's where we're going to go, and that's just going to get more refined. And yes, a lot of consolidation, especially on the observability side, but that's also starting to consume the security side, which is really interesting to watch. So that could be a little different supercloud coming on there that's really focused on specific types of security, at least, that we'll layer across, and then we'll just hook them all together. It's an API first world, and it seems like that's going to be our standard for the next while of how we integrate everything. So superclouds or APIs. >> Awesome. Adrian... Adrian, take us home. >> Yeah, sure. >> What's your- I think, and just picking up on Lori's point that these are web services, meaning that you can just call them from anywhere, they don't have to run everything in one place, they can stitch it together, and that's really meant... It's somewhat composable. So in practice, people are going to be composable. Can they compose their applications on multiple platforms? But I think the interesting thing here is what the vendors do, and what I'm seeing is vendors running software on other vendors. So you have Google building platforms that, then, they will support on AWS and Azure and vice versa. You've got AWS's distro of Kubernetes, which they now give you as a distro so you can run it on another platform. So I think that trend's going to continue, and it's going to be, possibly, you pick, say, an AWS or a Google software stack, but you don't run it all on AWS, you run it in multiple places. Yeah, and then the other thing is the third tier, second, third tier vendors, like, I mean, what's IBM doing? I think in five years time, IBM is going to be a SaaS vendor running on the other clouds. I mean, they're already halfway there. To be a bit more controversial, I guess it's always fun to... Like I don't work for a corporate entity now. No one tells me what I can say. >> Bring it on. >> How long can Google keep losing a billion dollars a quarter? They've either got to figure out how to make money out of this thing, or they'll end up basically being a software stack on another cloud platform as their, likely, actual way they can make money on it. Because you've got to... And maybe Oracle, is that a viable cloud platform that... You've got to get to some level of viability. And I think the second, third tier of vendors in five, 10 years are going to be running on the primary platform. And I think, just the other final thing that's really driving this right now. If you try and place an order right now for a piece of equipment for your data center, key pieces of equipment are a year out. It's like trying to buy a new fridge from like Sub-Zero or something like that. And it's like, it's a year. You got to wait for these things. Any high quality piece of equipment. So you go to deploy in your data center, and it's like, "I can't get stuff in my data center. "Like, the key pieces I need, I can't deploy a whole system. "We didn't get bits and pieces of it." So people are going to be cobbling together, or they're going, "No, this is going to cloud, because the cloud vendors "have a much stronger supply chain to just be able "to give you the system you need. "They've got the capacity." So I think we're going to see some pandemic and supply chain induced forced cloud migrations, just because you can't build stuff anymore outside the- >> We got to accelerate supercloud, 'cause they have the supply. They are the chain. >> That's super smart. That's the benefit of going last. So I'm going to scoop in real quick. I can't believe we can call this "Web3 Supercloud," because none of us said "Web3." Don't forget DAO. (crosstalk) (indistinct) You have blockchain, blockchain superclouds. I mean, there's some very interesting distributed computing stuff there, but we'll have to do- >> (crosstalk) We're going to call that the "Cubeverse." The "Cubeverse" is coming. >> Oh, the "Cubeverse." All right. >> We will be... >> That's very meta. >> In the metaverse, Cubeverse soon. >> "Stupor cloud," perhaps. But anyway, great points, Adrian and Lori. Loved it. >> Chris, great to see you. Adrian, Lori, thanks for coming on. We've known each other for a long time. You guys are part of the cloud-erati, the group that has been in there from day one, and watched it evolve, and you get the scar tissue to prove it, and the experience. So thank you so much for sharing your commentary. We'll roll this up and make it open to everybody as additional content. We'll call this the "outtakes," the longer version. But really appreciate your time, thank you. >> Thank you. >> Thanks so much. >> Okay, we'll be back with more "Supercloud 22" right after this. (bright upbeat music)

>> Narrator: Live from San Juan, Puerto Rico. It's theCUBE, covering Blockchain Unbound. Brought to you by Blockchain Industries. >> Hello everyone, welcome back to our exclusive coverage of, in Puerto, Rico for Blockchain Unbound. This is the industry conference room. People around the world from Silicon Valley, New York, and around the glove, coming to Puerto, Rico to talk about Blockchain decentralized internet cryptocurrency and really the future of society and global economic value creation of course our continuing coverage is focusing La Sierra for 2018. Our next guest is Mark Jeffery, CEO and Co-Founder of a company called Guardian Circle. Welcome. >> Thank you, thanks for having me. >> So you guys are doing something really interesting, so we, first of all, we like to geek out, as Fred say, "We're alpha-geeks." But we love IoT, cloud computing. You're doing something really interesting right now with Blockchain and this new decentralized internet around something of a critical infrastructure nature. Take a minute to talk about Guardian Circle's product, the coin, token that you're doing, and what it all means. >> So, Guardium is the token, the company's called Guardian Circle. Together they comprise global decentralized emergency response. So, six billion people on earth have no 911, There's just no magic number you can call, right? So hold that in your mind for a second. The other one billion of us, we do have 911, but it's not very good, it hasn't been really updated since the 60's. If you call 911 and if you're lucky enough to not get a busy signal, they have no idea where you are. Your location information is not transmitted. Which Uber can find you more easily than 911. Which is just insane, but that is the way it is. So, nevermind, so throw all that out >> So 911 is broken? 911 is broken. >> Yep If you have it, it's broken, and most people don't have it, so throw the whole thing out the window, let's start over. What would we build today? The way the world should work is whenever you're in trouble, no matter where you are on the globe, all you should have to do is press a button, that button sends an alert up to the Cloud, the Cloud looks down and sees what people and resources are already nearby, and then activates, coordinates, pushes all that help to you as quickly as possible. So, ten people in three minutes. That's what were, that's our-- >> So a couple things going on. So to me when you say, what should we start from scratch, put in my little operating system design network solutions add on, all kind of rolled into one as a stable, fault-tolerant, resilient, robust, always on network. >> Yes. >> Database that is fully interoperable and updated in real time of every number, every location, every persons capability to understand the discovery and resolution of a number. >> Yeah, so >> So that sounds like the internet. That sounds like the internet. >> (laughs) Well that's a little bit, probably further than we're going right now, but yes. Ultimately, you're correct. That would be the ultimate-- >> So no legacy baggage, 1960's Telco. >> No >> We're talking about immobile, in Africa for instance, there's more mobile penetration than anything else. That's what they got. >> Yes. >> So every country is their own sovereign kind of architecture? >> Yes >> Are you guys looking at it from a global perspective or regional? >> Global, so we think that, I mean, this is, this thing should be mobile native, location aware, and the alert should go out to multiple parties. And the phone number is your identifier in this system, but it's effectively an IP based system, really, so you're right. We have to balance that against privacies, so you get to decide who is on your alert grid, right? So you have to emphatically say, yes my friends, family and neighbors, and the subscription services, and if available, these official services. >> So Blockchain can solve the immutability privacy issue? >> Yes. >> The decentralized nature of network effect is a dynamic that people look for in good deals or good architecture. That's in place. >> Yes. >> People have a social graph, interest graphs connections. So the analog world is going digital. I mean, the old days was, is there a doctor in the house? But you were limited by how far you could yell. >> Right. >> So here you're saying literally, if you connect properly, the users in charge are their, their data. >> Yeah. >> They can dictate what they want to connect to, where, is that kind of how it works, is it peer to peer? >> Yeah, it's sort of peer to peer. I mean, a lot of people think, a lot of people mishear me a little bit and think that when you press that button, the alert goes out to everybody that's nearby, right? So total strangers that may or may not be trustworthy are suddenly coming, that's not what I'm saying. That is not what we're doing because we don't want to accidentally summon Jack the Ripper, like that's, you don't want to make a bad situation worse, right? So, you explicitly invite people into your protection grid, we call them guardians, hence, Guardian Circle, that would be your guardian circle. And you can have an unlimited number of them, so six, 6000, however many friends you have. Then we will also feature paid subscription services where you will be able to subscribe to, like, your local EMT collective, or your local license and bonded arms security, or if you're in a remote corner of the world, you could subscribe to the guy with a truck, who could run you down the mountain, right? When you're having medical problems. So it's going to vary depending on where you are in the world. We're also working with the Women's Safety Xprize, we're a partner, we're the backend of that prize. Which is an IoT device contest to make a panic button device, right? So when you push the panic button, what happens? It goes into Guardian Circle. >> So how does token economics fit into this? So I'm getting why it's tokenizable, How does it work mechanically? Do I buy tokens for safety? Is it like, I mean, take us through some of the use cases. >> Yeah sure, so there's five different ways in which we use the token. The first one is, obviously, to create the, to buy emergency response subscriptions. Now we're going to allow you, or provide a way for you to, as a consumer, just swipe your credit card in the app, and in the background you'll be purchase Guardium tokens, right? And it'll re-up every month if you don't have enough in, it'll be that sort of thing. So you might not even really be conscious of the fact that you're using cryptocurrency. If you are, there's a wallet that'll allow you to just use the cryptocurrency manually, the way you do any, any right now, right? >> And. >> So there's that. >> Okay so continue. >> Yep, the second thing we're going to do, we think that giving will be a big behavior in our universe, so you're going to be able to send Guardium directly to a beneficiary in the developing world. And what's cool about that is it doesn't go through a governments, a bank, or an organization. So remember Red Cross in Haiti? Can't happen here, and we're going to go even further than that, down the road, you're going to be able to track every dollar that you donated as easily as a FedEx, right? >> So you are creating a direct relationship between people who might want to help people and then a direct access for resources for the user. >> Correct. >> And so that's the primary, kind of a two >> That's one major flywheel. >> major flywheels going on. >> Just like people sponsor a child, safety is one of the biggest problems in the world. In fact, some people say, this guy named, Greg Hahn, who says it's the number one problem in the world that all other problems flow from the fact that people in the developing world aren't safe. Why don't they have water? Cause they're not safe. Why don't they have education? Cause they're not safe. Lawlessness has to be solved first. >> Trust is a huge part of this too. >> Yeah. >> So how do I set this up, where are you guys in the system, is there a product up and running, how do people get involved with your project? Take a minute to share that. >> Sure, so we have apps released today and they're distributed world-wide on IOS, Android, and Alexa. We also have an open API that lets anyone plug any alert device into our grid, obviously we have to, we want to know who you are first, but basically everyone is welcome. And so, and then our token sales site is at Guardium, Guardium.co. >> G, Guard, ium, Guardium. >> Yes, Guardium. >> And then Guardian Circle? >> Correct. >> Guardium with the m and the end of the token. What's the plan, what are you guys, how much have you raised, what's the story? Yeah, so we're selling ten million dollars worth of tokens, which represents 30% overall, 33% overall. We have a 100 million tokens in the sys, that, that's it, that will ever be distributed. It's on the NEO Blockchain, so we are, we are, we're sort of different from a lot of other folks. We're one of the very first western, we're not the first but we're one of the firsts. >> NEO has a good reputation of high performance. >> Yes >> Is that one of the considerations you had for them? >> Yeah, without a doubt. I mean, we deal in emergencies, so our tolerance for things like CryptoKitty swamping the network is very low. So yeah, so we liked what NEO had to say in a lot of ways because of that. >> I interviewed the CryptoKitties at Polycon, interesting story. It's a Pokemon moment for the internet stare. Well congratulations Mark, what's next for you guys, get through the sale, how's the team makeup look, what's going on with the company? >> Yeah, get through, I mean, definitely get through the sale is the biggest thing right now. We're a small team of, like about five people, plus some contractors. The next big thing that we have on our agenda is we're going out to India in four weeks to actually test the Xprize IoT panic button devices on the streets of Mumbai, so Guardian Circle plus device. >> Intense environment a lot of people there. >> Yeah. >> So let's talk about you. What is your background that got you here, or was there an itch you were scratching? Why this time, also the way to attract a lot of alph entrepreneurs, this is a disruptive time, but why Mark Jeffrey's, why now, why Guradian Circle, what's the passion behind it? >> So, well I started life as an engineer, but I won't bore you with all my adventures up until this moment. But in 2013, I became very interested in Bitcoin, wrote a book called, Bitcoin Explained Simply. Got the book, got the little crazy thoughts in my head. >> You're an author, speaker >> Right, same thing. >> distinguished influencer. (laughs) >> So that was sort of how that side began. In 2014, I basically, my girlfriend at the time had a stroke, she's fine, but at the time she was all alone. And she was on the floor of her garage, and I took her to the hospital, brought her back, and afterwards, I realized, she was alone for about a half an hour, if this had been a real stroke, this could have been very serious, she could have died, she could have been paralyzed. And she was drowning in help, there were about seven people who were either driving by or nearby while this was going on, within a 1000 yards. And she had no way to get to them. >> Yeah, yeah, a personal example of what you're doing. >> And I also realized, the other component was, all the help, I didn't know six, five of the other six people, they're her friends, they're not mine. But during her emergency, all of us need to be sharing location and in communication with each other immediately. And the importance of that just cannot be overstated in emergencies, seconds count. And so putting instant communications so that we can coordinate a response is the second-half of the problem. I initially did not intend to build an app. I went looking for this app and what I discovered was there are a ton of panic button apps, but all of them neglected solving the second-half of the problem, which is organizing the response. >> Yeah. >> And getting people on, in the same-- >> Mobilizing resources. >> Yeah, getting everyone into a war room without requiring them to know each other ahead of time, that was the big thing, no one had thought of that, so. >> It's like rolling up services when you need it instantly. It's like a compiler. >> It's at hawk services. >> You know, compile everything >> Yes, exactly. >> at real time assembly. >> Real time assembly, yeah >> Operating system. (laughs) >> that's exactly, it's great. That's actually a really good way to put it, yeah. >> No, but this is also pretty important, so it was a great personal example, thanks for sharing that personal story. But you know, there's a avalanches, whether you're a skier, it's people who go rock climbing, there's all kinds of use cases where a mountain biker is missing, all kinds of-- >> Remote locations are really big ones. >> I'm scuba diving, where are people, where were they last? So a lot of this is, are location based, and no one knows what the situation is, so the alerting is only one step to the value chain. >> It is, but I think, sorry you have a question. >> No, no, I was going to ask you, where does it go from there? >> Well I think, I think there are a lot of, I think safety check-ins, I think there's other things that we can do, but the one thing that, the one lesson that I've seen again, and again, and again, and again is that the companies that fail invariably, oh, the companies that don't focus always fail. So you got to pick one thing and be the best in the world at that one thing. And the emergency situation is our one thing, and that's big enough. >> Well, I think you have a great opportunity and we'll splint through the, as the evolution of this market grows, it's kind of a moving train, but the value promises is legit. I was talking to Fred Krueger, your friend and colleague in the business, it's a marketplace of these days, so it's money and marketplaces, in your case it's safety, marketplace. I could envision a day with your services where I publish and subscribe to services, I got in a catalog. >> Yes. >> Hey, I know my risks, everyone knows what they do in vanity, or risk factors whether you're jumping out of an airplane, or double black diamond skier. I would love to go to Lake Tahoe, or a mountain, or a place like this, and saying, I'm going to take some chances, here's what I'm going to subscribe to. >> (laughs) You're going to have to subscribe to some extra tokens while you're there. >> I would use Guardium. It could be more, I'm just brainstorming, thinking out loud, but I mean, that's the kind of web services framework you could bring. >> That's exactly right. >> Is that they way you guys are thinking about it? >> I do, I do, I'm so focused on this sort of food and shelter stage of our life right now. >> Yeah, get an ICO done. So yeah, we've got tons of all those ideas written done but we're not quite there yet, but when we get there, great ideas, absolutely. >> Well the use cases are changing because the peoples expectations are changing and now technology can meet these cases. So I'm seeing a lot of social entrepreneurship being done that are coming in through a funding vehicles that never would have got funded on venture capital funding. >> Totally correct. >> Whether it's battered women applications, human trafficking, safety apps, stuff that can make money, not be a kazillion, billion dollar business, but really change society and makeup. >> You've hit the nail on the head. There are a lot of Blockchain companies or ICO companies, this stuff, the venture guys, would never fund it because their model doesn't allow for it. They have, all these things have to be Facebook potentially, or they just have no tolerance for it. >> And the philanthropy world is not incented on economics, and also when the project loses its grant or funding the stack just gets thrown away. >> So this allows for sustainability for mission-based investing and developing. Slowly, I see societal entrepreneurship categorically going to boom from this wave. >> Yeah, totally agree. >> Across the board. >> The world will become a better place, we'll have better companies. >> Mark Jeffery, Guardian Circle, co-founder and CEO. This is theCUBE's exclusive coverage here on the ground in Puerto, Rico for Blockchain Unbound. A lot of great stuff here, a lot of great start-ups, investors, of course theCUBE. 2018 will be covering all the shows. I'm John Furrier, thanks for watching.