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

>> Hey, welcome back everybody. Jeff Frick here with the CUBE. We are in downtown San Francisco at the Twitter headquarters for a big event, the Data Privacy Day that's been going on for years and years and years. It's our first visit and we're excited to be here. And our next guest is going to talk about something that is near and dear to all of our hearts. Eve Maler, she's the VP Innovation and Emerging Technology for ForgeRock. Welcome. >> Thank you so much. >> Absolutely. So for people who aren't familiar with ForgeRock, give us a little background on the company. >> Sure. So, of course, the digital journey for every customer and consumer and patient and citizen in the world is so important because trust is important. And so what ForgeRock is about is about creating that seamless digital identity journey throughout cloud, mobile, internet of things, devices, across all of their experiences in a trustworthy and secure way. >> So one of the topics that we had down and getting ready for this was OAuth. >> Yes. >> And as the proliferation of SAS applications continues to grow both within our home life as well as our work life, we have these pesky things called passwords which no one can remember and they force you to change all the time. So along comes OAuth. >> Yes. So OAuth is one of those technologies... I'm kind of a standards wonk. I actually had a hand in creating XML for those people who remember XML. >> Jeff: That's right. >> OAuth took a tact of saying, "Let's get rid of what's called the password anti-pattern. "Let's not give out our passwords to third party services and applications so that we can just give those applications what's called an access token. Instead it's meant just for that application. In fact, Twitter... We're heard at Twitter headquarters. Twitter uses that OAuth technology. And I'm involved in a standard, being a standards wonk, that builds on top of OAuth called user managed access. And it uses this so that we can share access with applications in the same way. And we can share access also with other people using applications. So for example, the same way we hit a share button in Google, Alice hits a share button to share access with a document with Bob. We want to allow every application in the world to be able to do that, not just GoogleDocs, GoogleSheets, and so on. So OAuth is powerful and user managed access is powerful for privacy in the same way. >> Now there's OAuth and I use my Twitter OAuth all the time. Or with Google. >> That's right. >> And then there's these other kind of third party tools which add kind of another layer. >> So you might use like tweetbot is something I like to use on my phone to tweet. >> Jeff: Right, right. >> And so there's... >> Well there's the tweetbot. But then there's these pure, like identity password manager applications which you know you load it into there and then... >> LastPass or something like that. >> Right, right, right. >> One password people use yeah >> To me it's just like wow, that just seems like it's adding another layer. And if oh my gosh, if I forget the LastPass password, I'm really in bad shape. >> You are. >> Not just the one application, but a whole bunch. I mean, how do you see the space kind of evolving to where we got to now? And how is it going to change going forward? It just fascinates me that you still have passwords when our phones have fingerprint. >> TouchID. >> Why can't it just work off my finger? >> More and more, SAS services and applications are actually becoming more sensitive to multifactor authentication, strong authentication, what we at ForgeRock would actually call contextual authentication and that's a great way to go. So they're leveraging things like TouchID, like device fingerprint, for example. Recognizing that the devices kind of represents you and your unique way of using the device. And in that way, we can start to do things like what's called a password list flow. Where it can, most of the time, or all of the time, actually not even use a password. And so, I don't know, I used to be an industry analyst and 75 percent of my conversations with folks like you would be about passwords. And more frequently, I would say now, we're getting into the topic of people are more password savvy and more of the time people are turning on things like multifactor authentication and more of that it knows the context that I'm using my corporate WiFi which is safer. Or I'm using a familiar device. And that means I don't have to use the password as often. So that's contextual authentication. Meaning I don't have to use that insecure password so often. >> Jeff: Right. >> So I think the world has gotten actually a little bit smarter about authentication. I'm hoping. And actually, technologies like OAuth and the things that are based on OAuth like OpenIDConnect which is an identity technology, a modern identity, federated identity technology. And things like user managed access are leveraging the fact that OAuth is getting away from having to use, if it was a password based authentication, not flinging the password around the internet, which is the problem. >> Right, right. Okay so that's good, that's getting better, but now we have this new thing. Internet of things. >> Yes indeed. >> And people are things. But now we've got connected devices, they're not necessarily ones that I purchased, that I authorized, that I even maybe am aware of. >> Like a beacon on a wall, just observing you. >> Like a beacon on a wall and sensors, and the proliferation is just now really starting to run. So from a privacy point of view, how does kind of IOT that I'm not directly involved with compare to IOT with my Alexa compare to applications that I'm actively participating in. How do those lines start to blur? And how does the privacy issues kind of spill over now into managing this wild world of IOT? >> Yeah, there's a couple of threads with the Internet of Things. And so I'm here today at this Data Privacy Day Event to participate on a panel about the IOT tipping point. And there's a couple of threads that are just really important. One is the security of these devices is in large part, a device identity theft problem with this dyn attack. In fact, that was an identity theft problem of devices. We had poorly authenticated devices. We had devices that have identities they have identities, they have identifiers, and they have secrets. And it was a matter of their own passwords being easily taken over. It was account takeovers, essentially for devices, that was the problem. And that's something we have to be aware of. So, you know, just like applications and services can have identities, just like people, we've always known that. It's something our platform can handle. We need to authenticate our devices better and that's something manufacturers have to take responsibility for. >> Jeff: Right. >> And we can see the government agencies starting to crack down on that which is a really good thing. The second thing is there's a saying in the healthcare world for people who are working on patient privacy rights, for example. And the saying is, no data about me without me. So there's got to be a kind of a pressure, you know we see whenever there's a front page news article about the latest password breach. We don't actually see so many password breaches anymore as we see this multifactor authentication come in to play. So that's the industry pressures coming in to play. Where passwords become less important because we have multifactor. We're starting to see consumer pressure say I want to be a part of this. I want you to tell me what you shared. I want more transparency, and I want more control. And that's got to be part of the equation now when it comes to these devices. It's got to be not just more transparent, but what is it you're sharing about me? >> Jeff: Right. >> Last year I actually bought, maybe this is TMI, I always have this habit of sharing too much information, >> That's okay, we're on theCUBE we like >> Being honest here. >> To go places other companies don't go. >> I bought one of those adjustable beds that actually has an air pump that... >> What's your number? Your sleep number. >> It is, it's a Sleep Number bed and it has a feature that connects to an app that tells you how well you slept. You look at the terms and conditions and it says we own your biometric data, we are free to do whatever we want. >> Where did you even find the terms and conditions? >> They're right there on the app, to use the app. >> Oh in the app, in the app. >> You have to say yes. >> So you actually read before just clicking on the box. >> Hey, I'm a privacy pro, I've got to. >> Right, right, right. >> And of course, I saw this, and to use the feature, you have to opt in. >> Right. >> This is the way it is. There's no choice, and they probably got some lawyer... This is the risk management view of privacy. It's no longer tenable to have just a risk management view because the most strategic and the most robust way to see your relationship with your customers is you have to realize there's two sides to the bargain because businesses are commoditized now. There's low switching costs to almost anything. I mean, I bought a bed, but I don't have to have that feature. >> Do you think, do you think they'll break it up? So you want the bed, you're using a FitBit or something else to tell you whether you got a good night's sleep or not. Do you see businesses starting to kind of break up the units of information that they're taking and can they deliver an experience based on a fragmented selection? >> I do believe so. So, user managed access and certain technologies like it, standards like it, there's a standard called consent receipts. They're based on a premise of being able to now deliver convenient control to users. There's even, so there's regulations that are coming like the general data protection regulation in the EU. It's bearing down on pretty much every multinational, every global enterprise that monitors or sells to an EU citizen. That's pretty much every enterprise. >> Jeff: Right, right. >> That demands that individuals get some measure of the ability to withdraw consent in a convenient fashion. So we've got to have consent tech that measures up to the policy that these >> Right. >> organizations have to have. So this is coming whether we sort of like it or not. But we should have a robust and strategic way of exposing to these people the kind of control that they want anyway. >> Jeff: Right. >> They all tell us they want it. So in essence, personal data is becoming a joint asset. We have to conceive of this that way. >> So that's in your... So that's in your sleep app, but what about the traffic cameras and the public facility? >> Yeah. >> I mean, they say in London right you're basically on camera all the time. I don't know if that's fact or not, but clearly there's a lot >> That's true, CCTV, yeah. Of cameras that are tracking your movements. You don't get a chance to opt in or out. >> That is actually true, that's a tough case. >> You don't know. >> The class of... Yeah. The class of beacons. >> And security, right. Obviously, post 9/11 world, that's usually the justification for we want to make sure something bad doesn't happen again. We want to keep track. >> Yeah. >> So how does kind of the government's role in that play? And even in the government, then you have you know all these different agencies, whether it's the traffic agency or even just a traffic camera that maybe KCBS puts up to keep track of you know, it says slow down >> Yeah. >> Between two exits. How does that play into this conversation? >> Yeah, where you don't have an identified individual. And not even an identifiable individual, these are actually terms if you look at GDPR, which I've read closely. It is a tougher case, although I have worked... One of the members of my user managed access working group is one of the sort of experts on UK CCTV stuff. And it is a very big challenge to figure out. And governments do have a special duty of care to figure this out. And so the toughest cases are when you have beacons that just observe passively. Especially because the incentives are such that, I will grant you, the incentives are such that, well how do they go and identify somebody who's hard to identify and then go inform them and be transparent about what they're doing. >> Jeff: Right, right. >> So in those cases, even heuristically identifying somebody is very, very tough. However, there is a case where eye beacons in, say, retail stores do have a very high incentive to identify their consumers and their retail customers. >> Right. >> And in those cases, the incentives flip in the other direction towards transparency and reaching out to the customer. >> Yeah. The tech of these things of someone who I will not name, recently got a drive through red light ticket. >> Yep. >> And the clarity of the images that came in that piece of paper that I saw was unbelievable. >> Yes. >> So I mean, if you're using any kind of monitoring equipment, the ability to identify is pretty much there. >> Now we have cases... So this just happened, actually I'm not going to say, do I say it was to me or to my husband? It was in a non-smart car in a non-smart circumstance where simply a red light camera that takes a picture of an identified car, so you've got a license plate and that binds it to a registered owner of a car. >> Right. >> Now I have a car that's registered in the name of a trust. They didn't get a picture of the driver. They got a picture of the car. So now here we can talk about, let's translate that from a dumb car circumstance, registered to a trust, not to an individual, they sent us what amounted to a parking ticket. Cause they couldn't identify the driver. So now that gives us an opportunity to map that to an IOT circumstance. Because if you've got a smart device. You've got a person, you've got a cloud account. What you need to do is the ability to, in responsible secured fashion, bind a smart device to a person and their cloud account. And the ability to unbind. So now we're back to having an identity centric architecture for security and privacy that knows how to... I'll give you a concrete example, let's say you've got a fleet vehicle in a police department. You assign it to whatever cop on the beat. And at the end of their shift, you assign the car to another cop. What happens on one shift and what happens on another shift is a completely different matter. And it's a smart car, maybe it's a cop who has a uniform with some sort of camera, you know body cam. That's another smart device, and those body cams also get reassigned. So you want whatever was recorded, in the car, on the body cam, with the cop, and with their whatever online account it is, you want the data to go with the cop, only when the cop is using the smart devices that they've been assigned and you want the data for somebody else to go with the somebody else. So in these cases, the binding of identities and the unbinding of identities is critical to the privacy of that police person. >> Jeff: Right, right. >> And to the integrity of the data. So this is why I think of identity centric security and privacy as being so important. And we actually say, at ForgeRock, we say identity relationship management is being so key. >> And whether you use it or not, it is really kind of after the fact of being able to effectively tie the two together. >> You have to look at the relationships in order to know whether it's viable to associate the police person's identity with the car identity. Did something happen to the car on the shift? Did something through the view of the camera on the shift? >> Right, right. And all this is underlaid by trust, which has come up in a number of these interviews today. And unfortunately we're in a situation now if you read all the surveys. And the government particularly, these are kind of the more crazy cases cause businesses can choose to or not to and they've got a relationship with the customer. But on the government side, where there's really no choice, right, they're there. Right now, I think we're at a low point on the trust factor. >> Indeed. >> So how is that, and if you don't trust, then these things are seen as really bad as opposed to if you do trust and then maybe they're just inconvenient or they're not quite worked out all the way. So as this trust changes and fake news and all this other stuff going on right now, how is that impacting the implementation of these technologies? >> Well ask me if I said yes to the terms and conditions. (laughter) Of the sleep app, right. I mean I said yes, I said yes. And I didn't even ask for the app, you know my husband signed up for the free trial. >> Just showed up on my phone. Cause I was in proximity >> I said this one on stage >> to the bed, right? >> at RSA so this is not news. I'm not breaking news here. But you know, consumers want the features, they want convenience, they want value. So it's unreasonable, I believe to simply mount an education campaign and thereby change the world. I do think it's good to have general awareness of what to demand and that's why I say no data about me without me. That's what people should be demanding is to be let in to the loop. Because that gives them more convenience and value. >> Right. >> They want share buttons. I mean, we saw that with the initial introduction of CareKit with Apple. Because that enabled what, people who are involved in user managed access, we call ourselves Umanitarians. So umanitarians like to say, like to call it Alice to Bob sharing, that's the use case. >> Jeff: Okay. >> And it enabled Alice to Dr. Bob sharing. That's a real use case. And IOT kind of made real that use case. When web and mobile and API, I don't think we thought about it so much as a positive use case, although in healthcare it's been a very real thing with EHR. You know you can go into your EHR system and you can see it, you can share with a spouse your allergy record or something, it's there. >> Right, right, right. >> But with IOT, it's a really positive thing. I've talked to folks in my day job about sharing access to a connected car to a remote user. You know, we've seen the experiments with let somebody deliver a package into the trunk of my car, but not get access to driving the car. These are real. That's better than saving >> I've heard that one actually >> Saving a little money by having smart light bulbs is not as good as you've got an Airbnb renter and you want to share limited access to all your stuff while you're away with your renter and then shut down access after you leave, that's an uma use case, actually. And that's good stuff. I could make money. >> Jeff: Right. >> Off of sharing that way. That's convenience and value. >> It's only, I just heard the other day that Airbnb is renting a million rooms a night. >> There you go. >> So not insignificant. >> So once you've have... You have a home that's bristling with smart stuff, you know. That's when it really makes sense to have a share button on all that stuff. It's not just data you're sharing. >> Well Eve, we could go on and on and on. >> Apparently. >> Are you going to be at RSA in a couple of weeks? >> Absolutely. >> Absolutely. >> I'm actually speaking about consent management. >> Alright, well maybe we'll see you there. >> That would be great. >> But I want to thank you for stopping by. >> It's a pleasure. >> And I really enjoyed the conversation. >> Me too, thanks. >> Alright, she's Eve, I'm Jeff, you're watching theCUBE. We'll catch you next time, thanks for watching. (upbeat music)