>> Announcer: From around the globe, it's theCUBE! With digital coverage of AnsibleFest 2020, brought to you by Red Hat. >> Hello, everyone, welcome back to theCUBE's coverage of AnsibleFest 2020. We're not face-to-face this year, we're in virtual remote mode. This is theCUBE virtual and obviously it's AnsibleFest 2020 virtual. We've got a great panel of experts and leaders at Red Hat and Ansible. I want to introduce them. Dave Lindquist, general manager and vice president of engineering of hybrid cloud management at Red Hat. Joe Fernandes, vice president and general manager of the Core Cloud platforms at Red Hat. And Tom Anderson, vice President at Red Hat, Ansible Automation Platform, the big news and feature of this event. Tom, great to see you, Joe and David, thanks for coming on. >> Great to be here. >> Every year I love talking about Red Hat because I remember going back a few years ago, Arvind from IBM was on at Red Hat Summit in San Francisco, and you can see the twinkle in his eye. This was three, four years ago. Cloud native was really gearing up and now it's kind of mainstream. Last year at AnsibleFest, all the buzz was collaboration, collections, and you can start to see that integration piece kicking in, and this year at the event, the big story is the same. More collections, more integrations, a lot of collaboration around code. Content equals code. So it really points to the trend with Kubernetes of multi-cloud, multi-cluster. So the first question for you guys is, why would anyone want to deploy multiple clusters simultaneously and why is multi-cluster such a big deal? Tom, we'll start with you. >> Great, okay, yeah. So why is multi-cluster such a big deal? Basically, Kubernetes and our OpenShift container platform have now become a strategic part of our customers' environments, of their infrastructure for building and deploying cloud native applications on. And as becoming a strategic part of that, when you're deploying production applications you're going to need all kinds of things like scale out, redundancy, cloud location for access to different cloud provider locations for application requirements and whatnot. So there are a bunch of requirements for why customers would deploy OpenShift in a multi-cluster way. And maybe I'll turn it over to Joe Fernandes a little bit 'cause he's got a lot of background on the OpenShift side of this. >> Joe, what's your thoughts? >> Yeah, thanks, Tom. Yeah, so I mean, as Tom mentions, a number of reasons why customers may deploy or need to deploy more than one Kubernetes cluster. So within a cluster, you can certainly have multiple applications, multiple developers, multiple teams work, but as you start to scale your usage you may want additional clusters. It could be because you want to separate your production environments from your dev and test environments. It could be for capacity, right? You have more development teams or more production environments than you want to sort of tie to a single cluster. Then you start expanding out into locations, right? Maybe you started in the data center, then you started doing deployments to one public cloud, then to other public clouds, and then that's only going to grow. We see more and more customers deploying multi-cloud strategies. And then the new thing right now that everybody wants to talk to us about is edge, and as you get into edge deployments, now those, the number of clusters could really explode into the hundreds or thousands. And so it all points back to you need a sane way to manage across all these clusters regardless of where they run and regardless of how many you have, and that's really what we've been working on with the Advanced Cluster Management for Kubernetes. >> What's the big draw? What's drawing the customers in with multi-cluster and multi-cloud? Obviously, the multi-cloud makes a lot of sense, you have multiple clouds. Sounds easier just saying it than doing it. But what is it about multi-cluster and multi-cloud that's drawing customers and people into this concept? >> Yes, I can start. I think what's drawing customers in is the need, the desire to have sort of a common abstraction for the applications that's consistent regardless of where they happen to run, right? So making sure that the developers don't have to worry about what infrastructure the applications are landing on, and they have that consistent experience that it's, abstracts their applications away from that infrastructure. So that gives the developers more flexibility, but it's also about flexibility and agility for those infrastructure owners, right, because they too want to make decisions on where stuff runs. Not because they're particularly tied to an infrastructure, but based on things like cost or security or other concerns. And so these are all drivers for multi-cluster and multi-cloud strategies and I think our hybrid cloud strategy at Red Hat really hits the mark to address those needs. >> Well, you guys had great performance. We've been following the past few years just the OpenShift and beyond, kind of the whole Red Hat, and Ansible specifically too, is doing real well in the marketplace so congratulations. David, I want to ask you about the management piece. This comes up over and over again. It's all good having the abstraction layer, you got all kinds of new sets of services, but multi-cluster management is not, (laughs) is not trivial. There's challenges for ops and automation teams. Could you share your perspective on how you guys are looking at the multi-cluster management? >> Sure, sure. The first thing we saw, and this kind of follows on the points that Joe and Tom are making, is that as customers start embracing the development with containers and leveraging Kubernetes, you start finding that they're putting up clusters across their data centers, across cloud, to support different parts of the life cycle of development, or supporting their own production environment or distributed workloads across clouds, across the data centers. And so the challenges that operations and management run into, and security in particular, is how do you start managing the clusters, their life cycle. It's easy to put 'em up, to provision 'em quickly, but how do you update and upgrade those? How do you make sure they're compliant with your various regulatory compliance like PCI, HIPAA, or the various federal standards? How do you make sure that compliance is adhered to across, and security across those clusters, as well as the applications themselves? How do you manage the applications through their life cycle? How do you have deployment policies? So the challenges for ops and automation and security are to have a consistent policy-driven way to take care of the clusters across these hybrid environments, and making sure they adhere to the compliance and security of the enterprise. >> Tom, multi-cluster deployments is a big part of this integration. We heard a little bit, obviously, compliance and governance is huge. IT's been living this world of policies and governance, but when we start moving fast into these new cutting edge services that are providing a lot of value, integration into existing IT infrastructure is important with clusters. How do you view that because this is where I think maybe collections are other things are, is this an indicator of what's happening? Can you give your thoughts on the customers out there who want to do multiple clusters for all the benefits, but then go, "Oh, I got to integrate it into existing IT infrastructure"? >> Yeah, absolutely. So that's what's happening right now. As Kubernetes and as OpenShift has become a strategic platform for our customers, the idea of, I'm going to say, kind of normalizing the operations of that platform as part of a greater IT ecosystem has become a challenge for them. And for the most part, they've already automated security, network, provisioning, app deployment, application updates, using the Ansible Automation Platform, and so it only makes sense that as Kubernetes and as OpenShift becomes a strategic platform for them, they want to use that same language, that same tool set, that same automation fabric, if you will, to integrate the applications that are running on OpenShift with the rest of the environment. So, for example, when I add a new node to a cluster or more capacity to a cluster or to clusters, I probably want to update my systems of record, right? My CMDBs or my ITSM systems. When I deploy a new app or make an update to an app on a cluster or across clusters, I'm probably going to want to update my load balancer to be able to direct traffic correctly to that, and that load balancer probably isn't running, my enterprise load balancer is kind of platform independent, so I'd need to be able to update that load balancer to properly direct traffic. Well, IT has already automated that function using Ansible. So by creating the collections that we have created for OpenShift and for Kubernetes, it makes it much easier for our customers to be able to just plug that in and adapt that to their existing automation infrastructure. So now it just becomes part of their overall IT environment. >> So just a follow-up real quick, if you don't mind. What are some of the challenges you're hearing from your customers around containerization and that growing space? I just talked to the IDC research analyst earlier at another virtual CUBE session where she says, roughly their estimate is 5 to 10% of enterprises are containerized, which is huge growth opportunities. The headroom in containers is massive, so what are some of the challenges? Is it easy to get started? This seems to be a nice opportunity for you guys. What's your take on that? >> Yeah, I think that the way of looking at it with all that growth space, it's also the speed at which Kubernetes adoption and containerized application adoption is happening. And so, IT organizations are having to respond faster than they ever have before as this environment grows, and it is a multi-cloud environment. They have Kubernetes, OpenShift running on-prem, in the cloud, multiple data centers, as both Joe and Dave have said, and it becomes critical that they automate that correctly and accurately to ensure security, consistency, performance, availability. All of the other things that drive the requirement for automation standardization, all of those things that drive the requirements for automation are applicable to Kubernetes environments and containerized environments as well except they're moving and expanding faster, so teams have to respond quicker to the need. >> Joe, what's your take on this? I mean, to me, I'm the glass half full. I think I've seen containers be great and that maybe I'm looking at the early adopters, but those numbers seem a little bit low to me. What does that mean to you? More people are now getting up to speed. Is it a tipping point? It just seems a little bit low, and David, if you want to comment too, I think this an important number there. Joe, what's your take? >> Yeah, I mean, I think the rate represents an opportunity, but I see the growth as having been tremendous even in just the first few years. But to get to that broader market we did continue making it easier for customers to bring their applications to this new environment, to ride on existing infrastructure, and ultimately for our customers that means an evolution, right? An evolution of how they are going to manage those applications, how they're going to build and deploy them. And so with the integration of OpenShift and our advanced container management platforms with Ansible we can bring that automation to the mix to sort of tie those together, right? So to tie in the existing compute infrastructure, to tie in storage and networking and configure those as needed. And then as Tom mentioned, all those other systems, whether it's an IT service management system, something like a ServiceNow or other ticketing systems or other enterprise systems that exist that you just can't ignore. Because the more you try to go against the grain and do something different, the even harder it'll be. So we need to help customers evolve to take advantage of cloud and cloud native approaches, and the solutions that we're bringing to market are all about enterprise Kubernetes, enterprise container platforms. The combination of those technologies with something like Ansible really helps pave the path for the next phase of growth that we're expecting. >> So, ready for prime time right now. >> Right. >> David, your thoughts real quick on this. Containerization upside. >> Yeah, real quick, the development organizations, development teams, have picked up on containers very rapidly. Everybody is leveraging containers when they develop new applications or modernize the existing applications. So what we found is that a lot of the folks that pushed out very quickly, some greenfield apps, that's the 5, 10, 15, 20% that you're seeing occur. What started getting complex is how you really scale this to your enterprise. How do you really run this at scale from management operations and security perspective? OpenShift is critical, that gives a consistent platform across the hybrid cloud environments. What we're doing with ACM and the Advanced Cluster Management brings in the security and compliance. And what you'll see through AnsibleFest, what we're doing with Ansible is then, how do we then hook these environments right into all the existing IT environments? That's, to me, what's critical to really bring this to scale to the enterprise. >> Yeah, I think this, to me, the number points to exactly what you guys said. Ready for prime time, scale's there, and the demand's there. And I think, Tom and Joe, I want to ask you specifically the relationship between OpenShift and Ansible, but before that, I remember, forget what year it was, we were doing a CUBE event at, I think it might've been OpenStack, going back to the day, but I remember OpenShift and it was a moment where OpenShift adopted containers and then next year Kubernetes. And I remember talking to the team, them saying, "This is going to be a big bet for OpenShift." Looks like it was a good bet. (laughs) It paid out real well, congratulations. And it was good, you guys stayed the course. But you made it easier, and one of the things was is that the complaint at the time was they didn't want Kubernetes to be the next Hadoop. Easy to use but gets out of control. Not that I meant they're comparable, but Hadoop had that problem of it was easy open source but then it was hard to manage. So OpenShift really took advantage of that. You guys, I think, did a good job on that. But now you got Ansible winning the game on developers, on easy to deploy, so as that scales up, automation's there. So I'd like to hear you guys talk about the connection between OpenShift and Ansible and how that expands the scope of what both products can do for customers. >> Yeah, maybe I'll give it a shot first and then let Joe go after me, which is, look, here's what we have, is we have lots and lots and lots of customers, Red Hat customers that are OpenShift users and that are Ansible users, right? So we have this two large pools. They also represent two very large and vibrant open source community projects. The Ansible project and the Kubernetes project are two hugely popular, vibrant communities, and so it just made sense to kind of be a catalyst in those communities, to bring those two things together, to work together, to the benefit of our customers and to kind of capture the innovation that's going on upstream in the communities. So we decided to get really kind of serious about the integration of these two platforms and integrated Ansible in a native way on Kubernetes so that OpenShift and Kubernetes operators, as well as application developers, could take advantage of that integration without having to learn something new or foreign in order to be able to do it. So it was a native integration using operators, which is the right way to integrate with the Kubernetes platform, with OpenShift in particular. And so that's the way we kind of brought it together to the benefit of our customers. Our customers are, like I said, normalizing the operations of OpenShift as a strategic part of their infrastructure, deploying production applications, and want to be able to tie that into their other systems and other parts of their infrastructure, both from an app deployment process as well as from an infrastructure deployment and management process. So it only made sense that it actually, our customers have been asking us for this and talking to us about this, so it only kind of made perfect sense to kind of get out there and do that, get the communities together innovating, and then take that innovation out for our customer. >> Joe. >> Yeah, the only thing I'd add to that, there's really two specific personas at play here, right? When you think of, there's the IT operations and infrastructure teams. They own those clusters, the provisioning, the configuration, the management of those clusters. And with ACM, with Advanced Cluster Management for Kubernetes, we have now an interface that they can use to see and manage the life cycle of all their clusters. So through that we can integrate Ansible as another automation tool in their portfolio to do things that need to happen when those clusters first get configured or when those clusters get updated and so forth. So if they need to update an ITSM system or configure a network or do whatever it needs to, you have Ansible automation scripts that can be plugged in at the appropriate time in that cluster's life cycle to do that. On the other side, you have the developer and DevOps teams that are consumers of these platforms, right? And what they care about is the applications that they're building, but there's a lot that goes into building it, right? There's the source code management systems, there's the CI systems, the CD systems, there's the test environments and stage and prod. And so there's a lot of moving parts, and again, and then there's the services themselves that they're configuring so you have, or building, not configuring, you have Ansible again ready to sort of take on some of those tasks, automation tasks that go beyond what Kubernetes is focused on or what you're trying to do with OpenShift. And again, doing it at the appropriate time in the life cycle, all tied in through Advanced Cluster Management which can actually see out to all those clusters and be in that sort of application deployment workflow across those clusters. So those are sort of some of the specific areas and how they pertain to those specific personas that are driving the activity. >> What's interesting, this automation piece really is key across multiple environments, and we've heard that from some of your customers. 'Cause you got now private clouds out there, you got large scale. But, Dave, I want to ask you, what makes Advanced Cluster Management a natural fit with OpenShift and Ansible? What's your take? >> Yeah, good question, John. First, ACM is purpose-built for the Kubernetes environment. It's a cloud native management system, and as we said earlier, we really focused on managing the cluster life cycles, managing the security compliance, and managing applications deployed into these environments. So it was a very natural extension of OpenShift, to be able to manage OpenShift, multiple clusters of OpenShift in hybrid environments. Within your data center, across data centers, across clouds, and the combination. So, very natural fit with OpenShift. As we've been all talking about, as we looked at how did we then bring OpenShift and these resources closer through automation to many of the other parts of your IT environment, that made it natural from ACM to call out into the playbooks of Ansible. So just a simple example, and I think we circled around this a few times. You're deploying a cluster or you're deploying, say, an application to that cluster. You need to configure that into a firewall. Maybe configure it into a load balancer. Maybe register it with a service management system. That, all those calls, they come out through policy from ACM over into Ansible to take advantage of the wealth of playbooks that are available in Ansible to perform those operations. Whether it's security, network, service management, storage, et cetera. >> Real quick follow-up for you is, how has bringing your ACM team and product into Red Hat changed the scope and approach of what you're trying to do? >> Yeah, well, let me say first of all it's been a great experience bringing the team into Red Hat. The environment, the open culture, it's really been invigorating for the whole team. Also, getting much, much closer into the open communities and open sourcing ACM and doing development in the open has really brought us closer really to users, the ecosystem, the communities, accelerating our delivery quality, as well as really getting much more closer insights, getting insights into what's happening in the community, what's happening with the users. So it's really, it's been a great experience all the way around. >> Joe and Tom, quick comment, what do you think people should pay attention to this year at AnsibleFest 2020? What's the big story? Obviously we're in a pandemic. We're going to come out of the pandemic. People want to have a growth strategy that has the right projects on the right rails. They want to either maybe downplay some of the projects that maybe not be a fit, that were exposed during the pandemic. Best practices that are emerging, shifting left for security is one. You're seeing remote workers. People have kind of had a wake-up call on cloud native being relevant for the modern app. Now they're running as fast as they can to build the infrastructure, and guess what? People are not actually in the workplaces. The workforce, the workplace has all changed. Can you guys share your expertise over the years on what is the best practice and approach to take? Because the clock's ticking. >> Yeah, from my perspective and from an Ansible perspective here, we had always been about kind of automate everything, right? Automate every task that is automatable, right? A repeatable task, automate it. Repeatable task, automate it. And over the past couple of years we've really been focused on automation across teams by using Ansible content, the actual automation code, if you will, itself to bring teams together and to cross teams and cross functions. So not just focused on what a network operations person or a network engineer needs to do in their day-to-day job, but connect that to what a security operations person is doing day-to-day in their job in terms of threat detection and intrusion response, or intrusion detection and threat response, and connecting those two teams together via automation to make both of them more responsive and more effective. So we've been on this bandwagon for the past couple of years around Ansible content, and now Ansible collections and Automation Hub, to try and accelerate the way these teams can collaborate together. The pandemic and the pressures that put on the system with remote users and having to do things in a different way only exacerbated, it only kind of enhanced the requirement for that collaboration, that automation across teams. So in a lot of ways, the past six, seven months, both for our Ansible business as well as for the way our customers have been using the technology, has really been an accelerator for that kind of cross-team collaboration, our subscription business, and our Ansible consumption. >> Yeah, well, I said it last year in-person when we were in Atlanta for AnsibleFest 2019, a platform approach is a great way to go. You start out as a tool, you become a platform. You guys are doin' the work over there. I really appreciate it and I want to call that out 'cause I think it's worth calling out. Joe, cloud platforms. Cloud is certainly an enabler. Red Hat and OpenShift has been a great success and can, only has got more work to do. People still got to build out these platforms, and you're seeing private cloud not going away. I mean, we just had a conversation at OpenStack and you guys got customers with a lot of private cloud everywhere. (laughs) So you got private, you got hybrid, you got multi, and you got public. It's pretty crazy. What's your thoughts on what people should take away from AnsibleFest and then going forward post-pandemic? >> Yeah, so, first Tom hit on a number of key points there, right? COVID-19 and everything going on in the world has really just accelerated a lot of these transformations that were already in the works at many of our enterprise customer accounts, right? And now when we're all working remotely, we're all meeting virtually, we're educating our children remotely, it just exacerbates the need to scale our networks, to extend security out to remote workforces, and to do all of these things at much larger scales than we ever envisioned before, and you can't do that without automation. And I would argue, without taking advantage of some of these modern cloud native platforms and cloud native development approaches. And we always say Red Hat's been a big proponent of hybrid cloud, of our open hybrid cloud strategy. We've been talking about that for years, and what we always say is even if that's a strategy that you aren't specifically looking for, it's something that, everybody ends up there, right? Because nobody's running everything in the data center anymore, but as they move out to public cloud they're not completely shutting those data centers off either. As they expand their consumption of public cloud, they tend to start exploring multi-cloud strategies, and now that hybrid cloud is extending out to the edge. So the hybrid cloud is sort of where everybody is, right? And the ability to sort of manage consistently, to run consistently across all those environments, to be able to secure all those environments and scale those environments, and that's what we're all about here at Red Hat and that's sort of the key to our open hybrid cloud strategy and what we're really trying to do with our entire portfolio. >> Awesome, David, final word. We're in a systems world now. The cloud is one big distributed computer. We got the edge, we heard that. Developers just want to code, they want infrastructure as code, you guys got to help 'em get there. What's your take on the importance of AnsibleFest and this systems world we live in? >> Well, there's probably not a more critical time. We've all been saying this and seeing this the last 10 months now. The transformation digitally that's been going on for years, the development transformations, it's all hit a fever pitch. It's been accelerated through COVID. In particular, how quickly can I adjust to a digital transformation? How quickly can I adjust my business processes? How quickly can I really become a very agile DevOps SRE organization? That is so critical. So at AnsibleFest what we're doing is bringing together platforms with automation with the ability to manage it at scale with security. That's what's going on from Red Hat in a open environment, open world, with communities and huge ecosystems. That, to me, is the critical rallying points, and really necessary to drive this accelerated transformation. >> Yeah, and again, open source continues to power it. One thing I'm impressed with is this concept of content, not content as in a video, but content as code. It's collaboration. It's what people are sharing their playbooks and they're sharing their, are opening things up. I think there's going to be a whole 'nother level of developer collaboration that's going to emerge and you guys are on the front end of all of this. I think it's going to be pretty powerful. I don't think yet clearly understood yet by most folks, but when you start seeing the automation benefits, Tom, I'm sure your team will be like, "Yeah, see, automation platform." Thank you so much for coming on, appreciate it. >> Thank you. >> Thanks a lot. >> Thanks. >> I'm John Furrier with theCUBE, hosting theCUBE virtual for AnsibleFest 2020 virtual. Thanks for watching. (relaxing music)

>> Narrator: Live from the Moscone Center, it's theCube, covering AWS Summit San Francisco 2018 brought to you by Amazon Web Services. (upbeat music) >> We're back I'm Stu Miniman and we're here with theCube's exclusive coverage of AWS Summit San Francisco here in the Moscone Center West. Happy to welcome to the program two gentlemen from DynaTrace, we've got Andy Grabner, who's a DevOps specialist and Dave Anderson, vice president of marketing. Gentlemen, thanks so much for joining us. >> Thanks for having us. >> Alright so Dave we'll start, since you've got the marketing title, give us a little bit your role there and for our audience that might not be familiar with DynaTrace, I'm sure everybody knows 'em, but give us a little bit of the background. >> So essentially what DynaTrace does is, the world needs software to work perfectly. What we do is we help customers build and manage their software in their cloud environments on premise to help deliver a fantastic customer experiences because we know that it all needs to work. We've been in the market for the Magic Quadrant leader for the last eight years in the APM space, but we're expanding out beyond that now as the customer demands. >> Excellent, well one of my favorite lines you say you have to make software work, is they said hardware will eventually fail and software will eventually work. So Andy you've given a session here at the show tell us what your role is at DynaTrace, what are you doing here at the show? >> So I've been with the company for 10 years and I've been through a similar transformation that I believe most of the people here want to go through from quote unquote old-fashion, on premise, legacy, monolithic applications to using containers, microservices, and eventually serverless. So my session was all about fearless from monolith to serverless. I gave them some ideas on what we went through, how we as a company transformed, but also how our product transformed from, before we did on premise monitoring, built for the monolithic apps, and now we basically do full cloud-scale, in the cloud, but still covering all the enterprise technology because everybody that wants to build the cool, new stuff that they are selling here, you still have legacy applications that you integrate with and still carry around. So it's all about enterprise cloud technology that we cover. >> So Dave I hear all this I'm sure DynaTrace has more than 10 years of server-less and 12 factor authentication experience, right? >> Dave: Yes. >> Okay so you're the hipster you know, a cloud native company, you were doing all of it before any of us knew about exists. Tell us a little bit, historically, how did DynaTrace start before and move into this space? >> Yeah, so we've been in the space for around 10 years. We've been a leader in the space, but what we really did four or five years ago is we predicted on the future we were going to have serverless environments, we're going to have microservices, customers are going to have multiple cloud environments, they're going to need that software to work and they're going to need automation. So what we did is we took our 50 best engineers and we said go and re-invent the future and that's exactly what they've done. Our CTO has a vision, fully automated IT, so our whole product philosophy is around making it really simple for our customers to be able to see within this really complex digital environment, exactly what's going on, how is the software performing, how are the users adopting it and how do we role out better features and better functions to the customer base. >> All right, I love the re-invent pun, but this is the Summit, ReInvent's in November. Andy, we were talking to Sandy Carter, in the last segment, talking about customers and customers have so many applications that it's great to say this is the future and serverless and micro-architectures distributed is great and everything, but some of your stuff's going to be lift and shift, some of the stuff's probably got to stay where it is for a while, how do customers manage that portfolio and a few years ago it was like, we're going to do a bi-model world, we were not onboard with that, but there's a spectrum and there's lots of applications and it's really complicated, so what is the advice, how do you help customers kind of squint through that, and work through that? >> So I think essentially people want to update the critical apps, be more innovative, they want to go and invest in the new enterprise clouds tech, I would say, right? So we basically help them, first of all, figure out which of the applications that they have right now are easier to migrate, whether it's lift and shift or re-platform because we actually give them full visibility into the current tech, tell them where are the most dependent and least dependent services, which ones are easier to extract and harder to extract, depending on the dependencies and the traffic take us over into criticalities. So we help them first of all figure out their cloud migration plan, what to migrate first. We talked about T-shirt sizing your migration, small, medium, and large, and then not only do we help them to migrate things over but to break the big monoliths apart put stuff on top of it, right? So this is also happening, so we really help them to figure out which application, which service to tackle first, to migrate over. We do it in a safe way because we not only help them to later on monitor their new system, but we help them along the way. So we talked about DevOps earlier. I mean we had our little prep call. We actually think that monitoring, the space we are, is not just something to keep the lights on in production, but it's something that has to be checked along the delivery pipeline. That's why we are part of the development process, we are apart of your CICD, when a code change goes in, an architectural change goes in, when they move over, we monitor all these changes and we give you early warning signals that this change is going to be good one or not a good one. And that's how we solve them. >> Well so much things in the cloud, it's never a one time thing, it's got to be an ongoing process, it's iterative and if I hear right though, you're not just only an AWS, it's my on premises stuff, multi-cloud, you play with all of those environments. >> Yes. Yes exactly so I mean you name it. I'm not sure if I'm allowed to name all the other vendors in this space here at AWS. >> Look we're independent media, we cover all of those shows, and I think your customers are using all them, so you can say, they're all in an AWS, but they might also use GCP and Azure and other stuff. >> I think the stats were like 98 or 90% of customers are hybrid enterprise, multi-cloud, and that's why we designed the product to be able to do just that. They're going to have applications running in the cloud that are making calls back to things on premise. You want to be able to see that entire delivery chain. So absolutely we provide that single visibility across all of their cloud environments and on premise. >> What are you seeing as some of the biggest challenges your customers are facing, Dave? >> The shear, the complexity, the pressures which they face, which is they've got to shift to the cloud faster. They've got their CEO going, we need to provide better digital experience. They're going to build out these new cloud platforms. They're just struggling for time to deploy these things. They need to move faster. There's threats of competition, all the buzzwords that come, but they're all real for IT people. And then all we're doing is giving them that visibility because the environments have become so complex, microservice, serverless, multi-cloud, on-premise, and just to be able to help them challenge the visibility into where is everything, how is it performing, is it working and then give them the confidence to release faster as Andy talks about. >> So Andy, one of the things that people look at sometimes is okay it's a multi-cloud environment, but okay if I go down the container environment, can I do that multi-cloud? If I go down the path of say something like Fargate, that's only with Amazon, so are your customers concerned about that, how deep down do they go? I should say, how far up the stack are they willing to go with Amazon or are they holding back and trying to use services that are more easy to be able to be migrated if need be? >> I want to give you two answers to this. >> Yeah. >> First of all, the developers don't care. >> Okay. >> I don't care where it runs. >> No, I understand. I've got a software development team. When they port it over to any of us, they're like autoscaling's awesome, it's great, I don't want to have to port somewhere else, and if it works, I go back to, it was like, standards and proprietary versus that if you solve my business need, I'm needed. So I agree, but, what's your other answer? >> Yeah so but it is clear that people, what we hear at least, what I hear, people want to figure out, how can they define their next platform and make sure that at least they're not doing a complete vendor lock in, a cloud lock in, so they definitely think and invest in, how can we deliver something, a platform to our developers so that they can just worry about writing code and we make sure that, if we decide Amazon today, maybe something else later, it's not going to be too hard and so I think we see the people try, I think still a lot of people are in the early stages. So they start primarily with one vendor, with one platform, with one technology, but they always make sure that they keep their options open to eventually move over and they're constantly look, that's why they're constantly bringing in new technology, which is also a challenge for every vendor that is here on the floor to make sure we're coping with this technology disruption that is constantly happening, not only for the users, the consumers of the technology, but those of us as vendors and I think that's what we try to keep up with, yeah? >> Yeah, so how we doing as industry and how are customers doing at keeping up with all this change? >> It is, I think, constant dedication, constantly looking what's new. We, as Dave mentioned, we until only a couple of years ago figured out something new is coming, so we actually broke out our own team, our innovation team, that figure out what's the next big thing, I think we see this also with our customers. You constantly have to disrupt yourself, you constantly have to redefine yourself and that's what we did with monitoring. We redefined monitoring because we saw five years ago that a new wave of technology's coming and we don't stop now, we keep innovating and everybody else is doing it as well. You always have to keep up with what's coming and experiment and figure out what makes sense for you and what maybe does not make sense for you. You don't have to be part of every hype. >> And we do that in two ways, we sort of do that also in that a lot of the features that we put into the product actually come from our customer base. So we have a really strong connection with our customers, we listen to the customers, and we say, what do you need, what challenges are you suffering, what would you like to have, and then we build them into our product roadmap. So it's kind of a hybrid model of making sure you're able to listen to the customer and take their needs in, but also sometimes they don't know what's coming, so we'd work with an AWS, to understand what they're building out, and other technology partners to make sure that our product is future proof. >> So when you built that innovation team and everything, is it serverless underneath now for some of your products? >> It's a set of technologies, right? It's all of what you basically see here on the floor and others. I think the nice thing, what I heard actually today on the floor, they said you don't only talk about DevOps and CICD and innovation, you actually live it and what they mean with this, he said, if I look at how often DynaTrace produces new features, we deploy new feature releases twice a month, we deploy daily new updates, and then they said, if you look at other vendors in this space they also claim to be living what they expect from you, but they deploy twice a year still or maybe every other month. So I think we redefined monitoring, but also redefined and live what we actually expect our customers to do. >> Yeah, if you say you're a DevOps company, you better be embracing CICD and publish now and often. All right, Andy and Dave, thank you so much for giving us the updates. Congrats on the progress, we look forward to catching with you up more in the future. We'll be back with lots more coverage here from AWS Summit San Francisco, I'm Stu Miniman. You're watching theCube. (upbeat music)

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

>> From theCUBE studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is theCUBE conversation. >> Hi, I'm Stu Miniman, and welcome to a CUBE conversation. Always love when we can dig into practitioner discussions, and one of the editorial themes I've been really looking into in 2020 has been discussion of server lists. So really excited to welcome to the program, Dave Anderson, he is director of technology at Liberty Mutual, coming to me from Ireland. Dave, thanks so much for joining us. >> Thank you Stu, delighted to be here. >> All right, so I think most of our audience is probably familiar with Liberty Mutual. You work in the software group, Liberty IT, as part of Liberty Mutual. If you could just start us off, give us a little bit about your background, and your group's role inside the organization. >> Sure, Liberty IT started 20 years ago as really sort of an internal software host. Part of the Liberty Mutual group, we're part of Liberty Mutual Technologies. So we kind of work across all the markets in Liberty Mutual and all the kind of global locations. My role as director of technology is really think about what's the technical direction of Liberty IT? I can lead the architects with my group and really thinking about global architecture of Liberty Mutual and how can we provide business value in the mission going forward. >> Excellent, so Dave I guess what is the just kind of overall business and IT relationship? When I think of companies like yours, usually MNA comes in their growth expansions and digital transformation's been one of those buzzword discussions. But absolutely you need to be close to your customers there's lots of services that you need to provide online. How are some of those overall dynamic impacting how IT is supporting the business? >> That's a great question Stu. I mean technology has always been a key differentiator in Liberty Mutual. Even as my group was setup, like I said 20 years ago. It was always seen as a differentiator as something that we can be very good at. We've always been quite close to be in the cutting edge of technology. Many companies would say, "We're not an insurance company, we're a technology company that sells insurance." We are an insurance company, that's very important but we also need to understand that using the latest technology i.e. the cloud providers, really helps us deliver value to our business partners and customers. It is critical that we have a very tight partnership with our business partner. >> Excellent so yeah 20 years, a lot has changed in that time. Give us a little bit if you can, share a snapshot of where you are kind of in the cloud discussion. And what are the relationships between kind of the infrastructure side of the team and the development side of the team? And excepting that'll lead us forward to the server discussion. >> Sure I mean I joined Liberty about 12 years ago, 13 years ago and I actually started in one of the digital channels, that existence of digital channels. And probably almost 10 years ago our CEO James McGlannan quite a visionary, started kind of pressing the public cloud agenda and we started discussing public cloud as a potential future. It was a really exciting time. Cause I think the infrastructure development we all are in, gosh what's the possibilities of public cloud. And as you know the cloud itself it probably changes every year, it's redefined, there's new capabilities. I'm not sure we could envisage where we are today back when we started that conversation. Like every large enterprise, the initial conversation's around how do we enable this? How do we make this safe? How do we protect our data? All the usual kind of questions you would have. But in a way we kind of really joined together the very different departments. We thought, well how do we move the enterprise forward? And as well I mean we want to get a global capability for cloud was very important. And bringing up the velocity that we can deliver value quickly to our business partners. We didn't do it for technology's sake we did it to contribute real value for the business. And one of the really interesting things that we talked about is we shied away from counting how many virtual machines do we have in the cloud. That wasn't really a good metric for us. How are we delivering value to your business partners? That was kind of the metric that we chased and continue to chase. >> Well that's excellent how you kind of laid that out. I'm wondering if you could help extend that and bring us into where serverless fit into that discussion. I loved how you say it's not about number of VM's or the new shiny thing. So, what was it that led to your first use of serverless? And bring us a little bit along that journey that you've been going through. >> Sure, well one of the things that I've always found critical working in technology is that curiosity. But in a search for what's next. So, within micro IOS charts my people will say, "Where do we need to get to? What is 3 to 5 years out?" And we've a lot of really fantastic peers right across Liberty Mutual. Bright, open minded, they can think ahead. So one of my team was at I think it was re:Invent in I think it was 2013, where the launched Lambda for 2014. And each my crew were excited. They can build their first small application. It was actually a document generation. I think they were using some propriety systems. So they built a document generation solution. I couldn't believe the amount of ROM cost that was saved. It probably knocked something like 97% off the cost. Couldn't believe it. And we started saying, "Wow this is potential." But back then, again 5 or 6 years ago the stack was very immature. There was a lot of things you needed to figure out. Like the observability, the developer environment. There's a whole bunch of stuff that wasn't quite right. So it's something that we shared to our peers across the organization. We talked about it. We really started to kind of think, "Well this is interesting, this idea of serverless or manage servers." It started to really change how we thought and it really started to make the concept of a cloud native application very real. Cause we started to think of cloud native architecture loaded into application architecture. And that started to really flip how we thought. So it's just been a real journey these past couple of years. And a big thing for me is we started with engineers thinking of cloud as a mindset not necessarily as a platform. That opened the door to a lot of possibilities. >> Yeah, that's really interesting that you said that. Often times we say cloud is an operational model not a physical location. Are you using multiple clouds today? >> Yes, we probably tend to have a multi cloud strategy. And really to be very clear, serverless for us it's not just functions of service. Its not saying, "We're just using kind of something like Lambda." It's really about that idea using managed service. Thinking about evolution of architecture. How can we kind of try and cut out anything that is actually not differentiating? There's a great term which I always like is the stack policy is sometimes a technology companies we get obsessed by the stack. We think that the piece near the customer is quite easy. But think from the technology perspective we need to think about, we can deliver the most value by making the customer experience kind of best. And it can be even ramp the stack from whoever we need. >> Yeah, no, its a fascinating discussion. I've seen even today. You say serverless functions as a service. A lot of it is I don't want the developer to have to think about those underlying layer. Which reminds me of the discussion we've been having about platform as a service for more than a decade but PaaS was supposed to be platform independent. So I could have my code where ever it goes. Serverless today, right now we've talked about Lambda, Amazon there's certain things that I could only do on Amazon. There are discussions and working groups and the cloud data computing foundation. Working on how we can do serverless functions as a service that could expand between multiple clouds or use the same sort of code. So how do you look at that space? You talk about cloud native. How do you make sure that you're leveraging the technologies of the specific cloud but I guess I'll throw out not being locked into any one provider? >> I think about it for me it starts with the empowerment of the engineering team. We talk about a serverless first strategy that means that we've got the capability to build anything you need to. But to rent where you can. We had a fascinating story one of our best stories is a company called Workgrid. Workgrid Software is one of the companies that we spun out of Liberty Mutual. That was a project that we had an internal digital assistant that we built with some of our teams, it'd be back 4, 5 years ago. And our CEO James McGlannan decided to fund that as a kind of a startup. They broke off around 3 years ago and that initial team had 4 people in that engineering team. So they kind of decided that they would be serverless first in their approach. They didn't have time to think about operability or rights for portability. They had to realize business value really quickly. So they took a evolutionary architectural approach which meant they kept incrementing and iterating delivering value where possible. What's the next best thing that they can build to deliver value to the customer? So when you think in that regard, if you ever come to an Amazon of a grid, no one way doors, keep the two way doors. Don't lock yourself into anything. Make decisions that you can always build upon. So with that kind of constant iterative work our teams and that's serverless first strategy. It means that when you do rent the service if you need to change to another service it's just a matter of if you've your boundaries set up practically, it's very easy to get out of that. You dig yourself in deep to something, that's the difference. So I think there's an engineering mindset and culture that we certainly have proudness in our teams. But they kind of go fast, focus on business value and try and be sort cloud native in their outlook. >> Excellent, yeah, I just heard Andy Jassy in the AWS Summit online talking about those one way door. So sounds like from your standpoint, serverless is a two-way door for architecting in your mindset? >> Absolutely, I mean I think really for me it brings architecture back into the team. It's one of the really nice things is if your team use managed services that focus is on business value. If our infrastructure is set up to support that type of team then you have minimal hand offs within the team. Through the single team, its their job to create value, engineer the solution, make sure the security is good enough, build the operation, the visibility it's all contained within one team. We get a huge responsibility from that one team. As an engineer that is super powerful, super huge autonomy. So we can talk with the serverless engineer and for me it's been absolutely fascinating to see teams come into this environment and once they understand that event driven way of creating their systems. And I use the words systems rather than applications to create event driven systems they're constantly building upon. It's just fascinating to see where they go. You start to see the creativity and innovation of the engineers. So its truly unbelievable to watch. They're really very cool. >> Dave, I'm curious when you look at the application portfolio that your team manages, how do you decide what goes serverless? Is it new development all goes serverless? Has there been a migration? How do you look at the overall application portfolio that you have? >> It kind of depends I suppose on, I'm not going to sit here and say that we're going to refactor everything to serverless. I think when you do a migration there's usually six or seven paths you can go down and you do what's best for the business. But for new development, it's definitely interesting we haven't found many used cases that are really a bad fit. It's a spectrum we may decide what different servers to use. We built a system last year which was absolutely fascinating to see. It's like a a financial aggregation system where we do a lot of our accounting. So it was kind of serverless ETL, we're trying to do like an end of month batch system to detect a lot accounts from different countries and kind of pipe them into a kind of general ledger. Not something I would've thought about for serverless, to be honest. But then when you think about it and some of our engineering leads they have put this together. They can design this fantastic system using serverless workflows. Cause you're taking lots of various different types of data orchestrated in a single destination. And we put live in that this year and I think one of the monthly ends that they recently ran I think they ran something like 100 million transactions. Relatively low cost and of course being a month end system the rest of the months there's zero cost. You don't pay for idle. We only actually pay for wireless roaming in that month end process for maybe like FDRs or something. >> Dave, you talked about the early days 2014 when Lambda was announced, re:Invent, when you first started using it in the first year or so. There's the maturity of that ecosystem solutions set. Where do you see things now? What's working well? What's on your wishlist? Kind of mature or increase overall functionality to help? >> I think that the developer environment and developer experience is a big part. One of the key messages in trying to kind of get into our culture is code is a liability. It's not an asset. If you have a bunch of engineers writing lots of code that in fact is a liability. There's no business asset in that. The asset is in the system that you create. Trying to get engineers into the mindset to write less code and they actually engineer systems. So one of the things we've been trying to do is maybe using patterns as building blocks. People became kind of like a Lego building block way of creating their systems. Piecing somethings like CDK code development kit patterns. Using the world architect process to make sure that teams are looking after their cost, their security, their performance, their liability, and their kind of optimizations. Some of those things are really important in that whole ownership of an operational view of their systems. And also even things like observability. When you create a system with a lot of events laying around it starts getting complex. But then if you do it correctly you can start to layer on well, what better insights can we build on top of the system? So it's really opening up teams a different way of working. And then of course there's lots of operational challenges when you get into more complex environment. So as we often say, it's not easier, different, built difficulty building systems, but it's different, that's what's definitely easier but better. >> All right, how about anything that you're looking out towards the future? You talked about the early days when you look at these and while you're not necessarily throwing the latest shiny thing into production, there's that curiosity. So what's exciting you now? Anything else kind of looking forward that you prepare? >> I think one of the fantastic success stories we've had is with a project we call Virtual Assistant. And really to answer your question, its about how teams can properly work at MVP. So, one of the things that we really find fascinating is when you put a good engineering team. And I mean a team who you're really solid engineers you then layer on the cloud and security best practices and verification. We then put them in a coded serverless environment with real business problem. They then create a MVP. You're virtual assistant in, raises an MVP. So if you call into a call center and you have a fairly straightforward request, like if you have an auto claim you might say, "Well when can I pick up my ramp bill?" If you already done your claim. We have an NLP a natural language assistant that can help you with that conversation. So when you start with an MVP system like that you can start them off at a fairly small traffic, until you actually tune that until it's kind of perfect. And then you gradually scale up and add on other data driven potential AI services, integrations to that. So I think when you start to take the MVP approach, and have a very, very novel solution see what that's like in the wild and then start to scale out. We scale that system for taking maybe 30 calls maybe taking about a quarter on your calls. It's fantastic how you can start to scale these system up. Well I think what I'm really looking for is more kind of support to see how we can you know, it's the art of the possible. How can we use this skillset and this serverless mindset to create really fascinating business applications. Because when you get under that kind of creative conversation with business partners, I mean they don't want to hear about Lambda or events or observability. They want to say, "Well, what can I do with AI? What can I do with Voice, what can I do with Vision?" So we start to open up really fantastic conversations like that. So I'd like to see more of that, but in a creative product development. >> Excellent, well yeah Dave, so important that you brought back as to how IT in the business. Working together, it's not about the technical widget or knobs or anything. But the services and the value that ultimately you can provide for the business and the impact that has on your ultimate end customer. All right, Dave, thanks so much. Real pleasure having a chat with you. >> Thanks Stu really appreciate it, thank you. >> All right, be sure to check out theCUBE.net. Lots of backgrounds, if you go hit the search, you can actually type serverless, find out more about what we've been covering as well as what events we will be at in the future. I'm Stu Miniman and thank you for watching theCube. (gentle music)

(mumbling) >> Voiceover: Covering Sapphire now. Headline sponsored by SAP HANA Cloud, the leader in platform as a service. With support from Console Inc., the cloud internet company. Now, here are your hosts, John Furrier and Peter Burris. >> We are here live at SAP Sapphire. This is SiliconANGLE Media's The Cube. It's our flagship program. We go out to the events and extract the signal to noise and want to do a shoutout to our sponsors SAP HANA Cloud and Console Inc. at console cloud, connecting the clouds together. I'm John Furrier with my co-host Peter Burris. Our next guest is Reggie Jackson, winner, athlete, tech athlete now, entrepreneur, overall great guy, and a cube alumni. Four years ago, we interviewed him here at SAP Sapphire. Welcome back, Reggie, to The Cube. Thanks for coming on. John, thank you very much. It's good to be here with old friends. We were havin' a little conversation about baseball there, but good to see you guys. Yeah, and obviously, the baseball, we were just talkin' about the whole fisticuffs and the glee of the grand slam walk-off. >> Reggie: Good stuff, good stuff. >> It's a good pivot point in some of the things that you're workin' on in here, the conversations in the tech world, which is social media and that notion of celebrating in a world of Instagram and Snapchat and social media. Certainly, ya flip the bat, the views go up. But then, baseball has these (laughing) unwritten rules, right. So does corporations. And so we're now a new era. Is baseball safe now with these unwritten rules and should they maintain those, certain things that have kept the game in balance? But yet with social media, the players are their own brand. And you certainly were a brand, even back in your day, which is a pioneer. What's your thoughts on that? >> You know John, Peter, I don't like the idea of someone going out of their way to promote their brand. Some of the great brands to me in history, Babe Ruth, Ty Cobb, the great Jim Brown, Joe Montana, Michael Jordan. And Michael Jordan would be a prominent example where technology and TV enhanced who he was. And he had someone behind him to enhance his brand, Nike, Phil Knight, who was a real pioneer. I'm not so in favor, I'm not in favor at all of someone manufacturing themselves as a brand. And I hear players talk about their brand and about trying to create something. If you're great, if you deserve it, I don't think Stephen Curry works on his brand. I think he works on bein' a great player. I think he works on bein' a great teammate. I think he does his best to maximize his skill set. And he's nothing but a gentleman along the way. He'll celebrate with joy once in awhile, with the Curry moves, which we've come to recognize. But for guys that talk about the manufacturing of their brand, there's something about it that's manufactured. It's not real, it's false. And I don't like it. I think it's okay, the Snapchats and the Google+ and all of the stuff, Twitter and Facebook and all that stuff, all of the things that go along with trying to create some hubbub, etc. I'm okay with that. >> So you're saying if it's not deserved. People are overplaying their hand before earning it. >> A lot of it, John, a lot of it. Joe Montana didn't work on his brand, he was great. Jim Brown didn't work on his brand, he was great. I don't want to use Jimmy Brown. I want to use Montana because even young people today will know Joe Montana. Tom Brady, Peyton Manning, they're not about their brand. They're about being classy, being great, being part of a team, being a leader, presenting themselves as something that's respected in the NFL, across the United States. Go ahead, Pete. >> So even though it's cheaper to get your name out there, you still believe in let your performance speak for itself. >> You got to be real about it. Ya got to be who you are. If you're not a great player, get out of the way. Get out of the space. So manufacturing your brand. I played with the Yankees. I was in the era of Cosell and Billy Martin and George Steinbrenner. We won championships with the team. I was part of something that helped me become recognized. And so in our era, the Sandy Koufax's became brands because they were associated with greatness around them. They stood out and so they earned that tremendous brand. >> We were just watching Graig Nettles gettin' taken out by George Brett in that big game and also the pine tar, we kind of gettin' some good laughs at it. You look at the balance of personalities. Certainly, Brett and Nettles and your team and you had a great personality, winning championships. Worked together as a team. And so I want to ask you that question about the balance, about the in baseball, certainly, the unwritten rules are a legacy and that has worked. And now in a era of personalities, in some cases, people self-promoting themselves, people are questioning that. Your thoughts on that because that applies to business too 'cause tech athletes or business athletes have a team, there are some unwritten rules. Thoughts on this baseball debate about unwritten rules. >> Pete and John, I'll try to correlate it between some tech giants that have a brand. I just left a guy with a brand, Bill McDermott, that runs SAP. Even Hasso, the boss. The face now of SAP is Bill McDermott. Dapper, slender, stylish, bright. It comes across well. So maintaining that brand, to me, relates to SAP, bills a great image for it. He's stylish, he's smooth, he's smart. He's about people. He presents himself with care. So that is a brand. I don't think it's manufactured. That's who he is in real life. If you take a look, and I'll go back to Steph Curry because that name resonates and everyone recognize it. That style of cool, that style of control, that style of team and care. And he presents to us all that he cares about us, the fan, his team, his family. And so those are things and I think you can go from the tech world. Bill Gates had a brand. Brilliant, somewhat reclusive, concerned about the world, concerned about the country, concerned about his company. And so that resonated it Microsoft because that's who he really was. Some of the people today don't really recognize that Jobs was thrown out of Apple. He was pushed out. All of his brilliance, which was marketing. And the gentleman there that really was the mind for the company, Steve Wozniak, happens to be here at SAP Sapphire. Today, I think he speaks. But those brands were real, not manufactured. And so, in today's world, I think you can manufacture a brand. And then all of a sudden, it'll crumble. It'll go away in the future. But the great brands of whether it's Jackie Robinson or whether it's Jack Welch or whether it's George Steinbrenner and the Yankee brand, those brands were real. They were not manufactured. Those guys were eccentric. They were brilliant. Go ahead. >> And also, they work hard. And I want to point out a comment you made yesterday here at the event. You were asked a question up on stage about that moment when you hit the home runs. I think we talked about it last time. I don't necessarily want to talk about the home runs. But you made a comment I'd like you to expand on and share with the audience. 'Cause you said, "I worked hard," but that day during warm-ups, you had batting practice. You made a comment that you were in the zone. So working hard and being great as it leads up to that. But also, in the moment, 'cause that's a theme these days, in the moment, being ready and prepared. Share your thoughts on what you meant by you had a great batting practice and you just felt it. >> I'm going to take it to what you say is in the moment. I remember when I was talkin' about it yesterday, which you reference to, when I had such a fantastic batting practice. I walked by a coupla sports writers in that era. Really well-known guys, Dave Anderson, New York Times. I can't think of his name right now, but it'll come to me, of the Daily News. It was like hey man. >> John: You were rockin' it out there. >> I kind of hope I didn't leave it out here. (laughing) That was in the moment and at the same time, >> I mean, you were crushing it. >> Yes, when the game started, I got back in that moment. I got back in what was live, what was now, what was going on. Certainly, I think our world now with the instant gratification of sending out a message or tweeting to someone or whatever certainly in the moment is about what our youth is and who we are today as a country, as a universe. >> But you didn't make that up. You worked hard, but you pulled it together in the moment. >> A comment with that is I went and did something with ESPN earlier this year in San Francisco, in Oakland with Stephen Curry. They said, "Reggie, we want ya to come up "and watch his practice, his pre-game." And it was very similar to your batting practice, where people come out and watch, etc. And so I was looking forward to it and I like to go to the games about an hour and a half or two hours early so I can see warm-up and see some of the guys and say hello. And I got a chance to watch Steph Curry. I know his dad. And happened to be the first time I went this year, the dad, Carolina, the Panthers were in town. Not the Panthers. Come on, help me, help me, help me. >> Peter: The Wizards? >> No, no, no, the Carolina. >> Peter: Carolina Panthers. >> The Carolina Hornets. >> John: Hornets. >> Were there and I know his dad, Dell Curry. And we talked a little bit. But then, Steph came out and I watched him. And I watched the dribbling exhibition. I watched the going between the legs and behind the back and the fancy passing, etc. And I watched the shots, the high-arcing threes, the normal trajectory threes, the high shots off the backboard and things like that that he did. The left-handed shots, the right-handed shots. And the guy asked me what I thought of the show. And I said, "Well, it's a cool show, "but I'm going to see all that tonight." And me watching him, the behind the backs, the between the legs, the passes, the high-arching shots from three, the high-arching touches off the glass. He does all that. >> John: He brought it into the game. >> Yeah, I said so, (laughing) >> Peter: That is his game. >> It's not a show, but that's his game. >> So Reggie, you did an interesting promotion, Reggie's Garage, where you bought a virtual reality camera and you created a really nice show of your garage demonstrating your love >> Reggie: 360. >> Peter: of cars, 360. Talk a little bit about that. And then if ya get a second, imagine what baseball's going to be like as that technology becomes available and how some of the conversation that we're having about authenticity, the fan coming into the game. >> An experience. >> Is going to change baseball. Start with the garage and how that went and then how ya think that's going to translate into baseball, if you've had any thoughts on that. >> In the technology that was used, certainly I enjoyed it. While I was doing it, I noticed where the cameras were in different spots. There was one on the floor of my car. There was one in the backseat. And then there was someone following us as closely as they could. But you could see everything. You'd see the shift and you could see my feet. It was like you were with me. When we did the 360 inside the garage as well, you could listen to me and then you could use your finger and spin around. And they had these special headset and special glasses that you could look around, just with your headset on, and see all around the room. Behind you, in front of you. And so it's an experience that I think is going to become part of who we are as a nation, who we are as a people watching television, that you're going to really feel like you're in the room. I think it's going to be exciting. And I think it's going to be fun. And when you're talking about products, when you're talking about my website, if you will, with the focus on automotive parts, where a guy can go in and shop and get any part he wants for a vehicle, you really can build a complete car from my website. You can buy a frame. You can buy body parts. You can buy a horn, an engine, brakes, tires, grills, turn signals, the whole nine yards. And it gives you an experience through 360 video of really walking into the store, walking into the building, walking into the stadium and looking around to see the hot dog stand, see the dugout, see the pitcher and the hitter, to see the parts in the garage, to see the cars and take a look and view at everything that's there. >> How are players going to react to havin' the fans virtually right there with them? >> I don't think it bothers you. I don't think ya notice. I don't think they'll show anything that will affect the player that he's going to be concerned about. I think you'd have to be sensitive if they start microphoning, start micing up and then the looseness of the language would impact. So I don't think they'll go that far. But I do think the more that you can see, the more attractive the game becomes, the more interested that you can get people. When I broadcast baseball for ABC back in the 80's, I always tried to broadcast for the lady of the house, while she worked, while she cooked the meal, she didn't have time to think about a backup slider or the fastball that painted the outside corner, the changeup, etc., the sinker. I tried to broadcast for her interpretation so I could attract another fan to the game. So I think that the technology and the viewing that you'll see from behind home plate, from under the player's feet while he's running down the bases and the slides and things of that nature, Pete, I think are going to be exciting for the fan and it'll attract more fans, attract a new type of television it's going to produce, etc. So it's exciting. >> Reggie, thanks for comin' on The Cube again. Appreciate your time. I ask ya final two questions that I want to get your thoughts on. One is obviously the cars. Reggie's Garage is goin' great. And you shared with us last time on The Cube, it's on YouTube, about you when you grew up and decide football and baseball. But when you were growin' up, what was your favorite car? What was that car that you wanted that was out of reach? That car that was your hot rod? And then the second question is, we'll get to the second question. Answer that one first. What was you dream car at the time? How did ya get >> Reggie: The dream car >> John: hooked on this? >> at the time. I had a '55 Chevrolet that I bought from a buddy by the name of Ronny Fog. I don't even know if he's still around anymore. Out of Pennsylvania. I had $300 and my dad gave me $200. I'd saved up mine from workin' for my dad. But my dream car was I went to school with a guy named Wayne Gethman and another guy named Irwin Croyes. I don't know Wayne Gethman anymore. But from the age of 16, I reengaged with Irwin Croyes, who happens to be a business investing type guy in the city of Philadelphia, right where we're still from. He's a car collector. And he drove a '62 Corvette and so did Wayne Gethman. And I always wanted one. And I now happen to have four. (laughing) >> He who get the most toys wins. Final question, 'cause you're such a legend and you're awesome and you're doin' so much work. And you're very active, engaged, appreciate that. Advice to young athletes coming up, whether they're also in business or a tech athlete or a business athlete. But the sports athletes today got travel ball, you got all this stuff goin' on. The idols like Stephen Curry are lookin' great. Great role models now emerging. What advice do you give them? >> John's got a freshman in high school. I got a junior in high school. What would ya say to 'em? >> You know, I'll tell ya. When you're young, the people you want to listen to are Mom and Dad. No one, and I'll say this to any child from the age of eight or nine years old, five, six years old to 17, 18, 19, 20, all the way up, now my daughter's 25. All the way up to the end of your parents' days. No one cares for you more than your mother or your father. Any parent, whether it's a job or whether their success in life, number one in that man or woman, mom or dad, number one in their life is their children. And so for kids, I say if there's any person you're going to listen to for advice in any path you want to walk down, it's the one that your parents talk to you about or how they show you. That is what I would leave as being most important. For kids, anything, idea that you have that you believe you can do, whether it's the athlete like Stephen Curry that has created shots and done things on the basketball court that he envisioned, that he thought about. Or whether it's the next Steve Jobs who happens to be Mark Zuckerman, who I don't know Mark is 30 years old yet. >> John: He just turned 30. >> It's an idea. He's born around the same time. He's born this week. His birthday is in this week. My birthday's tomorrow. >> John: Happy birthday. >> But thank you. Anything that you can think of in today's world of technology. With places like Silicon Valley where they take dreams and create foundations for them. I had a dream about a website that would sell automotive parts and you could go to my site and buy anything for your car. We've got about 75,000 items now. We'll get to 180,000 in a few months. We'll get to a half a million as soon as my technology is ready for it. But we have things to pay attention to and look into and issues to make sure that we iron out that aren't there for our consumer, for ease of navigation, ease of consumption and purchasing. Any idea that you have, take time to dream. It's much more so than taking time to dream when I was a young kid. Because my father would say, "Stop daydreamin' "and wastin' time." >> John: Get to work. >> Reggie: In today's world, for our children, I say take time to create a vision or to create something new. And go to someone that's in the tech world and they'll figure out a way of helping you manifest it into something that's a reality. >> Listen to your parents, kids. And folks out there, dream, build the foundation, go for it. Reggie Jackson, congratulations for being a Cube alumni again, multi-return. >> Peter: Thank you very much. >> John: Appreciate it. Congratulate on all your continued success. You're a legend. Great to have you on. And thanks so much for comin' on The Cube. >> Peter: And happy 70th birthday. >> John, Pete, always a pleasure. >> John: Happy birthday. >> Thank you very much. >> Have some cake for Reggie. It's The Cube, live here in Orlando. Bringin' all the action here on The Cube. I'm John Furrier with Peter Burris with Reggie Jackson. We'll be right back. (electronic music)