>>welcome to the session. Long live swarm with containers and kubernetes everywhere we have this increasing cloud complexity at the same time that we're facing economic uncertainty and, of course, to navigate this. For most companies, it's a matter of focusing on speed and on shipping and iterating their code faster. Now. For many, Marantz is customers. That means using docker swarm rather than kubernetes to handle container orchestration. We really believe that the best way to increase your speed to production is choice, simplicity and security. So we wanted to bring you a couple of experts to talk about the state of swarm and Docker enterprise and how you can make best use of both of you. So let's get to it. Well, good afternoon or good morning, depending on where you are on and welcome to today's session. Long live swarm. I am Nick Chase. I'm head of content here at Mantis and I would like to introduce you to our two Panelists today eight of Manzini. Why don't you introduce yourself? >>I am a van CNI. I'm a solutions architect here at Moran Tous on work primarily with Docker Enterprise System. I have a long history of working with support team. Um, at what used to be Ah Docker Enterprise, part of Docker Inc. >>Yeah, Okay. Great. And Don Power. >>I, um Yeah, I'm Don Power on the docker. Captain Docker, community leader. Right now I run our Dev Ops team for Citizens Bank out of Nashville, Tennessee, and happy to be here. >>All right, Excellent. So All right, so thank you both for coming. Now, before we say anything else, I want to go ahead and kind of name the elephant in the room. There's been a lot of talk about the >>future. Yeah, that's right. Um, swarm as it stands right now, um, we have, ah, very vested interest in keeping our customers on who want to continue using swarm, functional and keeping swarm a viable alternative or complement to kubernetes. However you see the orchestration war playing out as it were. >>Okay? It's hardly a war at this point, but they do work together, and so that's >>absolutely Yeah, I I definitely consider them more of like, complimentary services, um, using the right tool for the job. Sort of sense. They both have different design goals when they were originally created and set out so I definitely don't see it as a completely one or the other kind of decision and that they could both be used in the same environment and similar clusters to run whatever workload that you have. >>Excellent. And we'll get into the details of all that as we go along. So that's terrific. So I have not really been involved in in the sort of swarm area. So set the stage for us where we kind of start out with all of this. Don I know that you were involved and so guys said, set the stage for us. >>Sure, Um I mean so I've been a heavy user of swarm in my past few roles. Professionally, we've been running containers in production with Swarm for coming up on about four years. Now, Um, in our case, we you know, we looked at what was available at the time, and of course you had. Kubernetes is your biggest contender out there, but like I just mentioned, the one of the things that really led us to swarm is it's design goals were very different than kubernetes. So Kubernetes tries to have an answer for absolutely every scenario where swarm tries to have an answer for, like, the 80% of problems or challenges will say that you might come across 80% of the workloads. Um, I had a better way of saying that, but I think I got my point across >>E Yeah, I think I think you hit the nail on the head. Um, Kubernetes in particular with the way that kubernetes itself is an a P I I believe that kubernetes was, um, you know, written as a toolkit. It wasn't really intended to be used by end users directly. It was really a way to build platforms that run containers. And because it's this really, really extensible ap I you can extend it to manage all sorts of resource is swarm doesn't have that X sensibility aspect, but what it was designed to do, it does very, very well and very easily in a very, very simple sort of way. Um, it's highly opinionated about the way that you should use the product, but it works very effectively. It's very easy to use. It's very low. Um, not low effort, but low. Ah, low barrier to entry. >>Yes. Yes. Absolutely. I was gonna touch on the same thing. It's very easy for someone to come in. Pick up swarm. You know they don't They don't have to know anything about the orchestrator on day one. Most people that are getting into this space are very familiar with Docker. Compose um, and entering from Docker compose into swarm is changing one command that you would run on the command line. >>Yeah, very, very trivial to if you are already used to building docker files using composed, organize your deployment into stacks of related components. It's trivial to turn on swarm mode and then deploy your container set to a cluster. >>Well, excellent. So answer this question for me. Is the swarm of today the same as the swarm of, you know, the original swarm. So, like when swim first started is that the same is what we have now >>it's kind of ah, complicated story with the storm project because it's changed names and forms a few times. Originally in is really somewhere around 2014 in the first version, and it was a component that you really had to configure and set up separately from Docker Ah, the way that it was structured. Ah, you would just have docker installed on a number of servers are machines in your cluster. And then you would organize them into a swarm by bringing your own database and some of the tooling to get those nodes talking to each other and to organize your containers across all of your docker engines. Ah, few years later, the swarm project was retooled and baked into the docker engine. And, um, this is where we sort of get the name change from. So originally it was a feature that we called swarm. Ah. Then the Swarm Kit project was released on Get Hub and baked directly into the engine, where they renamed it as swarm mode. Because now it is a motile option that you just turn on as a button in the docker engine and because it's already there the, um, the tuning knobs that you haven't swarm kit with regard to how what my time outs are and some of these other sort of performance settings there locked there, they're there. It's part of the opinionated set of components that builds up the docker engine is that we bring in the Swarm Kit project with a certain set of defaults and settings. And that is how it operates in today's version of Docker engine. >>Uh, okay for that, that makes sense. That makes sense. So ah, so don, I know you have pretty strong feelings about this topic, but it is swarm still viable in a world that's sort of increasingly dominated by Kubernetes. >>Absolutely. And you were right. I'm very passionate about this topic where I work. We're we're doing almost all of our production work lives on swarm we only have out of Ah, we've got something like 600 different services between three and 4000 containers. At any given point in time. Out of all of those projects, all of those services we've only run into two or three that don't kind of fit into the opinionated model of swarm. So we are running those on KUBERNETES in the same cluster using Moranis is Docker enterprise offering. But, um, no, that's a very, very small percentage of services that we didn't have an answer for in swarm with one. The one case that really gets us just about every time is scaling state full services. But you're gonna have very few staple services in most environments for things like micro service architecture, which is predominantly what we build out. Swarm is perfect. It's simple. It's easy to use you, don't you? Don't end up going for miles of yamma files trying to figure out the one setting that you didn't get exactly right? Um yeah, the other Thea the other big piece of it that way really led us to adopting it so heavily in the beginning is, you know, the overlay network. So your networks don't have to span the whole cluster like they do with kubernetes. So we could we could set up a network isolation between service A and service B, just by use using the built in overlay networks. That was a huge component that, like I said, let us Teoh adopting it so heavily when we first got started. >>Excellent. You look like you're about to say something in a >>Yeah, I think that speaks to the design goals for each piece of software. On the way that I've heard this described before is with regard to the networking piece the ah, the docker networking under the hood, um, feels like it was written by a network engineer. The way that the docker engine overlay networks communicate uses ah, VX lan under the hood, which creates pseudo V lands for your containers. And if two containers aren't on the same Dylan, there's no way they can communicate with each other as opposed to the design of kubernetes networking, which is really left to the C and I implementation but still has the design philosophy of one big, flat sub net where every I p could reach every other i p and you control what is allowed to access, what by policy. So it's more of an application focused Ah design. Whereas in Docker swarm on the overlay networking side, it's really of a network engineering sort of focus. Right? >>Okay, got it. Well, so now how does all this fit in with Docker enterprise now? So I understand there's been some changes on how swarm is handled within Docker Enterprise. Coming with this new release, >>Docker s O swarm Inside Docker Enterprise is represented as both the swarm classic legacy system that we shift way back in 2014 on and then also the swarm mode that is curly used in the docker engine. Um, the Swarm Classic back end gives us legacy support for being able to run unmanaged plane containers onto a cluster. If you were to take Docker ce right now, you would find that you wouldn't be able to just do a very basic docker run against a whole cluster of machines. You can create services using the swarms services, a p I but, um, that that legacy plane container support is something that you have to set up external swarm in order to provide. So right now, the architecture of Docker Enterprise UCP is based on some of that legacy code from about five or six years ago. Okay. Ah, that gives us ability to deploy plane containers for use cases that require it as well as swarm services for those kinds of workloads that might be better served by the built in load balancing and h A and scaling features that swarm provides. >>Okay, so now I know that at one point kubernetes was deployed within Docker Enterprise as you create a swarm cluster and then deploy kubernetes on top of swarm. >>Correct? That is how the current architecture works. >>Okay. All right. And then, um what is what is where we're going with this like, Are we supposed to? Are we going to running Swarm on top of kubernetes? What's >>the the design goals for the future of swarm within branches? Stocker Enterprise are that we will start the employing Ah, like kubernetes cluster features as the base and a swarm kit on top of kubernetes. So it is like you mentioned just a reversal of the roles. I think we're finding that, um, the ability to extend kubernetes a p I to manage resource is is valuable at an infrastructure and platform level in a way that we can't do with swarm. We still want to be able to run swarm workloads. So we're going to keep the swarm kit code the swarm kit orchestration features to run swarm services as a part of the platform to keep the >>got it. Okay, so, uh, if I'm a developer and I want to run swarm, but my company's running kubernetes what? What are my one of my options there? Well, I think >>eight touched on it pretty well already where you know, it depends on your design goals, and you know, one of the other things that's come up a few times is Thea. The level of entry for for swarm is much, much simpler than kubernetes. So I mean, it's it's kind of hard to introduce anything new. So I mean, a company, a company that's got most of their stuff in kubernetes and production is gonna have a hard time maybe looking at a swarm. I mean, this is gonna be, you know, higher, higher up, not the boots on the ground. But, um, you know, the the upper management, that's at some point, you have to pay for all their support, all of it. What we did in our approach. Because there was one team already using kubernetes. We went ahead and stood up a small cluster ah, small swarm cluster and taught the developers how to use it and how to deploy code to it. And they loved it. They thought it was super simple. A time went on, the other teams took notice and saw how fast these guys were getting getting code deployed, getting services up, getting things usable, and they would look over at what the innovation team was doing and say, Hey, I I want to do that to, uh, you know, so there's there's a bunch of different approaches. That's the approach we took and it worked out very well. It looks like you wanted to say something too. >>Yeah, I think that if you if you're if you're having to make this kind of decision, there isn't There isn't a wrong choice. Ah, it's never a swarm of its role and your organization, right? Right. If you're if you're an individual and you're using docker on your workstation on your laptop but your organization wants to standardize on kubernetes there, there are still some two rules that Mike over Ah, pose. And he's manifest if you need to deploy. Coop resource is, um if you are running Docker Enterprise Swarm kit code will still be there. And you can run swarm services as regular swarm workloads on that component. So I I don't want to I don't want people to think that they're going to be like, locked into one or the other orchestration system. Ah, there the way we want to enable developer choice so that however the developer wants to do their work, they can get it done. Um Docker desktop. Ah, ships with that kubernetes distribution bundled in it. So if you're using a Mac or Windows and that's your development, uh, system, you can run docker debt, turn on your mode and run the kubernetes bits. So you have the choices. You have the tools to deploy to either system. >>And that's one of the things that we were super excited about when they introduced Q. Burnett ease into the Docker Enterprise offering. So we were able to run both, so we didn't have to have that. I don't want to call it a battle or argument, but we didn't have to make anybody choose one or the other. We, you know, we gave them both options just by having Docker enterprise so >>excellent. So speaking of having both options, let's just say for developers who need to make a decision while should I go swarm, or should I go kubernetes when it sort of some of the things that they should think about? >>So I think that certain certain elements of, um, certain elements of containers are going to be agnostic right now. So the the the designing a docker file and building a container image, you're going to need to know that skill for either system that you choose to operate on. Ah, the swarm value. Some of the storm advantage comes in that you don't have to know anything beyond that. So you don't have to learn a whole new A p I a whole new domain specific language using Gamel to define your deployment. Um, chances are that if you've been using docker for any length of time, you probably have a whole stack of composed files that are related to things that you've worked on. And, um, again, the barrier to entry to getting those running on swarm is very low. You just turn it on docker stack, deploy, and you're good to go. So I think that if you're trying to make that choice, if you I have a use case that doesn't require you to manage new resource is if you don't need the Extensible researchers part, Ah, swarm is a great great, great viable option. >>Absolutely. Yeah, the the recommendation I've always made to people that are just getting started is start with swarm and then move into kubernetes and going through the the two of them, you're gonna figure out what fits your design principles. What fits your goals. Which one? You know which ones gonna work best for you. And there's no harm in choosing one or the other using both each one of you know, very tailor fit for very various types of use cases. And like I said, kubernetes is great at some things, but for a lot of other stuff, I still want to use swarm and vice versa. So >>on my home lab, for all my personal like services that I run in my, uh, my home network, I used storm, um, for things that I might deploy onto, you know, a bit this environment, a lot of the ones that I'm using right now are mainly tailored for kubernetes eso. I think especially some of the tools that are out there in the open source community as well as in docker Enterprise helped to bridge that gap like there's a translator that can take your compose file, turn it into kubernetes. Yeah, Mel's, um, if if you're trying to decide, like on the business side, should we standardize on former kubernetes? I think like your what? What functionality are you looking at? Out of getting out of your system? If you need things like tight integration into a ah infrastructure vendor such as AWS Azure or VM ware that might have, like plug ins for kubernetes. You're now you're getting into that area where you're managing Resource is of the infrastructure with your orchestration. AP I with kube so things like persistent volumes can talk to your storage device and carve off chunks of storage and assign those two pods if you don't have that need or that use case. Um, you know, KUBERNETES is bringing in a lot of these features that you maybe you're just not taking advantage of. Um, similarly, if you want to take advantage of things like auto scaling to scale horizontally, let's say you have a message queue system and then a number of workers, and you want to start scaling up on your workers. When your CPU hits a certain a metric. That is something that Kubernetes has built right into it. And so, if you want that, I would probably suggest that you look at kubernetes if you don't need that, or if you want to write some of that tooling yourself. Swarm doesn't have an object built into it that will do automatic horizontal scaling based on some kind of metric. So I always consider this decision as a what features are the most I available to you and your business that you need to Yep. >>All right. Excellent. Well, and, ah, fortunately, of course, they're both available on Docker Enterprise. So aren't we lucky? All right, so I am going to wrap this up. I want to thank Don Bauer Docker captain, for coming here and spending some time with us and eight of Manzini. I would like to thank you. I know that the the, uh, circumstances are less than ideal here for your recording today, but we appreciate you joining us. Um and ah, both of you. Thank you very much. And I want to invite all of you. First of all, thank you for joining us. We know your time is valuable and I want to invite you all Teoh to take a look at Docker Enterprise. Ah, follow the link that's on your screen and we'll see you in the next session. Thank you all so much. Thank you. >>Thank you, Nick.

>> Voiceover: From New York, it's theCUBE covering Blockchain Week. Now, here's John Furrier. >> Hello everyone, welcome back, I'm John Furrier here in the ground in New York City, Manhattan, for Blockchain Week New York, also day three of Consensus 2018; it's a huge event, everyone's here in all the action. Philipp Pieper's the CEO and co-founder of... he's with Swarm Funds; now, it's an interesting story, we've interviewed a couple of other companies: Polymath, Securitize, these guys got a unique value proposition. Philip, Swarm Funds, tell about what you guys are doing? >> Sure. >> What's the value proposition, where you guys are at? >> So we are the first security token framework that is live in the market. We launched, actually, end of January, only three months after the ICO, and we focus actually on tokenizing LP positions and funds, and we do that with a unique legal structure, governing structure, and obviously token infrastructure, that actually is meant to become a lingua franca that anyone in the market can collaborate on, so we even invite the previously named companies to actually collaborate with this because it's not a one-person or one organization sellout. >> And you got a shipping product. >> We have a shipping product. We actually have business on it, which means that there's funds that have tokenized on our platform, four of them actually. We have another 50 right now in the pipeline, so the next couple of weeks we're going to see at least nine to maybe 15 that are going to come to the market. >> So, I understand your value proposition. Are you guys operationalizing venture capital or equity partners? Or is it targeting entrepreneurs themselves or both? Who's the customer for you? >> So, on the project side, on the investment opportunity side, it's actually people that have something that they've done in the past that have existing business and where we just become another part of their capital structure. So, when you >> Give me an example. >> When you focus on a fund, so for example, we have a fund called Andra Capital that is a pre-IPO tech fund, so you can buy into a composite of Airbnb, Uber, and other tech companies where they buy secondaries off the market. They're an existing fund, they have existing LP's, they have existing business, and for them to open up to the crypto landscape, both for crypto investors as well as family offices, we're that conduit. >> Yeah. >> So, for them it's no change of legal structures, they can just do this in the existing way, and for us in the crypto community it's an excellent way to democratize access to that, so you can get into these kind of things that normally were only for the privileged investors. >> And so the benefit to them is that they don't have to unwind or mess with a tangled web of deals and LP's, relationships, because it's complicated, the side deals, all kinds of, not side deals, but you know what I'm saying, like one, there's a lot of moving parts, right, so? >> Well, yeah, and even more so, they don't have to put all their chips into this one thing that, you know, we all believe that is going to be big, but who knows whether it's going to pan out? So, you know, if I would approach one of those partners and say, "Well, your entire fund has to be tokenized." That's a pretty big deal with a lot of resistance. In this way, they can just open up a backdoor saying, "Okay, let's test this out, see how it works" and, by the way, they can actually push their existing investors to that direction, too, because it has a liquidity to it. That's the key element that is missing >> Yeah and they don't have to do anything different, so it's really smart. So, I've got to ask you, so, your advice or security token's been a pretty positive reaction from most folks. Hey, finally a security token, there are people are raising money, that's what we're doing, I mean that's what we're doing, no one has product. I mean, we have a product, some people have products, you have products. The thing is that there's very few people that have products so they're basically raising money. So call it what it is, it's a raising money token. Security tokens are now good, but as the entrepreneurs out there, they say, "Well, do I just pledge with my cashflow, or do I put equity against it?" What's your vision on how entrepreneurs should think about what they give up for the tokens, how they securitize it? >> Are you meaning that the entrepreneurs actually come to the space with their entrepreneurial efforts or? >> So, I'm an entrepreneur and I say I want to raise 15 million dollars or 10 million dollars on an issuing a security token and what do I get for that? So the investor wants security. >> Well, the investor wants actually something that is reliable in the most legal way possible, which means that it is something that they can, you know, have confidence that there's something on the other end, that there is a trustful asset that is underlying, that there's a legal stress that they can put this to and if things go sideways, that they have a voice that they can actually govern their ownership with. >> What is that now, what's the standard? Is there a standard evolving around what that is behind the security token? Is it cashflow, is it equity? >> Well, so, in our case we pay attention to actually having a vetting process that actually makes sure that things exist where actually, so this one token being the utilities, sort of like, it's a token to consider us as an AWS for fund operations, so, we incentivize existing players to help vet. We are working with some of the biggest servicing firms and auditing firms to, in the end, actually put the rubber stamp on stuff saying this actually is in existence and it's being, you know, looked at in detail, and the community in the end then can actually say, "We want this, too" or "We don't want this." So, there's multiple hoops that someone has to jump through before they can actually claim to be on a network like Swarm on this SRC-20 token that we have. >> What's interesting, too, is that what I like about your business model is that there's leverage, too, and, as you do things, you don't have to do it again, and, so, everyone has to sort of replicate and provision their company some way, right? So, it's complicated. >> Well, and, by the way, just to extend that also to the fact that there's only, there's one investor graph that is a qualified investor graph that basically anyone can chip in to, and it makes it incredibly easy for a qualified investor to move around on amongst different security tokens, and not just do that, like on a dedicated platform, but we are taking this into existing exchanges. You can even think of a model where this works with a decentralized exchange, where people can confidently actually trade one another and they don't have to requalify with the decentralized exchange, which doesn't have an organization to qualify them. >> It sounds like cloud computing and devops in action. >> Yeah. >> Bringing in some crypto, so you probably bring great service, okay, what else is going on, how much did you raise, how big is the team, what's going on with the company? >> Yeah. >> What's next? What's on the road map? >> So, we actually started thinking this end of 2016, before this whole craziness started, so there's a lot of pen to paper that we had to put in place, so there's a preparation into the ICO that we did in September/October; we were very restrictive, the way that we did it, we had a token liquidator release in order to appeal to some of the more US-focused investors. We raised 5.5 million dollars back then, valued in ether, pretty good. We then actually, the foundation still hold half of the tokens, we just were really cleared to be not a security. In this realm, we clearly separated the security from the utility function and we are off to the races with actually not just being listed on exchanges but also to actually list the security tokens on exchanges with a clear mandate by the token issuers that that's something that they are qualified to do. >> That's awesome. So, Philipp, I'm going to give you a use case, if I'm going to do a token offering, say for theCUBE, hypothetical, wink wink, what do I do? How do I engage with you? Would I use your service? How would I use your service? I'm going to issue tokens, you know, we're building the business, we're building the brand, we're going to open it up. I don't have time to deal with all those details. It's a lot of hassles. Do I do the Cayman Islands, special purpose vehicles, I mean, where is my entity, what's my domicile, what's the law here? Do I use you? I mean, would I use you guys and that would be the service or are you targeting, would I have to go somewhere else? Who do I use? Who would I, how would I use Swarm? >> Well there's two parts to answer that question: one is actually, obviously, we have a lot of institutional organizations on the other end that have their own custom setup, they have existing things, we make it incredibly easy for them to engage with us because we form these SPV's which are, you know, so far we've trialed this in MBVI and Cayman's and Estonia and Lichtenstein, but those entities become shareholders of the underlying assets. So, if someone wants to list something, they go to tokenize.swarm.fund; there's an in-take form that actually allows them to supply their proposals, their proposals get put through different layers of vetting, so we work with... >> From your team? >> Well, first on our team, but we work with external people that vet that, too, and then actually it goes to an auditing firms that actually then say this is something real because before we take it to market, and actually offer it to the broader community, we really want to make sure that this is actually something that has validity to it because, as you know, market can be killed by the first ill leanings of actually something not being real. >> So do you pay for those service or is it paid in tokens? >> It's paid in tokens. Again, the analogy is the AWS, so it's basically, if someone wants to list, there's a gas for a fund listing that has to be paid, and that goes to both investor qualification as well as the auditing process. The same actually applies to the fund operations, so there's gas for fund operations, which goes to the technical nodes, the legal service providers we work with, accounting firms, people that want to do due diligence, like say I receive a nav report and that adds some value through it. >> It's coin-operated, literally. >> Exactly, but if I receive a net asset value report from one of the underlying assets, and I as an investor don't believe it, I can stake to say I want to have KPMG go off and actually validate that this is actually real and it's actually built on standards. >> You're bringing a lot of service providers together, you're also providing some base services, that's cool, what's next, what are you going to do this next year? What's next for you guys the second half of the year? >> I think we're just scratching the surface of what this is going to do. I mean, we're very happy that actually there's a very big focus by the market on actually security tokens, Wall Street is taking it extremely serious and legislators across the world are taking it seriously, so we're very, very fortunate to be in some of those conversations with legislators who want the security tokens base to be compliant with what they're thinking about. I think it's just going to be volume, on both ends, our target is to actually have a hundred thousand active investors engaged. We want to have at least a hundred funds that are live on the platform on the network, and we want to stitch partnerships with whoever wants to participate. That makes this a frictionless ecosystem such that everyone can continue doing their business. >> Well, we need more faster, better products out there. The SEC, you've seen some of the regulatory issues, slowing things down in the US and a lot of action going on outside the United States, so, the sooner the better, right? >> Yeah, but I think the SEC is taking the approach to say, "We're going to regulate the bad actors, but we're urging a self-regulatory position by the industry." And, so, efforts like all the ones that you mentioned and us actually going in the direction to be compliant, not shying away from having security tokens in a legal fashion is the good news because the more we show that the more actually they understand that this is not some kind of evasion strategy in many different directions. >> Yeah, and we need to move faster, cool. Well, great job Philipp, we've got a great job here, Swarm Fund, check it out, they're really making it easier for investors and limited partners, the Big Money, to actually move an encrypto, open up a door, put a toe in the water, and make money, get liquid, thanks for coming on. >> Thanks so much. >> We appreciate it, BlockChain Week New York City, I'm John Furrier, thanks for watching.

>>Hey guys. Welcome back to Detroit, Michigan. Lisa Martin and John Furrier here live with the cube at Coan Cloud Native Con North America. John, it's been a great day. This is day one of our coverage of three days of coverage. Kubernetes is growing up. Yeah, it's maturing. >>Yeah. We got three days of wall to wall coverage, all about Kubernetes. We about security, large scale, cloud native at scale. That's the big focus. This next segment's gonna be really awesome. You have a fast growing private company and a practitioner, big name, blue chip practitioner, building out next NextGen Cloud first, transforming, then building out the next level. This is classic of what we call super cloud-like, like interview. It's gonna be great. I'm looking forward >>To this anytime we can talk about Super Cloud. All right, please welcome back. One of our alumni, Bani is here, the CEO of Rafe. Great to see you Santos. Ula also joins us, the global head of Cloud SRE at Mass Mutual. Ge. Great to have you on the program. Thanks >>For having us. Thank you for having me. >>So Steve, you've been on the queue many times. You were on just recently with the momentum that that's around us today with the maturation of Kubernetes, the collaboration of the community, the recognition of the community. What are some of the things that you're excited about with on, on day one of the show? >>Wow, so many new companies. I mean, there are companies that I don't know who are here. And I, I, I live in this industry and I'm seeing companies that I don't know, which is a good thing. I mean, it means that the, the community's growing. But at the same time, I'm also seeing another thing, which is I have met more enterprise representatives at this show than other coupons. Like when we hung out at, you know, in Valencia for example, or even, you know, other places. It hasn't been this many people, which means, and this is, this is a good thing that enterprises are now taking Kubernetes seriously. It's not a toy. It's not just for developers. It's enterprises who are now investing in Kubernetes as a foundational component, right. For their applications going forward. And that to me is very, very good. >>Definitely becoming foundational. >>Yep. Well, you guys got a great traction. We had many interviews at the Cube and you got a practitioner here with you. You guys are both pioneering kind of what I call the next gen cloud. First you gotta get through gen one, which you guys done at Mass Mutual, extremely well, take us through the story of your transformation. Cause you're on the, at the front end now of that next inflection point. But take us through how you got here. You had a lot of transformation success at Mass Mutual. >>So I was actually talking about this topic few, few minutes back, right? And, and the whole cloud journey in big companies, large financial institutions, healthcare industry or, or our insurance sector. It takes generations of leadership to get, to get to that perfection level. And, and ideally the, the, the cloud for strategy starts in, and then, and then how do you, how do you standardize and optimize cloud, right? You know, that that's, that's the second gen altogether. And then operationalization of the cloud. And especially if, you know, if you're talking about Kubernetes, you know, in the traditional world, you know, almost every company is running middleware and their applications in middleware. And then containerization is a topic that come, that came in. And docker is, is you know, basically the runtime containerization. So that came in first and from Docker, you know, eventually when companies started adopting Docker, Docker Swarm is one of the technologies that they adopted. And eventually when, when, when we were taking it to a more complicated application implementations or modernization efforts, that's when Kubernetes played a key role. And, and Hasi was pointing out, you know, like you never saw so many companies working on Kubernetes. So that should tell you one story, right? How fast Kubernetes is growing and how important it is for your cloud strategy. So, >>And your success now, and what are you thinking about now? What's on your agenda now as you look forward? What's on your plate? What are you guys doing right now? >>So we are, we are past the stage of, you know, proof of concepts, proof of technologies, pilot implementations. We are actually playing it, you know, the real game now. So in the past I used the quote, you know, like, hello world to real world. So we are actually playing in the real world, not, not in the hello world anymore. Now, now this is where the real time challenges will, will pop up, right? So if you're talking about standardizing it and then optimizing the cloud and how do you put your governance structure in place? How do you make sure your regulations are met? You know, the, the, the demands that come out of regulations are met and, and how, how are you going to scale it and, and, and while scaling, however you wanna to keep up with all the governance and regulations that come with it. So we are in that stage today. >>Has Steve talked about, you talked about the great evolution of what's going on at Mass Mutual has talked a little bit about who, you mentioned one of the things that's surprising you about this Coan and Detroit is that you're seeing a lot more enterprise folks here who, who's deciding in the organization and your customer conversations, Who are the deci decision makers in terms of adoption of Kubernetes these days? Is that elevating? >>Hmm. Well this guy, >>It's usually, you know, one of the things I'm seeing here, and John and I have talked about this in the past, this idea of a platform organization and enterprises. So consistently what I'm seeing is, you know, somebody, a cto, CIO level, you know, individual is making a determin decision. I have multiple internal buss who are now modernizing applications. They're individually investing in DevOps. And this is not a good investment for my business. I'm going to centralize some of this capability so that we can all benefit together. And that team is essentially a platform organization and they're making Kubernetes a shared services platform so that everybody else can come and, and, and sort of, you know, consume it. So what that means to us is our customer is a platform organization and their customer is a developer. So we have to make two constituencies successful. Our customer who's providing a multi-tenant platform, and then their customer who's a developer, both have to be happy. If you don't solve for both, you know, constituencies, you're not gonna be >>Successful. You're targeting the builder of the infrastructure and the consumer of that infrastructure. >>Yes sir. It has to be both. Exactly. Right. Right. So, so that look, honestly, that it, it, you know, it takes iterations to figure these things out, right? But this is a consistent theme that I am seeing. In fact, what I would argue now is that every enterprise should be really stepping back and thinking about what is my platform strategy. Cuz if you don't have a platform strategy, you're gonna have a bunch of different teams who are doing different things and some will be successful and look, some will not be. And that is not good for business. >>Yeah. And, and stage, I wanna get to you, you mentioned that your transformation was what you look forward and your title, global head of cloud sre. Okay, so sre, we all know came from Google, right? Everyone wants to be like Google, but no one wants to be like Google, right? And no one is Google, Google's a unique thing. It's only one Google. But they had the dynamic and the power dynamic of one person to large scale set of servers or infrastructure. But concept is, is, is can be portable, but, but the situation isn't. So board became Kubernetes, that's inside baseball. So you're doing essentially what Google did at their scale you're doing for Mass Mutual. That's kind of what's happening. Is that kind of how I see it? And you guys are playing in there partnering. >>So I I totally agree. Google introduce, sorry, Ty engineering. And, and if you take, you know, the traditional transformation of the roles, right? In the past it was called operations and then DevOps ops came in and then SRE is is the new buzzword. And the future could be something like product engineering, right? And, and, and in this journey, you know, here is what I tell, you know, folks on my side like what worked for Google might not work for a financial company, might not work for an insurance company. So, so, so it's, it's okay to use the word sre, but but the end of the day that SRE has to be tailored down to, to your requirements and and, and the customers that you serve and the technology that you serve. Yep. >>And this is, this is why I'm coming back, this platform engineering. At the end of the day, I think SRE just translates to, you're gonna have a platform engineering team cuz you gotta enable developers to be producing more code faster, better, cheaper guardrails policy. So this, it's kind of becoming the, you serve the business, which is now the developers it used to serve the business Yep. Back in the old days. Hey, the, it serves the business. Yep. Which is a terminal, >>Which is actually true >>Now it the new, it serves the developers, which is the business. Which is the business. Because if digital transformation goes to completion, the company is the app. Yep. >>And the, you know, the, the hard line between development and operations, right? So, so that's thining down over the time, you know, like that that line might disappear. And, and, and that's where asari is fitting in. >>Yeah. And they're building platforms to scale the enablement up that what is, so what is the key challenges you guys are, are both building out together this new transformational direction? What's new and what's the same, The same is probably the business results, but what's the new dynamic involved in rolling it out and making people successful? You got the two constituents, the builders of the infrastructures and the consumers of the services on the other side. What's the new thing? >>So the new thing if, if I may go fast these, so the faster market to, you know, value, right? That we are bringing to the table. That's, that's very important. You know, business has an idea. How do you get that idea implemented in terms of technology and, and take it into real time. So that journey we have cut down, right? Technology is like Kubernetes. It makes, it makes, you know, an IT person's life so easy that, that they can, they can speed up the process in, in, in a traditional way. What used to take like an year or six months can be done in a month today or or less than that, right? So, so there's definitely the losses, speed, velocity, agility in general, and then flexibility. And then the automation that we put in, especially if you have to maintain like thousands of clusters, you know, these, these are today like, you know, it is possible to, to make that happen with a click off a button. In the past it used to take like, you know, probably, you know, a hundred, a hundred percent team and operational team to do it. And a lot of time. But, but, but that automation is happening. You know, and we can get into the technology as much as possible. But, but, you know, blueprinting and all that stuff made >>It possible. Well say that for another interview, we'll do it take time. >>But the, the end user on the other end, the consumer doesn't have the patience that they once had. Right? Right. It's, I want this in my lab now. Now, how does the culture of Mass Mutual, how is it evolv to be able to deliver the velocity that your customers are demanding? >>So if once in a while, you know, it's important to step yourself into the customer's shoes and think it from their, from their, from their perspective, business does not care how you're running your IT shop. What they care about is your stability of the product and the efficiencies of the product and, and, and how, how, how easy it is to reach out to the customers and how well we are serving the customers, right? So whether I'm implementing Docker in the background, Dr. Swam or es you know, business doesn't even care about it. What they really care about it is if your environment goes down, it's a problem. And, and, and if you, if your environment or if your solution is not as efficient as the business needs, that's the problem, right? So, so at that point, the business will step in. So our job is to make sure, you know, from an, from a technology perspective, how fast you can make implement it and how efficiently you can implement it. And at the same time, how do you play within the guardrails of security and compliance. >>So I was gonna ask you if you have VMware in your environment, cause a lot of clients compare what vCenter does for Kubernetes is really needed. And I think that's what you guys got going on. I I can say that you're the v center of Kubernetes. I mean, as a, as an as an metaphor, a place to manage it all is all 1, 1 1 paint of glass, so to speak. Is that how you see success in your environment? >>So virtualization has gone a long way, you know where we started, what we call bare metal servers, and then we virtualized operating systems. Now we are virtualizing applications and, and we are virtualizing platforms as well, right? So that's where Kubernetes basically got. >>So you see the need for a vCenter like thing for Uber, >>Definitely a need in the market in the way you need to think is like, you know, let's say there is, there is an insurance company who actually mented it and, and they gain the market advantage. Right? Now the, the the competition wants to do it as well, right? So, so, so there's definitely a virtualization of application layer that, that, that's very critical and it's, it's a critical component of cloud strategy as >>A whole. See, you're too humble to say it. I'll say you like the V center of Kubernetes, Explain what that means and your turn. If I said that to you, what would you react? How would you react to that? Would say bs or would you say on point, >>Maybe we should think about what does vCenter do today? Right? It's, it's so in my opinion, by the way, well vCenter in my opinion is one of the best platforms ever built. Like ha it's the best platform in my opinion ever built. It's, VMware did an amazing job because they took an IT engineer and they made him now be able to do storage management, networking management, VMs, multitenancy, access management audit, everything that you need to run a data center, you can do from a single, essentially single >>Platform, from a utility standpoint home >>Run. It's amazing, right? Yeah, it is because you are now able to empower people to do way more. Well why are we not doing that for Kubernetes? So the, the premise man Rafa was, well, oh, bless, I should have IT engineers, same engineers now they should be able to run fleets of clusters. That's what people that mass major are able to do now, right? So to that end, now you need cluster management, you need access management, you need blueprinting, you need policy management, you need ac, you know, all of these things that have happened before chargebacks, they used to have it in, in V center. Now they need to happen in other platforms. But for es so should do we do many of the things that vCenter does? Yes. >>Kind >>Of. Yeah. Are we a vCenter for es? Yeah, that is a John Forer question. >>All right, well, I, I'll, the speculation really goes back down to the earlier speed question. If you can take away the, the complexity and not make it more steps or change a tool chain or do something, then the devs move faster and the service layer that serves the business, the new organization has to enable speed. So this, this is becoming a, a real discussion point in the industry is that, oh yeah, we've got new tool, look at the shiny new toy. But if it doesn't move the needle, does it help productivity for developers? And does it actually scale up the enablement? That's the question. So I'm sure you guys are thinking about this a lot, what's your reaction? >>Yeah, absolutely. And one thing that just, you know, hit my mind is think about, you know, the hoteling industry before Airbnb and after Airbnb, right? Or, or, or the taxi industry, you know, before Uber and after Uber, right? So if I'm providing a platform, a Kubernetes platform for my application folks or for my application partners, they have everything ready. All they need to do is like, you know, build their application and deployed and running, right? They, they, they don't have to worry about provisioning of the servers and then building the middleware on top of it and then, you know, do a bunch of testing to make sure, you know, they, they, they iron out all the, all the compatible issues and whatnot. Yeah. Now, now, today, all I, all I say is like, hey, you have, we have a platform built for you. You just build your application and then deploy it in a development environment. That's where you put all the pieces of puzzle together, make sure you see your application working, and then the next thing that, that you do is like, you know, you know, build >>Production, chip, build production, go and chip release it. Yeah, that's the nirvana. But then we're there. I mean, we're there now we're there. So we see the future. Because if you, if that's the case, then the developers are the business. They have to be coding more features, they have to react to customers. They might see new business opportunities from a revenue standpoint that could be creatively built, got low code, no code, headless systems. These things are happening where this I call the architectural list environment where it's like, you don't need architecture, it's already happening. >>Yeah. And, and on top of it, you know, if, if someone has an idea, they want to implement an idea real quick, right? So how do you do it? Right? And, and, and you don't have to struggle building an environment to implement your idea and testers in real time, right? So, so from an innovation perspective, you know, agility plays a key role. And, and that, that's where the Kubernetes platforms or platforms like Kubernetes >>Plays. You know, Lisa, when we talked to Andy Chasy, when he was the CEO of aws, either one on one or on the cube, he always said, and this is kind of happening, companies are gonna be builders where it's not just utility. You need that table stakes to enable that new business idea. And so he, this last keynote, he did this big thing like, you know, think like your developers are the next entrepreneurial revenue generators. And I think that, I think starting to see that, what do you think about that? You see that coming sooner than later? Or is that in, in sight or is that still ways away? >>I, I think it's already happening at a level, at a certain level now. Now the question comes back to, you know, taking it to the reality, right? Yeah. I mean, you can, you can do your proof of concept, proof of technologies, and then, and then prove it out. Like, Hey, I got a new idea. This idea is great. Yeah. And, and it's to the business advantage, right? But we really want to see it in production live where your customers are actually >>Using it and the board meetings, Hey, we got a new idea that came in, generating more revenue, where'd that come from? Agile developer. Again, this is real. Yeah, >>Yeah. >>Absolutely agree. Yeah. I think, think both of you gentlemen said a word in, in your, as you were talking, you used the word guardrails, right? I think, you know, we're talking about rigidity, but you know, the really important thing is, look, these are enterprises, right? They have certain expectations. Guardrails is key, right? So it's automation with the guardrails. Yeah. Guardrails are like children, you know, you know, shouldn't be hurt. You know, they're seen but not hurt. Developers don't care about guard rails. They just wanna go fast. They also bounce >>Around a little bit. Yeah. Off the guardrails. >>One thing we know that's not gonna slow down is, is the expectations, right? Of all the consumers of this, the Ds the business, the, the business top line, and of course the customers. So the ability to, to really, as your website says, let's see, make life easy for platform teams is not trivial. And clearly what you guys are talking about here is you're, you're really an enabler of those platform teams, it sounds like to me. Yep. So, great work, guys. Thank you so much for both coming on the program, talking about what you're doing together, how you're seeing the, the evolution of Kubernetes, why, and really what the focus should be on those platform games. We appreciate all your time and your insights. >>Thank you so much for having us. Thanks >>For our pleasure. For our guests and for John Furrier, I'm Lisa Martin. You're watching The Cube Live, Cobe Con, Cloud Native con from Detroit. We've out with our next guest in just a minute, so stick around.

(bright upbeat music) >> Hey, guys. Welcome back to Detroit, Michigan. Lisa Martin and John Furrier here live with "theCUBE" at KubeCon CloudNativeCon, North America. John, it's been a great day. This is day one of our coverage of three days of coverage. Kubernetes is growing up. It's maturing. >> Yeah, we got three days of wall-to-wall coverage, all about Kubernetes. We heard about Security, Large scale, Cloud native at scale. That's the big focus. This next segment's going to be really awesome. You have a fast growing private company and a practitioner, big name, blue chip practitioner, building out next-gen cloud. First transforming, then building out the next level. This is classic, what we call Super Cloud-Like interview. It's going to be great. I'm looking forward to this. >> Anytime we can talk about Super Cloud, right? Please welcome back, one of our alumni, Haseeb Budhani is here, the CEO of Rafay. Great to see you. Santhosh Pasula, also joins us, the global head of Cloud SRE at Mass Mutual. Guys, great to have you on the program. >> Thanks for having us. >> Thank you for having me. >> So, Haseeb, you've been on "theCUBE" many times. You were on just recently, with the momentum that's around us today with the maturation of Kubernetes, the collaboration of the community, the recognition of the community. What are some of the things that you're excited about with on day one of the show? >> Wow, so many new companies. I mean, there are companies that I don't know who are here. And I live in this industry, and I'm seeing companies that I don't know, which is a good thing. It means that the community's growing. But at the same time, I'm also seeing another thing, which is, I have met more enterprise representatives at this show than other KubeCons. Like when we hung out at in Valencia, for example, or even other places, it hasn't been this many people. Which means, and this is a good thing that enterprises are now taking Kubernetes seriously. It's not a toy. It's not just for developers. It's enterprises who are now investing in Kubernetes as a foundational component for their applications going forward. And that to me is very, very good. >> Definitely, becoming foundational. >> Haseeb: Yeah. >> Well, you guys got a great traction. We had many interviews at "theCUBE," and you got a practitioner here with you guys, are both pioneering, kind of what I call the next-gen cloud. First you got to get through Gen-One, which you guys done at Mass Mutual extremely well. Take us through the story of your transformation? 'Cause you're on at the front end now of that next inflection point. But take us through how you got here? You had a lot of transformation success at Mass Mutual? >> So, I was actually talking about this topic few minutes back. And the whole cloud journey in big companies, large financial institutions, healthcare industry or insurance sector, it takes generations of leadership to get to that perfection level. And ideally, the cloud for strategy starts in, and then how do you standardize and optimize cloud, right? That's the second-gen altogether, and then operationalization of the cloud. And especially if you're talking about Kubernetes, in the traditional world, almost every company is running middleware and their applications in middleware. And their containerization is a topic that came in. And Docker is basically the runtime containerization. So, that came in first, and from Docker, eventually when companies started adopting Docker, Docker Swarm is one of the technologies that they adopted. And eventually, when we were taking it to a more complicated application implementations or modernization efforts, that's when Kubernetes played a key role. And as Haseeb was pointing out, you never saw so many companies working on Kubernetes. So, that should tell you one story, right? How fast Kubernetes is growing, and how important it is for your cloud strategy. >> And your success now, and what are you thinking about now? What's on your agenda now? As you look forward, what's on your plate? What are you guys doing right now? >> So we are past the stage of proof of concepts, proof of technologies, pilot implementations. We are actually playing it, the real game now. In the past, I used the quote, like "Hello world to real world." So, we are actually playing in the real world, not in the hello world anymore. Now, this is where the real time challenges will pop up. So, if you're talking about standardizing it, and then optimizing the cloud, and how do you put your governance structure in place? How do you make sure your regulations are met? The demands that come out of regulations are met? And how are you going to scale it? And while scaling, how are you going to keep up with all the governance and regulations that come with it? So we are in that stage today. >> Haseeb talked about, you talked about the great evolution of what's going on at Mass Mutual. Haseeb talk a little bit about who? You mentioned one of the things that's surprising you about this KubeCon in Detroit, is that you're seeing a lot more enterprise folks here? Who's deciding in the organization and your customer conversations? Who are the decision makers in terms of adoption of Kubernetes these days? Is that elevating? >> Hmm. Well, this guy. (Lisa laughing) One of the things I'm seeing here, and John and I have talked about this in the past, this idea of a platform organization and enterprises. So, consistently what I'm seeing, is somebody, a CTO, CIO level, an individual is making a decision. I have multiple internal Bus who are now modernizing applications. They're individually investing in DevOps, and this is not a good investment for my business. I'm going to centralize some of this capability so that we can all benefit together. And that team is essentially a platform organization. And they're making Kubernetes a shared services platform so that everybody else can come and sort of consume it. So, what that means to us, is our customer is a platform organization, and their customer is a developer. So we have to make two constituencies successful. Our customer who's providing a multi-tenant platform, and then their customer, who's your developer, both have to be happy. If you don't solve for both, you know, constituencies, you're not going to be successful. >> So, you're targeting the builder of the infrastructure and the consumer of that infrastructure? >> Yes, sir. It has to be both. >> On the other side? >> Exactly, right. So that look, honestly, it takes iteration to figure these things out. But this is a consistent theme that I am seeing. In fact, what I would argue now, is that every enterprise should be really stepping back and thinking about what is my platform strategy? Because if you don't have a platform strategy, you're going to have a bunch of different teams who are doing different things, and some will be successful, and look, some will not be. And that is not good for business. >> Yeah, and Santhosh, I want to get to you. You mentioned your transformations, what you look forward, and your title, Global Head of Cloud, SRE. Okay, so SRE, we all know came from Google, right? Everyone wants to be like Google, but no one wants to be like Google, right? And no one is Google. Google's a unique thing. >> Haseeb: Only one Google. >> But they had the dynamic and the power dynamic of one person to large scale set of servers or infrastructure. But concept can be portable, but the situation isn't. So, Borg became Kubernetes, that's inside baseball. So, you're doing essentially what Google did at their scale, you're doing for Mass Mutual. That's kind of what's happening, is that kind of how I see it? And you guys are playing in there partnering? >> So, I totally agree. Google introduce SRE, Site Reliability Engineering. And if you take the traditional transformation of the roles, in the past, it was called operations, and then DevOps ops came in, and then SRE is the new buzzword. And the future could be something like Product Engineering. And in this journey, here is what I tell folks on my side, like what worked for Google might not work for a financial company. It might not work for an insurance company. It's okay to use the word, SRE, but end of the day, that SRE has to be tailored down to your requirements. And the customers that you serve, and the technology that you serve. >> This is why I'm coming back, this platform engineering. At the end of the day, I think SRE just translates to, you're going to have a platform engineering team? 'Cause you got to enable developers to be producing more code faster, better, cheaper, guardrails, policies. It's kind of becoming the, these serve the business, which is now the developers. IT used to serve the business back in the old days, "Hey, the IT serves the business." >> Yup. >> Which is a term now. >> Which is actually true now. >> The new IT serves the developers, which is the business. >> Which is the business. >> Because if digital transformation goes to completion, the company is the app. >> The hard line between development and operations, so that's thinning down. Over the time, that line might disappear. And that's where SRE is fitting in. >> Yeah, and then building platform to scale the enablement up. So, what is the key challenges? You guys are both building out together this new transformational direction. What's new and what's the same? The same is probably the business results, but what's the new dynamic involved in rolling it out and making people successful? You got the two constituents, the builders of the infrastructures and the consumers of the services on the other side. What's the new thing? >> So, the new thing, if I may go first. The faster market to value that we are bringing to the table, that's very important. Business has an idea. How do you get that idea implemented in terms of technology and take it into real time? So, that journey we have cut down. Technology is like Kubernetes. It makes an IT person's life so easy that they can speed up the process. In a traditional way, what used to take like an year, or six months, can be done in a month today, or less than that. So, there's definitely speed velocity, agility in general, and then flexibility. And then the automation that we put in, especially if you have to maintain like thousands of clusters. These are today, it is possible to make that happen with a click off a button. In the past, it used to take, probably, 100-person team, and operational team to do it, and a lot of time. But that automation is happening. And we can get into the technology as much as possible, but blueprinting and all that stuff made it possible. >> We'll save that for another interview. We'll do it deep time. (panel laughing) >> But the end user on the other end, the consumer doesn't have the patience that they once had, right? It's, "I want this in my lab now." How does the culture of Mass Mutual? How is it evolve to be able to deliver the velocity that your customers are demanding? >> Once in a while, it's important to step yourself into the customer's shoes and think it from their perspective. Business does not care how you're running your IT shop. What they care about is your stability of the product and the efficiencies of the product, and how easy it is to reach out to the customers. And how well we are serving the customers, right? So, whether I'm implementing Docker in the background, Docker Swam or Kubernetes, business doesn't even care about it. What they really care about, it is, if your environment goes down, it's a problem. And if your environment or if your solution is not as efficient as the business needs, that's the problem, right? So, at that point, the business will step in. So, our job is to make sure, from a technology perspective, how fast you can make implement it? And how efficiently you can implement it? And at the same time, how do you play within the guardrails of security and compliance? >> So, I was going to ask you, if you have VMware in your environment? 'Cause a lot of clients compare what vCenter does for Kubernetes is really needed. And I think that's what you guys got going on. I can say that, you're the vCenter of Kubernetes. I mean, as as metaphor, a place to manage it all, is all one paint of glass, so to speak. Is that how you see success in your environment? >> So, virtualization has gone a long way. Where we started, what we call bare metal servers, and then we virtualized operating systems. Now, we are virtualizing applications, and we are virtualizing platforms as well, right? So that's where Kubernetes plays a role. >> So, you see the need for a vCenter like thing for Kubernetes? >> There's definitely a need in the market. The way you need to think is like, let's say there is an insurance company who actually implement it today, and they gain the market advantage. Now, the the competition wants to do it as well, right? So, there's definitely a virtualization of application layer that's very critical, and it's a critical component of cloud strategy as a whole. >> See, you're too humble to say it. I'll say, you're like the vCenter of Kubernetes. Explain what that means in your term? If I said that to you, what would you react? How would you react to that? Would you say, BS, or would you say on point? >> Maybe we should think about what does vCenter do today? So, in my opinion, by the way, vCenter in my opinion, is one of the best platforms ever built. Like it's the best platform in my opinion ever built. VMware did an amazing job, because they took an IT engineer, and they made him now be able to do storage management, networking management, VM's multitenancy, access management, audit. Everything that you need to run a data center, you can do from essentially single platform. >> John: From a utility standpoint, home-run? >> It's amazing. >> Yeah. >> Because you are now able to empower people to do way more. Well, why are we not doing that for Kubernetes? So, the premise man Rafay was, well, I should have IT engineers, same engineers. Now, they should be able to run fleets of clusters. That's what people that Mass Mutual are able to do now. So, to that end, now you need cluster management, you need access management, you need blueprinting, you need policy management. All of these things that have happened before, chargebacks, they used to have it in vCenter, now they need to happen in other platforms but for Kubernetes. So, should we do many of the things that vCenter does? Yes. >> John: Kind of, yeah. >> Are we a vCenter for Kubernetes? >> No. >> That is a John Furrier question. >> All right, well, the speculation really goes back down to the earlier speed question. If you can take away the complexity and not make it more steps, or change a tool chain, or do something, then the Devs move faster. And the service layer that serves the business, the new organization, has to enable speed. This is becoming a real discussion point in the industry, is that, "Yeah, we got new tool. Look at the shiny new toy." But if it move the needle, does it help productivity for developers? And does it actually scale up the enablement? That's the question. So, I'm sure you guys are thinking about this a lot. What's your reaction? >> Yeah, absolutely. And one thing that just hit my mind, is think about the hoteling industry before Airbnb and after Airbnb. Or the taxi industry before Uber and after Uber. So, if I'm providing a platform, a Kubernetes platform for my application folks, or for my application partners, they have everything ready. All they need to do is build their application and deploy it, and run it. They don't have to worry about provisioning of the servers, and then building the Middleware on top of it, and then, do a bunch of testing to make sure they iron out all the compatible issues and whatnot. Now, today, all I say is like, "Hey, we have a platform built for you. You just build your application, and then deploy it in a development environment, that's where you put all the pieces of puzzle together. Make sure you see your application working, and then the next thing that you do is like, do the correction. >> John: Shipping. >> Shipping. You build the production. >> John: Press. Go. Release it. (laughs) That when you move on, but they were there. I mean, we're there now. We're there. So, we need to see the future, because that's the case, then the developers are the business. They have to be coding more features, they have to react to customers. They might see new business opportunities from a revenue standpoint that could be creatively built, got low code, no code, headless systems. These things are happening where there's, I call the Architectural List Environment where it's like, you don't need architecture, it's already happening. >> Yeah, and on top of it, if someone has an idea, they want to implement an idea real quick. So, how do you do it? And you don't have to struggle building an environment to implement your idea and test it in real time. So, from an innovation perspective, agility plays a key role. And that's where the Kubernetes platforms, or platforms like Kubernetes plays. >> You know, Lisa, when we talked to Andy Jassy, when he was the CEO of AWS, either one-on-one or on "theCUBE," he always said, and this is kind of happening, "Companies are going to be builders, where it's not just utility, you need that table stakes to enable that new business idea." And so, in this last keynote, he did this big thing like, "Think like your developers are the next entrepreneurial revenue generators." I think I'm starting to see that. What do you think about that? You see that coming sooner than later? Or is that an insight, or is that still ways away? >> I think it's already happening at a level, at a certain level. Now ,the question comes back to, you know, taking it to the reality. I mean, you can do your proof of concept, proof of technologies, and then prove it out like, "Hey, I got a new idea. This idea is great." And it's to the business advantage. But we really want to see it in production live where your customers are actually using it. >> In the board meetings, "Hey, we got a new idea that came in, generating more revenue, where'd that come from?" Agile Developer. Again, this is real. >> Yeah. >> Yeah. Absolutely agree. Yeah, I think both of you gentlemen said a word as you were talking, you used the word, Guardrails. We're talking about agility, but the really important thing is, look, these are enterprises, right? They have certain expectations. Guardrails is key, right? So, it's automation with the guardrails. Guardrails are like children, you know, shouldn't be heard. They're seen but not heard. Developers don't care about guardrails, they just want to go fast. >> They also bounce around a little bit, (laughs) off the guardrails. >> Haseeb: Yeah. >> One thing we know that's not going to slow down, is the expectations, right? Of all the consumers of this, the Devs, the business, the business top line, and, of course, the customers. So, the ability to really, as your website says, let's say, "Make Life Easy for Platform Teams" is not trivial. And clearly what you guys are talking about here, is you're really an enabler of those platform teams, it sounds like to me. >> Yup. >> So, great work, guys. Thank you so much for both coming on the program, talking about what you're doing together, how you're seeing the evolution of Kubernetes, why? And really, what the focus should be on those platform teams. We appreciate all your time and your insights. >> Thank you so much for having us. >> Thanks for having us. >> Our pleasure. For our guests and for John Furrier, I'm Lisa Martin. You're watching "theCUBE" Live, KubeCon CloudNativeCon from Detroit. We'll be back with our next guest in just a minute, so stick around. (bright upbeat music)

(calm music) >> Hi everybody. We're here at VeeamON 2022. This is day two of the CUBE's continuous coverage. I'm Dave Vellante. My co-host is Dave Nicholson. A ton of energy. The keynotes, day two keynotes are all about products at Veeam. Veeam, the color of green, same color as money. And so, and it flows in this ecosystem. I'll tell you right now, Michael Cade is here. He's the senior technologist for product strategy at Veeam. Michael, fresh off the keynotes. >> Yeah, yeah. >> Welcome. Danny Allen's keynote was fantastic. I mean, that story he told blew me away. I can't wait to have him back. Stay tuned for that one. But we're going to talk about protecting containers, Kasten. You guys got announcements of Kasten by Veeam, you call it K10 version five, I think? >> Yeah. So just rolled into 5.0 release this week. Now, it's a bit different to what we see from a VBR release cycle kind of thing, cause we're constantly working on a two week sprint cycle. So as much as 5.0's been launched and announced, we're going to see that trickling out over the next couple of months until we get round to Cube (indistinct) and we do all of this again, right? >> So let's back up. I first bumped into Kasten, gosh, it was several years ago at VeeamON. Like, wow this is a really interesting company. I had deep conversations with them. They had a sheer, sheer cat grin, like something was going on and okay finally you acquire them, but go back a little bit of history. Like why the need for this? Containers used to be ephemeral. You know, you didn't have to persist them. That changed, but you guys are way ahead of that trend. Talk a little bit more about the history there and then we'll get into current day. >> Yeah, I think the need for stateful workloads within Kubernetes is absolutely grown. I think we just saw 1.24 of Kubernetes get released last week or a couple of weeks ago now. And really the focus there, you can see, at least three of the big ticket items in that release are focused around storage and data. So it just encourages that the community is wanting to put these data services within that. But it's also common, right? It's great to think about a stateless... If you've got stateless application but even a web server's got some state, right? There's always going to be some data associated to an application. And if there isn't then like, great but that doesn't really work- >> You're right. Where'd they click, where'd they go? I mean little things like that, right? >> Yeah. Yeah, exactly. So one of the things that we are seeing from that is like obviously the requirement to back up and put in a lot of data services in there, and taking full like exposure of the Kubernetes ecosystem, HA, and very tiny containers versus these large like virtual machines that we've always had the story at Veeam around the portability and being able to move them left, right, here, there, and everywhere. But from a K10 point of view, the ability to not only protect them, but also move those applications or move that data wherever they need to be. >> Okay. So, and Kubernetes of course has evolved. I mean the early days of Kubernetes, they kept it simple, kind of like Veeam actually. Right? >> Yeah. >> And then, you know, even though Mesosphere and even Docker Swarm, they were trying to do more sophisticated cluster management. Kubernetes has now got projects getting much more complicated. So more complicated workloads mean more data, more critical data means more protection. Okay, so you acquire Kasten, we know that's a small part of your business today but it's going to be growing. We know this cause everybody's developing applications. So what's different about protecting containers? Danny talks about modern data protection. Okay, when I first heard that, I'm like, eh, nice tagline, but then he peel the onion. He explains how in virtualization, you went from agents to backing up of VMware instance, a virtual instance. What's different about containers? What constitutes modern data protection for containers? >> Yeah, so I think the story that Danny tells as well, is so when we had our physical agents and virtualization came along and a lot of... And this is really where Veeam was born, right, we went into the virtualization API, the VMware API, and we started leveraging that to be more storage efficient. The admin overhead around those agents weren't there then, we could just back up using the API. Whereas obviously a lot of our competition would use agents still and put that resource overhead on top of that. So that's where Veeam initially got the kickstart in that world. I think it's very similar to when it comes to Kubernetes because K10 is deployed within the Kubernetes cluster and it leverages the Kubernetes API to pull out that data in a more efficient way. You could use image based backups or traditional NAS based backups to protect some of the data, and backup's kind of the... It's only one of the ticks in the boxes, right? You have to be able to restore and know what that data is. >> But wait, your competitors aren't as fat, dumb and happy today as they were back then, right? So it can't... They use the same APIs and- >> Yeah. >> So what makes you guys different? >> So I think that's testament to the Kubernetes and the community behind that and things like the CSI driver, which enables the storage vendors to take that CSI abstraction layer and then integrate their storage components, their snapshot technologies, and other efficiency models in there, and be able to leverage that as part of a universal data protection API. So really that's one tick in the box and you're absolutely right, there's open source tools that can do exactly what we're doing to a degree on that backup and recovery. Where it gets really interesting is the mobility of data and how we're protecting that. Because as much as stateful workloads are seen within the Kubernetes environments now, they're also seen outside. So things like Amazon RDS, but the front end lives in Kubernetes going to that stateless point. But being able to protect the whole application and being very application aware means that we can capture everything and restore wherever we want that to go as well. Like, so the demo that I just did was actually a Postgres database in AWS, and us being able to clone or migrate that out into an EKS cluster as a staple set. So again, we're not leveraging RDS at that point, but it gives us the freedom of movement of that data. >> Yeah, I want to talk about that, what you actually demoed. One of the interesting things, we were talking earlier, I didn't see any CLI when you were going through the integration of K10 V5 and V12. >> Yeah. >> That was very interesting, but I'm more skeptical of this concept, of the single pane of glass and how useful that is. Who is this integration targeting? Are you targeting the sort of traditional Veeam user who is now adding as a responsibility, the management of protecting these Kubernetes environments? Or are you at the same time targeting the current owners of those environments? Cause I know you talk about shift left and- >> Yeah. >> You know, nobody needs Kubernetes if you only have one container and one thing you're doing. So at some point it's all about automation, it's about blueprints, it's about getting those things in early. So you get up, you talk about this integration, who cares about that kind of integration? >> Yeah, so I think it's a bit of both, right? So we're definitely focused around the DevOps focused engineer. Let's just call it that. And under an umbrella, the cloud engineer that's looking after Kubernetes, from an application delivery perspective. But I think more and more as we get further up the mountain, CIS admin, obviously who we speak to the tech decision makers, the solutions architects systems engineers, they're going to inherit and be that platform operator around the Kubernetes clusters. And they're probably going to land with the requirement around data management as well. So the specific VBR centralized management is very much for the backup admin, the infrastructure admin or the cloud based engineer that's looking after the Kubernetes cluster and the data within that. Still we speak to app developers who are conscious of what their database looks like, because that's an external data service. And the biggest question that we have or the biggest conversation we have with them is that the source code, the GitHub or the source repository, that's fine, that will get your... That'll get some of the way back up and running, but when it comes to a Postgres database or some sort of data service, oh, that's out of the CI/CD pipeline. So it's whether they're interested in that or whether that gets farmed out into another pre-operations, the traditional operations team. >> So I want to unpack your press release a little bit. It's full of all the acronyms, so maybe you can help us- >> Sure. >> Cipher. You got security everywhere enhance platform hardening, including KMS. That's key- >> Yeah, key management service, yeah. >> System, okay. With AWS, KMS and HashiCorp vault. Awesome, love to see HashiCorp company. >> Yeah. >> RBAC objects in UI dashboards, ransomware attacks, AWS S3. So anyway, security everywhere. What do you mean by that? >> So I think traditionally at Veeam, and continue that, right? From a security perspective, if you think about the failure scenario and ransomware's, the hot topic, right, when it comes to security, but we can think about security as, if we think about that as the bang, right, the bang is something bad's happen, fire, flood, blood, type stuff. And we tend to be that right hand side of that, we tend to be the remediation. We're definitely the one, the last line of defense to get stuff back when something really bad happens. And I think what we've done from a K10 point of view, is not only enhance that, so with the likes of being able to... We're not going to reinvent the wheel, let's use the services that HashiCorp have done from a HashiCorp vault point of view and integrate from a key management system. But then also things like S3 or ransomware prevention. So I want to know if something bad's happened and Kasten actually did something more generic from a Veeam ONE perspective, but one of the pieces that we've seen since we've then started to send our backups to an immutable object storage, is let's be more of that left as well and start looking at the preventative tasks that we can help with. Now, we're not going to be a security company, but you heard all the way through Danny's like keynote, and probably when he is been on here, is that it's always, we're always mindful of that security focus. >> On that point, what was being looked for? A spike in CPU utilization that would be associated with encryption? >> Yeah, exactly that. >> Is that what was being looked- >> That could be... Yeah, exactly that. So that could be from a virtual machine point of view but from a K10, and it specifically is that we're going to look at the S3 bucket or the object storage, we're going to see if there's a rate of change that's out of the normal. It's an abnormal rate. And then with that, we can say, okay, that doesn't look right, alert us through observability tools, again, around the cloud native ecosystem, Prometheus Grafana. And then we're going to get insight into that before the bang happens, hopefully before the bang. >> So that's an interesting when we talk about adjacencies and moving into this area of security- >> We're talking to Zeus about that too. >> Exactly. That's that sort of creep where you can actually add value. It's interesting. >> So, okay. So we talked about shift left, get that, and then expanded ecosystem, industry leading technologies. By the way, one of them is the Red Hat Marketplace. And I think, I heard Anton's... Anton was amazing. He is the head of product management at Veeam. Is been to every VeeamON. He's got family in Ukraine. He's based in Switzerland. >> Yeah. >> But he chose not to come here because he's obviously supporting, you know, the carnage that's going on in Ukraine. But anyway, I think he said the Red Hat team is actually in Ukraine developing, you know, while the bombs are dropping. That's amazing. But anyway, back to our interview here, expanded ecosystem, Red Hat, SUSE with Rancher, they've got some momentum. vSphere with Tanzu, they're in the game. Talk about that ecosystem and its importance. >> Yeah, and I think, and it goes back to your point around the CLI, right? Is that it feels like the next stage of Kubernetes is going to be very much focused towards the operator or the operations team. The CIS admin of today is going to have to look after that. And at the moment it's all very command line, it's all CLI driven. And I think the marketplace is OpenShift, being our biggest foothold around our customer base, is definitely around OpenShift. But things like, obviously we are a longstanding alliance partner with VMware as well. So their Tanzu operations actually there's support for TKGS, so vSphere Tanzu grid services is another part of the big release of 5.0. But all three of those and the common marketplace gives us a UI, gives us a way of being able to see and visualize that rather than having to go and hunt down the commands and get our information through some- >> Oh, some people are going to be unhappy about that. >> Yeah. >> But I contend the human eye has evolved to see in color for a very good reason. So I want to see things in red, yellow, and green at times. >> There you go, yeah. >> So when we hear a company like Veeam talk about, look we have no platform agenda, we don't care which cloud it's in. We don't care if it's on-prem or Google Azure, AWS. We had Wasabi on, we have... Great, they got an S3 compatible, you know, target, and others as well. When we hear them, companies like you, talk about that consistent experience, single pane of glass that you're skeptical of, maybe cause it's technically challenging, one of the things, we call it super cloud, right, that's come up. Danny and I were riffing on that the other day and we'll do that more this afternoon. But it brings up something that we were talking about with Zeus, Dave, which is the edge, right? And it seems like Kubernetes, and we think about OpenShift. >> Yeah. >> We were there last week at Red Hat Summit. It's like 50% of the conversation, if not more, was the edge. Right, and really true edge, worst cases, use cases. Two weeks ago we were at Dell Tech, there was a lot of edge talk, but it was retail stores, like Lowe's. Okay, that's kind of near edge, but the far edge, we're talking space, right? So seems like Kubernetes fits there and OpenShift, you know, particularly, as well as some of the others that we mentioned. What about edge? How much of what you're doing with container data protection do you see as informing you about the edge opportunity? Are you seeing any patterns there? Nobody's really talking about it in data protection yet. >> So yeah, large scale numbers of these very small clusters that are out there on farms or in wind turbines, and that is definitely something that is being spoken about. There's not much mention actually in this 5.0 release because we actually support things like K3s,(indistinct), that all came in 4.5, but I think, to your first point as well, David, is that, look, we don't really care what that Kubernetes distribution is. So you've got K3s lightweight Kubernetes distribution, we support it, because it uses the same native Kubernetes APIs, and we get deployed inside of that. I think where we've got these large scale and large numbers of edge deployments of Kubernetes and that you require potentially some data management down there, and they might want to send everything into a centralized location or a more centralized location than a farm shed out in the country. I think we're going to see a big number of that. But then we also have our multi cluster dashboard that gives us the ability to centralize all of the control plane. So we don't have to go into each individual K10 deployment to manage those policies. We can have one big centralized management multi cluster dashboard, and we can set global policies there. So if you're running a database and maybe it's the same one across all of your different edge locations, where you could just set one policy to say I want to protect that data on an hourly basis, a daily basis, whatever that needs to be, rather than having to go into each individual one. >> And then send it back to that central repository. So that's the model that you see, you don't see the opportunity, at least at this point in time, of actually persisting it at the edge? >> So I think it depends. I think we see both, but again, that's the footprint. And maybe like you mentioned about up in space having a Kubernetes cluster up there. You don't really want to be sending up a NAS device or a storage device, right, to have to sit alongside it. So it's probably, but then equally, what's the art of the possible to get that back down to our planet, like as part of a consistent copy of data? >> Or even a farm or other remote locations. The question is, I mean, EVs, you know, we believe there's going to be tons of data, we just don't.. You think about Tesla as a use case, they don't persist a ton of their data. Maybe if a deer runs across, you know, the front of the car, oh, persist that, send that back to the cloud. >> I don't want anyone knowing my Tesla data. I'll tell you that right now. (all laughing) >> Well, there you go, that one too. All right, well, that's future discussion, we're still trying to squint through those patterns. I got so many questions for you, Michael, but we got to go. Thanks so much for coming to theCUBE. >> Always. >> Great job on the keynote today and good luck. >> Thank you. Thanks for having me. >> All right, keep it right there. We got a ton of product talk today. As I said, Danny Allan's coming back, we got the ecosystem coming, a bunch of the cloud providers. We have, well, iland was up on stage. They were just recently acquired by 11:11 Systems. They were an example today of a cloud service provider. We're going to unpack it all here on theCUBE at VeeamON 2022 from Las Vegas at the Aria. Keep it right there. (calm music)

>>Hi everybody. This is Dave Volante. Welcome to this cube conversation where we're going to go back in time a little bit and explore the early days of Kubernetes. Talk about how it formed the improbable events, perhaps that led to it. And maybe how customers are taking advantage of containers and container orchestration today, and maybe where the industry is going. Matt Provo is here. He's the founder and CEO of storm forge and Chandler Huntington hoes. Hoisington is the general manager of EKS edge and hybrid AWS guys. Thanks for coming on. Good to see you. Thanks for having me. Thanks. So, Jenny, you were the vice president of engineering at miso sphere. Is that, is that correct? >>Well, uh, vice-president engineering basis, fear and then I ran product and engineering for DTQ masons. >>Yeah. Okay. Okay. So you were there in the early days of, of container orchestration and Matt, you, you were working at a S a S a Docker swarm shop, right? Yep. Okay. So I mean, a lot of people were, you know, using your platform was pretty novel at the time. Uh, it was, it was more sophisticated than what was happening with, with Kubernetes. Take us back. What was it like then? Did you guys, I mean, everybody was coming out. I remember there was, I think there was one Docker con and everybody was coming, the Kubernetes was announced, and then you guys were there, doc Docker swarm was, was announced and there were probably three or four other startups doing kind of container orchestration. And what, what were those days like? Yeah. >>Yeah. I wasn't actually atmosphere for those days, but I know them well, I know the story as well. Um, uh, I came right as we started to pivot towards Kubernetes there, but, um, it's a really interesting story. I mean, obviously they did a documentary on it and, uh, you know, people can watch that. It's pretty good. But, um, I think that, from my perspective, it was, it was really interesting how this happened. You had basically, uh, con you had this advent of containers coming out, right? So, so there's new novel technology and Solomon, and these folks started saying, Hey, you know, wait a second, wait if I put a UX around these couple of Linux features that got launched a couple of years ago, what does that look like? Oh, this is pretty cool. Um, so you have containers starting to crop up. And at the same time you had folks like ThoughtWorks and other kind of thought leaders in the space, uh, starting to talk about microservices and saying, Hey, monoliths are bad and you should break up these monoliths into smaller pieces. >>And any Greenfield application should be broken up into individuals, scalable units that a team can can own by themselves, and they can scale independent of each other. And you can write tests against them independently of other components. And you should break up these big, big mandalas. And now we are kind of going back to model this, but that's for another day. Um, so, so you had microservices coming out and then you also had containers coming out, same time. So there was like, oh, we need to put these microservices in something perfect. We'll put them in containers. And so at that point, you don't really, before that moment, you didn't really need container orchestration. You could just run a workload in a container and be done with it, right? You didn't need, you don't need Kubernetes to run Docker. Um, but all of a sudden you had tons and tons of containers and you had to manage these in some way. >>And so that's where container orchestration came, came from. And, and Ben Heineman, the founder of Mesa was actually helping schedule spark at the time at Berkeley. Um, and that was one of the first workloads with spark for Macy's. And then his friends at Twitter said, Hey, come over, can you help us do this with containers at Twitter? He said, okay. So when it helped them do it with containers at Twitter, and that's kinda how that branch of the container wars was started. And, um, you know, it was really, really great technology and it actually is still in production in a lot of shops today. Um, uh, more and more people are moving towards Kubernetes and Mesa sphere saw that trend. And at the end of the day, Mesa sphere was less concerned about, even though they named the company Mesa sphere, they were less concerned about helping customers with Mesa specifically. They really want to help customers with these distributed problems. And so it didn't make sense to, to just do Mesa. So they would took on Kubernetes as well. And I hope >>I don't do that. I remember, uh, my, my co-founder John furrier introduced me to Jerry Chen way back when Jerry is his first, uh, uh, VC investment with Greylock was Docker. And we were talking in these very, obviously very excited about it. And, and his Chandler was just saying, it said Solomon and the team simplified, you know, containers, you know, simple and brilliant. All right. So you guys saw the opportunity where you were Docker swarm shop. Why? Because you needed, you know, more sophisticated capabilities. Yeah. But then you, you switched why the switch, what was happening? What was the mindset back then? We ran >>And into some scale challenges in kind of operationalize or, or productizing our kind of our core machine learning. And, you know, we, we, we saw kind of the, the challenges, luckily a bit ahead of our time. And, um, we happen to have someone on the team that was also kind of moonlighting, uh, as one of the, the original core contributors to Kubernetes. And so as this sort of shift was taking place, um, we, we S we saw the flexibility, uh, of what was becoming Kubernetes. Um, and, uh, I'll never forget. I left on a Friday and came back on a Monday and we had lifted and shifted, uh, to Kubernetes. Uh, the challenge was, um, you know, you, at that time, you, you didn't have what you have today through EKS. And, uh, those kinds of services were, um, just getting that first cluster up and running was, was super, super difficult, even in a small environment. >>And so I remember we, you know, we, we finally got it up and running and it was like, nobody touch it, don't do anything. Uh, but obviously that doesn't, that doesn't scale either. And so that's really, you know, being kind of a data science focused shop at storm forge from the very beginning. And that's where our core IP is. Uh, our, our team looked at that problem. And then we looked at, okay, there are a bunch of parameters and ways that I can tune this application. And, uh, why are the configurations set the way that they are? And, you know, uh, is there room to explore? And that's really where, unfortunately, >>Because Mesa said much greater enterprise capabilities as the Docker swarm, at least they were heading in that direction, but you still saw that Kubernetes was, was attractive because even though it didn't have all the security features and enterprise features, because it was just so simple. I remember Jen Goldberg who was at Google at the time saying, no, we were focused on keeping it simple and we're going from mass adoption, but does that kind of what you said? >>Yeah. And we made a bet, honestly. Uh, we saw that the, uh, you know, the growing community was really starting to, you know, we had a little bit of an inside view because we had, we had someone that was very much in the, in the original part, but you also saw the, the tool chain itself start to, uh, start to come into place right. A little bit. And it's still hardening now, but, um, yeah, we, as any, uh, as any startup does, we, we made a pivot and we made a bet and, uh, this, this one paid off >>Well, it's interesting because, you know, we said at the time, I mean, you had, obviously Amazon invented the modern cloud. You know, Microsoft has the advantage of has got this huge software stays, Hey, just now run it into the cloud. Okay, great. So they had their entry point. Google didn't have an entry point. This is kind of a hail Mary against Amazon. And, and I, I wrote a piece, you know, the improbable, Verizon, who Kubernetes to become the O S you know, the cloud, but, but I asked, did it make sense for Google to do that? And it never made any money off of it, but I would argue they, they were kind of, they'd be irrelevant if they didn't have, they hadn't done that yet, but it didn't really hurt. It certainly didn't hurt Amazon EKS. And you do containers and your customers you've embraced it. Right. I mean, I, I don't know what it was like early days. I remember I've have talked to Amazon people about this. It's like, okay, we saw it and then talk to customers, what are they doing? Right. That's kind of what the mindset is, right? Yeah. >>That's, I, I, you know, I've, I've been at Amazon a couple of years now, and you hear the stories of all we're customer obsessed. We listened to our customers like, okay, okay. We have our company values, too. You get told them. And when you're, uh, when you get first hired in the first day, and you never really think about them again, but Amazon, that really is preached every day. It really is. Um, uh, and that we really do listen to our customers. So when customers start asking for communities, we said, okay, when we built it for them. So, I mean, it's, it's really that simple. Um, and, and we also, it's not as simple as just building them a Kubernetes service. Amazon has a big commitment now to start, you know, getting involved more in the community and working with folks like storm forage and, and really listening to customers and what they want. And they want us working with folks like storm florigen and that, and that's why we're doing things like this. So, well, >>It's interesting, because of course, everybody looks at the ecosystem, says, oh, Amazon's going to kill the ecosystem. And then we saw an article the other day in, um, I think it was CRN, did an article, great job by Amazon PR, but talk about snowflake and Amazon's relationship. And I've said many times snowflake probably drives more than any other ISV out there. And so, yeah, maybe the Redshift guys might not love snowflake, but Amazon in general, you know, they're doing great three things. And I remember Andy Jassy said to me, one time, look, we love the ecosystem. We need the ecosystem. They have to innovate too. If they don't, you know, keep pace, you know, they're going to be in trouble. So that's actually a healthy kind of a dynamic, I mean, as an ecosystem partner, how do you, >>Well, I'll go back to one thing without the work that Google did to open source Kubernetes, a storm forge wouldn't exist, but without the effort that AWS and, and EKS in particular, um, provides and opens up for, for developers to, to innovate and to continue, continue kind of operationalizing the shift to Kubernetes, um, you know, we wouldn't have nearly the opportunity that we do to actually listen to them as well, listen to the users and be able to say, w w w what do you want, right. Our entire reason for existence comes from asking users, like, how painful is this process? Uh, like how much confidence do you have in the, you know, out of the box, defaults that ship with your, you know, with your database or whatever it is. And, uh, and, and how much do you love, uh, manually tuning your application? >>And, and, uh, obviously nobody's said, I love that. And so I think as that ecosystem comes together and continues expanding, um, it's just, it opens up a huge opportunity, uh, not only for existing, you know, EKS and, uh, AWS users to continue innovating, but for companies like storm forge, to be able to provide that opportunity for them as well. And, and that's pretty powerful. So I think without a lot of the moves they've made, um, you know, th the door wouldn't be nearly as open for companies like, who are, you know, growing quickly, but are smaller to be able to, you know, to exist. >>Well, and I was saying earlier that, that you've, you're in, I wrote about this, you're going to get better capabilities. You're clearly seeing that cluster management we've talked about better, better automation, security, the whole shift left movement. Um, so obviously there's a lot of momentum right now for Kubernetes. When you think about bare metal servers and storage, and then you had VM virtualization, VMware really, and then containers, and then Kubernetes as another abstraction, I would expect we're not at the end of the road here. Uh, what's next? Is there another abstraction layer that you would think is coming? Yeah, >>I mean, w for awhile, it looked like, and I remember even with our like board members and some of our investors said, well, you know, well, what about serverless? And, you know, what's the next Kubernetes and nothing, we, as much as I love Kubernetes, um, which I do, and we do, um, nothing about what we particularly do. We are purpose built for Kubernetes, but from a core kind of machine learning and problem solving standpoint, um, we could apply this elsewhere, uh, if we went that direction and so time will tell what will be next, then there will be something, uh, you know, that will end up, you know, expanding beyond Kubernetes at some point. Um, but, you know, I think, um, without knowing what that is, you know, our job is to, to, to serve our, you know, to serve our customers and serve our users in the way that they are asking for that. >>Well, serverless obviously is exploding when you look again, and we tucked the ETR survey data, when you look at, at the services within Amazon and other cloud providers, you know, the functions off, off the charts. Uh, so that's kind of an interesting and notable now, of course, you've got Chandler, you've got edge in your title. You've got hybrid in, in your title. So, you know, this notion of the cloud expanding, it's not just a set of remote services, just only in the public cloud. Now it's, it's coming to on premises. You actually got Andy, Jesse, my head space. He said, one time we just look at it. The data centers is another edge location. Right. Okay. That's a way to look at it and then you've got edge. Um, so that cloud is expanding, isn't it? The definition of cloud is, is, is evolving. >>Yeah, that's right. I mean, customers one-on-one run workloads in lots of places. Um, and that's why we have things like, you know, local zones and wavelengths and outposts and EKS anywhere, um, EKS, distro, and obviously probably lots more things to come. And there's, I always think of like, Amazon's Kubernetes strategy on a manageability scale. We're on one far end of the spectrum, you have EKS distro, which is just a collection of the core Kubernetes packages. And you could, you could take those and stand them up yourself in a broom closet, in a, in a retail shop. And then on the other far in the spectrum, you have EKS far gate where you can just give us your container and we'll handle everything for you. Um, and then we kind of tried to solve everything in between for your data center and for the cloud. And so you can, you can really ask Amazon, I want you to manage my control plane. I want you to manage this much of my worker nodes, et cetera. And oh, I actually want help on prem. And so we're just trying to listen to customers and solve their problems where they're asking us to solve them. Cut, >>Go ahead. No, I would just add that in a more vertically focused, uh, kind of orientation for us. Like we, we believe that op you know, optimization capabilities should transcend the location itself. And, and, and so whether that's part public part, private cloud, you know, that's what I love part of what I love about EKS anywhere. Uh, it, you know, you shouldn't, you should still be able to achieve optimal results that connect to your business objectives, uh, wherever those workloads, uh, are, are living >>Well, don't wince. So John and I coined this term called Supercloud and people laugh about it, but it's different. It's, it's, you know, people talk about multi-cloud, but that was just really kind of vendor diversity. Right? I got to running here, I'm running their money anywhere. Uh, but, but individually, and so Supercloud is this concept of this abstraction layer that floats wherever you are, whether it's on prem, across clouds, and you're taking advantage of those native primitives, um, and then hiding that underlying complexity. And that's what, w re-invent the ecosystem was so excited and they didn't call it super cloud. We, we, we called it that, but they're clearly thinking differently about the value that they can add on top of Goldman Sachs. Right. That to me is an example of a Supercloud they're taking their on-prem data and their, their, their software tooling connecting it to AWS. They're running it on AWS, but they're, they're abstracting that complexity. And I think you're going to see a lot, a lot more of that. >>Yeah. So Kubernetes itself, in many cases is being abstracted away. Yeah. There's a disability of a disappearing act for Kubernetes. And I don't mean that in a, you know, in an, a, from an adoption standpoint, but, uh, you know, Kubernetes itself is increasingly being abstracted away, which I think is, is actually super interesting. Yeah. >>Um, communities doesn't really do anything for a company. Like we run Kubernetes, like, how does that help your bottom line? That at the end of the day, like companies don't care that they're running Kubernetes, they're trying to solve a problem, which is the, I need to be able to deploy my applications. I need to be able to scale them easily. I need to be able to update them easily. And those are the things they're trying to solve. So if you can give them some other way to do that, I'm sure you know, that that's what they want. It's not like, uh, you know, uh, a big bank is making more money because they're running Kubernetes. That's not, that's not the current, >>It gets subsumed. It's just become invisible. Right. Exactly. You guys back to the office yet. What's, uh, what's the situation, >>You know, I, I work for my house and I, you know, we go into the office a couple of times a week, so it's, it's, uh, yeah, it's, it's, it's a crazy time. It's a crazy time to be managing and hiring. And, um, you know, it's, it's, it's, it's definitely a challenge, but there's a lot of benefits of working home. I got two young kids, so I get to see them, uh, grow up a little bit more working, working out of my house. So it's >>Nice also. >>So we're in, even as a smaller startup, we're in 26, 27 states, uh, Canada, Germany, we've got a little bit of presence in Japan, so we're very much distributed. Um, we, uh, have not gone back and I'm not sure we will >>Permanently remote potentially. >>Yeah. I mean, w we made a, uh, pretty like for us, the timing of our series B funding, which was where we started hiring a lot, uh, was just before COVID started really picking up. So we, you know, thankfully made a, a pretty good strategic decision to say, we're going to go where the talent is. And yeah, it was harder to find for sure, especially in w we're competing, it's incredibly competitive. Uh, but yeah, we've, it was a good decision for us. Um, we are very about, you know, getting the teams together in person, you know, as often as possible and in the safest way possible, obviously. Um, but you know, it's been a, it's been a pretty interesting, uh, journey for us and something that I'm, I'm not sure I would, I would change to be honest with you. Yeah. >>Well, Frank Slootman, snowflakes HQ to Montana, and then can folks like Michael Dell saying, Hey, same thing as you, wherever they want to work, bring yourself and wherever you are as cool. And do you think that the hybrid mode for your team is kind of the, the, the operating mode for the, for the foreseeable future is a couple of, >>No, I think, I think there's a lot of benefits in both working from the office. I don't think you can deny like the face-to-face interactions. It feels good just doing this interview face to face. Right. And I can see your mouth move. So it's like, there's a lot of benefits to that, um, over a chime call or a zoom call or whatever, you know, that, that also has advantages, right. I mean, you can be more focused at home. And I think some version of hybrid is probably in the industry's future. I don't know what Amazon's exact plans are. That's above my pay grade, but, um, I know that like in general, the industry is definitely moving to some kind of hybrid model. And like Matt said, getting people I'm a big fan at Mesa sphere, we ran a very diverse, like remote workforce. We had a big office in Germany, but we'd get everybody together a couple of times a year for engineering week or, or something like this. And you'd get a hundred people, you know, just dedicated to spending time together at a hotel and, you know, Vegas or Hamburg or wherever. And it's a really good time. And I think that's a good model. >>Yeah. And I think just more ETR data, the current thinking now is that, uh, the hybrid is the number one sort of model, uh, 36% that the CIO is believe 36% of the workforce are going to be hybrid permanently is kind of their, their call a couple of days in a couple of days out. Um, and the, the percentage that is remote is significantly higher. It probably, you know, high twenties, whereas historically it's probably 15%. Yeah. So permanent changes. And that, that changes the infrastructure. You need to support it, the security models and everything, you know, how you communicate. So >>When COVID, you know, really started hitting and in 2020, um, the big banks for example, had to, I mean, you would want to talk about innovation and ability to, to shift quickly. Two of the bigger banks that have in, uh, in fact, adopted Kubernetes, uh, were able to shift pretty quickly, you know, systems and things that were, you know, historically, you know, it was in the office all the time. And some of that's obviously shifted back to a certain degree, but that ability, it was pretty remarkable actually to see that, uh, take place for some of the larger banks and others that are operating in super regulated environments. I mean, we saw that in government agencies and stuff as well. >>Well, without the cloud, no, this never would've happened. Yeah. >>And I think it's funny. I remember some of the more old school manager thing people are, aren't gonna work less when they're working from home, they're gonna be distracted. I think you're seeing the opposite where people are too much, they get burned out because you're just running your computer all day. And so I think that we're learning, I think everyone, the whole industry is learning. Like, what does it mean to work from home really? And, uh, it's, it's a fascinating thing is as a case study, we're all a part of right now. >>I was talking to my wife last night about this, and she's very thoughtful. And she w when she was in the workforce, she was at a PR firm and a guy came in a guest speaker and it might even be in the CEO of the company asking, you know, what, on average, what time who stays at the office until, you know, who leaves by five o'clock, you know, a few hands up, or who stays until like eight o'clock, you know, and enhancement. And then, so he, and he asked those people, like, why, why can't you get your work done in a, in an eight hour Workday? I go home. Why don't you go in? And I sit there. Well, that's interesting, you know, cause he's always looking at me like, why can't you do, you know, get it done? And I'm saying the world has changed. Yeah. It really has where people are just on all the time. I'm not sure it's sustainable, quite frankly. I mean, I think that we have to, you know, as organizations think about, and I see companies doing it, you guys probably do as well, you know, take a four day, you know, a week weekend, um, just for your head. Um, but it's, there's no playbook. >>Yeah. Like I said, we're a part of a case study. It's also hard because people are distributed now. So you have your meetings on the east coast, you can wake up at seven four, and then you have meetings on the west coast. You stay until seven o'clock therefore, so your day just stretches out. So you've got to manage this. And I think we're, I think we'll figure it out. I mean, we're good at figuring this stuff. >>There's a rise in asynchronous communication. So with things like slack and other tools, as, as helpful as they are in many cases, it's a, it, isn't always on mentality. And like, people look for that little green dot and you know, if you're on the you're online. So my kids, uh, you know, we have a term now for me, cause my office at home is upstairs and I'll come down. And if it's, if it's during the day, they'll say, oh dad, you're going for a walk and talk, you know, which is like, it was my way of getting away from the desk, getting away from zoom. And like, you know, even in Boston, uh, you know, getting outside, trying to at least, you know, get a little exercise or walk and get, you know, get my head away from the computer screen. Um, but even then it's often like, oh, I'll get a slack notification on my phone or someone will call me even if it's not a scheduled walk and talk. Um, uh, and so it is an interesting, >>A lot of ways to get in touch or productivity is presumably going to go through the roof. But now, all right, guys, I'll let you go. Thanks so much for coming to the cube. Really appreciate it. And thank you for watching this cube conversation. This is Dave Alante and we'll see you next time.

>> From theCUBE studios in Palo Alto, in Boston, bringing you data driven insights from theCUBE and ETR. This is Breaking Analysis with Dave Vollante. >> The rise of Kubernetes came about through a combination of forces that were, in hindsight, quite a long shot. Amazon's dominance created momentum for Cloud native application development, and the need for newer and simpler experiences, beyond just easily spinning up computer as a service. This wave crashed into innovations from a startup named Docker, and a reluctant competitor in Google, that needed a way to change the game on Amazon and the Cloud. Now, add in the effort of Red Hat, which needed a new path beyond Enterprise Linux, and oh, by the way, it was just about to commit to a path of a Kubernetes alternative for OpenShift and figure out a governance structure to hurt all the cats and the ecosystem and you get the remarkable ascendancy of Kubernetes. Hello and welcome to this week's Wikibon CUBE Insights powered by ETR. In this breaking analysis, we tapped the back stories of a new documentary that explains the improbable events that led to the creation of Kubernetes. We'll share some new survey data from ETR and commentary from the many early the innovators who came on theCUBE during the exciting period since the founding of Docker in 2013, which marked a new era in computing, because we're talking about Kubernetes and developers today, the hoodie is on. And there's a new two part documentary that I just referenced, it's out and it was produced by Honeypot on Kubernetes, part one and part two, tells a story of how Kubernetes came to prominence and many of the players that made it happen. Now, a lot of these players, including Tim Hawkin Kelsey Hightower, Craig McLuckie, Joe Beda, Brian Grant Solomon Hykes, Jerry Chen and others came on theCUBE during formative years of containers going mainstream and the rise of Kubernetes. John Furrier and Stu Miniman were at the many shows we covered back then and they unpacked what was happening at the time. We'll share the commentary from the guests that they interviewed and try to add some context. Now let's start with the concept of developer defined structure, DDI. Jerry Chen was at VMware and he could see the trends that were evolving. He left VMware to become a venture capitalist at Greylock. Docker was his first investment. And he saw the future this way. >> What happens is when you define infrastructure software you can program it. You make it portable. And that the beauty of this cloud wave what I call DDI's. Now, to your point is every piece of infrastructure from storage, networking, to compute has an API, right? And, and AWS there was an early trend where S3, EBS, EC2 had API. >> As building blocks too. >> As building blocks, exactly. >> Not monolithic. >> Monolithic building blocks every little building bone block has it own API and just like Docker really is the API for this unit of the cloud enables developers to define how they want to build their applications, how to network them know as Wills talked about, and how you want to secure them and how you want to store them. And so the beauty of this generation is now developers are determining how apps are built, not just at the, you know, end user, you know, iPhone app layer the data layer, the storage layer, the networking layer. So every single level is being disrupted by this concept of a DDI and where, how you build use and actually purchase IT has changed. And you're seeing the incumbent vendors like Oracle, VMware Microsoft try to react but you're seeing a whole new generation startup. >> Now what Jerry was explaining is that this new abstraction layer that was being built here's some ETR data that quantifies that and shows where we are today. The chart shows net score or spending momentum on the vertical axis and market share which represents the pervasiveness in the survey set. So as Jerry and the innovators who created Docker saw the cloud was becoming prominent and you can see it still has spending velocity that's elevated above that 40% red line which is kind of a magic mark of momentum. And of course, it's very prominent on the X axis as well. And you see the low level infrastructure virtualization and that even floats above servers and storage and networking right. Back in 2013 the conversation with VMware. And by the way, I remember having this conversation deeply at the time with Chad Sakac was we're going to make this low level infrastructure invisible, and we intend to make virtualization invisible, IE simplified. And so, you see above the two arrows there related to containers, container orchestration and container platforms, which are abstraction layers and services above the underlying VMs and hardware. And you can see the momentum that they have right there with the cloud and AI and RPA. So you had these forces that Jerry described that were taking shape, and this picture kind of summarizes how they came together to form Kubernetes. And the upper left, Of course you see AWS and we inserted a picture from a post we did, right after the first reinvent in 2012, it was obvious to us at the time that the cloud gorilla was AWS and had all this momentum. Now, Solomon Hykes, the founder of Docker, you see there in the upper right. He saw the need to simplify the packaging of applications for cloud developers. Here's how he described it. Back in 2014 in theCUBE with John Furrier >> Container is a unit of deployment, right? It's the format in which you package your application all the files, all the executables libraries all the dependencies in one thing that you can move to any server and deploy in a repeatable way. So it's similar to how you would run an iOS app on an iPhone, for example. >> A Docker at the time was a 30% company and it just changed its name from .cloud. And back to the diagram you have Google with a red question mark. So why would you need more than what Docker had created. Craig McLuckie, who was a product manager at Google back then explains the need for yet another abstraction. >> We created the strong separation between infrastructure operations and application operations. And so, Docker has created a portable framework to take it, basically a binary and run it anywhere which is an amazing capability, but that's not enough. You also need to be able to manage that with a framework that can run anywhere. And so, the union of Docker and Kubernetes provides this framework where you're completely abstracted from the underlying infrastructure. You could use VMware, you could use Red Hat open stack deployment. You could run on another major cloud provider like rec. >> Now Google had this huge cloud infrastructure but no commercial cloud business compete with AWS. At least not one that was taken seriously at the time. So it needed a way to change the game. And it had this thing called Google Borg, which is a container management system and scheduler and Google looked at what was happening with virtualization and said, you know, we obviously could do better Joe Beda, who was with Google at the time explains their mindset going back to the beginning. >> Craig and I started up Google compute engine VM as a service. And the odd thing to recognize is that, nobody who had been in Google for a long time thought that there was anything to this VM stuff, right? Cause Google had been on containers for so long. That was their mindset board was the way that stuff was actually deployed. So, you know, my boss at the time, who's now at Cloudera booted up a VM for the first time, and anybody in the outside world be like, Hey, that's really cool. And his response was like, well now what? Right. You're sitting at a prompt. Like that's not super interesting. How do I run my app? Right. Which is, that's what everybody's been struggling with, with cloud is not how do I get a VM up? How do I actually run my code? >> Okay. So Google never really did virtualization. They were looking at the market and said, okay what can we do to make Google relevant in cloud. Here's Eric Brewer from Google. Talking on theCUBE about Google's thought process at the time. >> One interest things about Google is it essentially makes no use of virtual machines internally. And that's because Google started in 1998 which is the same year that VMware started was kind of brought the modern virtual machine to bear. And so Google infrastructure tends to be built really on kind of classic Unix processes and communication. And so scaling that up, you get a system that works a lot with just processes and containers. So kind of when I saw containers come along with Docker, we said, well, that's a good model for us. And we can take what we know internally which was called Borg a big scheduler. And we can turn that into Kubernetes and we'll open source it. And suddenly we have kind of a cloud version of Google that works the way we would like it to work. >> Now, Eric Brewer gave us the bumper sticker version of the story there. What he reveals in the documentary that I referenced earlier is that initially Google was like, why would we open source our secret sauce to help competitors? So folks like Tim Hockin and Brian Grant who were on the original Kubernetes team, went to management and pressed hard to convince them to bless open sourcing Kubernetes. Here's Hockin's explanation. >> When Docker landed, we saw the community building and building and building. I mean, that was a snowball of its own, right? And as it caught on we realized we know what this is going to we know once you embrace the Docker mindset that you very quickly need something to manage all of your Docker nodes, once you get beyond two or three of them, and we know how to build that, right? We got a ton of experience here. Like we went to our leadership and said, you know, please this is going to happen with us or without us. And I think it, the world would be better if we helped. >> So the open source strategy became more compelling as they studied the problem because it gave Google a way to neutralize AWS's advantage because with containers you could develop on AWS for example, and then run the application anywhere like Google's cloud. So it not only gave developers a path off of AWS. If Google could develop a strong service on GCP they could monetize that play. Now, focus your attention back to the diagram which shows this smiling, Alex Polvi from Core OS which was acquired by Red Hat in 2018. And he saw the need to bring Linux into the cloud. I mean, after all Linux was powering the internet it was the OS for enterprise apps. And he saw the need to extend its path into the cloud. Now here's how he described it at an OpenStack event in 2015. >> Similar to what happened with Linux. Like yes, there is still need for Linux and Windows and other OSs out there. But by and large on production, web infrastructure it's all Linux now. And you were able to get onto one stack. And how were you able to do that? It was, it was by having a truly open consistent API and a commitment into not breaking APIs and, so on. That allowed Linux to really become ubiquitous in the data center. Yes, there are other OSs, but Linux buy in large for production infrastructure, what is being used. And I think you'll see a similar phenomenon happen for this next level up cause we're treating the whole data center as a computer instead of trading one in visual instance is just the computer. And that's the stuff that Kubernetes to me and someone is doing. And I think there will be one that shakes out over time and we believe that'll be Kubernetes. >> So Alex saw the need for a dominant container orchestration platform. And you heard him, they made the right bet. It would be Kubernetes. Now Red Hat, Red Hat is been around since 1993. So it has a lot of on-prem. So it needed a future path to the cloud. So they rang up Google and said, hey. What do you guys have going on in this space? So Google, was kind of non-committal, but it did expose that they were thinking about doing something that was you know, pre Kubernetes. It was before it was called Kubernetes. But hey, we have this thing and we're thinking about open sourcing it, but Google's internal debates, and you know, some of the arm twisting from the engine engineers, it was taking too long. So Red Hat said, well, screw it. We got to move forward with OpenShift. So we'll do what Apple and Airbnb and Heroku are doing and we'll build on an alternative. And so they were ready to go with Mesos which was very much more sophisticated than Kubernetes at the time and much more mature, but then Google the last minute said, hey, let's do this. So Clayton Coleman with Red Hat, he was an architect. And he leaned in right away. He was one of the first outside committers outside of Google. But you still led these competing forces in the market. And internally there were debates. Do we go with simplicity or do we go with system scale? And Hen Goldberg from Google explains why they focus first on simplicity in getting that right. >> We had to defend of why we are only supporting 100 nodes in the first release of Kubernetes. And they explained that they know how to build for scale. They've done that. They know how to do it, but realistically most of users don't need large clusters. So why create this complexity? >> So Goldberg explains that rather than competing right away with say Mesos or Docker swarm, which were far more baked they made the bet to keep it simple and go for adoption and ubiquity, which obviously turned out to be the right choice. But the last piece of the puzzle was governance. Now Google promised to open source Kubernetes but when it started to open up to contributors outside of Google, the code was still controlled by Google and developers had to sign Google paper that said Google could still do whatever it wanted. It could sub license, et cetera. So Google had to pass the Baton to an independent entity and that's how CNCF was started. Kubernetes was its first project. And let's listen to Chris Aniszczyk of the CNCF explain >> CNCF is all about providing a neutral home for cloud native technology. And, you know, it's been about almost two years since our first board meeting. And the idea was, you know there's a certain set of technology out there, you know that are essentially microservice based that like live in containers that are essentially orchestrated by some process, right? That's essentially what we mean when we say cloud native right. And CNCF was seated with Kubernetes as its first project. And you know, as, as we've seen over the last couple years Kubernetes has grown, you know, quite well they have a large community a diverse con you know, contributor base and have done, you know, kind of extremely well. They're one of actually the fastest, you know highest velocity, open source projects out there, maybe. >> Okay. So this is how we got to where we are today. This ETR data shows container orchestration offerings. It's the same X Y graph that we showed earlier. And you can see where Kubernetes lands not we're standing that Kubernetes not a company but respondents, you know, they doing Kubernetes. They maybe don't know, you know, whose platform and it's hard with the ETR taxon economy as a fuzzy and survey data because Kubernetes is increasingly becoming embedded into cloud platforms. And IT pros, they may not even know which one specifically. And so the reason we've linked these two platforms Kubernetes and Red Hat OpenShift is because OpenShift right now is a dominant revenue player in the space and is increasingly popular PaaS layer. Yeah. You could download Kubernetes and do what you want with it. But if you're really building enterprise apps you're going to need support. And that's where OpenShift comes in. And there's not much data on this but we did find this chart from AMDA which show was the container software market, whatever that really is. And Red Hat has got 50% of it. This is revenue. And, you know, we know the muscle of IBM is behind OpenShift. So there's really not hard to believe. Now we've got some other data points that show how Kubernetes is becoming less visible and more embedded under of the hood. If you will, as this chart shows this is data from CNCF's annual survey they had 1800 respondents here, and the data showed that 79% of respondents use certified Kubernetes hosted platforms. Amazon elastic container service for Kubernetes was the most prominent 39% followed by Azure Kubernetes service at 23% in Azure AKS engine at 17%. With Google's GKE, Google Kubernetes engine behind those three. Now. You have to ask, okay, Google. Google's management Initially they had concerns. You know, why are we open sourcing such a key technology? And the premise was, it would level the playing field. And for sure it has, but you have to ask has it driven the monetization Google was after? And I would've to say no, it probably didn't. But think about where Google would've been. If it hadn't open source Kubernetes how relevant would it be in the cloud discussion. Despite its distant third position behind AWS and Microsoft or even fourth, if you include Alibaba without Kubernetes Google probably would be much less prominent or possibly even irrelevant in cloud, enterprise cloud. Okay. Let's wrap up with some comments on the state of Kubernetes and maybe a thought or two about, you know, where we're headed. So look, no shocker Kubernetes for all its improbable beginning has gone mainstream in the past year or so. We're seeing much more maturity and support for state full workloads and big ecosystem support with respect to better security and continued simplification. But you know, it's still pretty complex. It's getting better, but it's not VMware level of maturity. For example, of course. Now adoption has always been strong for Kubernetes, for cloud native companies who start with containers on day one, but we're seeing many more. IT organizations adopting Kubernetes as it matures. It's interesting, you know, Docker set out to be the system of the cloud and Kubernetes has really kind of become that. Docker desktop is where Docker's action really is. That's where Docker is thriving. It sold off Docker swarm to Mirantis has made some tweaks. Docker has made some tweaks to its licensing model to be able to continue to evolve its its business. To hear more about that at DockerCon. And as we said, years ago we expected Kubernetes to become less visible Stu Miniman and I talked about this in one of our predictions post and really become more embedded into other platforms. And that's exactly what's happening here but it's still complicated. Remember, remember the... Go back to the early and mid cycle of VMware understanding things like application performance you needed folks in lab coats to really remediate problems and dig in and peel the onion and scale the system you know, and in some ways you're seeing that dynamic repeated with Kubernetes, security performance scale recovery, when something goes wrong all are made more difficult by the rapid pace at which the ecosystem is evolving Kubernetes. But it's definitely headed in the right direction. So what's next for Kubernetes we would expect further simplification and you're going to see more abstractions. We live in this world of almost perpetual abstractions. Now, as Kubernetes improves support from multi cluster it will be begin to treat those clusters as a unified group. So kind of abstracting multiple clusters and treating them as, as one to be managed together. And this is going to create a lot of ecosystem focus on scaling globally. Okay, once you do that, you're going to have to worry about latency and then you're going to have to keep pace with security as you expand the, the threat area. And then of course recovery what happens when something goes wrong, more complexity, the harder it is to recover and that's going to require new services to share resources across clusters. So look for that. You also should expect more automation. It's going to be driven by the host cloud providers as Kubernetes supports more state full applications and begins to extend its cluster management. Cloud providers will inject as much automation as possible into the system. Now and finally, as these capabilities mature we would expect to see better support for data intensive workloads like, AI and Machine learning and inference. Schedule with these workloads becomes harder because they're so resource intensive and performance management becomes more complex. So that's going to have to evolve. I mean, frankly, many of the things that Kubernetes team way back when, you know they back burn it early on, for example, you saw in Docker swarm or Mesos they're going to start to enter the scene now with Kubernetes as they start to sort of prioritize some of those more complex functions. Now, the last thing I'll ask you to think about is what's next beyond Kubernetes, you know this isn't it right with serverless and IOT in the edge and new data, heavy workloads there's something that's going to disrupt Kubernetes. So in that, by the way, in that CNCF survey nearly 40% of respondents were using serverless and that's going to keep growing. So how is that going to change the development model? You know, Andy Jassy once famously said that if they had to start over with Amazon retail, they'd start with serverless. So let's keep an eye on the horizon to see what's coming next. All right, that's it for now. I want to thank my colleagues, Stephanie Chan who helped research this week's topics and Alex Myerson on the production team, who also manages the breaking analysis podcast, Kristin Martin and Cheryl Knight help get the word out on socials, so thanks to all of you. Remember these episodes, they're all available as podcasts wherever you listen, just search breaking analysis podcast. Don't forget to check out ETR website @etr.ai. We'll also publish. We publish a full report every week on wikibon.com and Silicon angle.com. You can get in touch with me, email me directly david.villane@Siliconangle.com or DM me at D Vollante. You can comment on our LinkedIn post. This is Dave Vollante for theCUBE insights powered by ETR. Have a great week, everybody. Thanks for watching. Stay safe, be well. And we'll see you next time. (upbeat music)

(upbeat music) Welcome back to theCUBE's coverage of AWS re:Invent 2021. I'm John Furrier, host of theCUBE. We have George Watkins, the product marketing manager, cloud gaming and visual cloud at AMD. George, thanks for coming on theCUBE. >> Thank you for having me. >> Love this segment, accelerating game development. AWS cloud, big topic on how the gaming developer environment's changing and how AMD is powering it. Let's get into it. So streaming remote, working remote, flexible collaboration, all powered by the G4ad virtual workstations, it's been a big part of success. Take us through what's going on there. >> Yeah, certainly. So obviously from a remote working perspective, there was a huge impact on collaboration and productivity for many industries out there. But, a collaborative environment like game design, it was even more so. First off, happy to have these big bulky workstation ship to local artists, so they can actually carry on working was a massive nightmare for IT management. Making sure that they have the right hardware, the right resources, the right applications and security. So it was a real mean task. And on top of that, working remotely also brings in other efficiencies when it comes to collaboration. So for example, working on a data sets, as I mentioned before, it's a huge team collaboration effort when it comes to game development, and using the same dataset happens very very often. So if you're actually working remotely and an artist, for example pulled a dataset, from a server, worked on it, then took it back up into the cloud. I'll tell you now, it takes some time to do. And at the same time you might have one or two other artists trying to use that data set. The problem or the big issue that comes here is version control. And essentially because these artists are using the older version, there's creating errors, and keeping that production timed longer. So it's very very inefficient. And then this is where the cloud really comes to end zone. First off the cloud, and then obviously in this case, the AWS cloud, with G4ad instances, really does bring the whole pipeline together. It brings the data sets and the virtual workstations, obviously, as I mentioned, G4ad, as well as all the applications into one place. It's all centralized. And from an IT perspective, this is fantastic. And actually sending out a workstation now is really really simple. It's log in details into an email to your new staff, and there's some really great benefits as well from a staff perspective. Not only are they not tethered to a local workstation, they have the flexibility of work where they need to, and also how they like to. But it's also really interesting about how they work on a day-to-day basis. So a good example of this is, if a artist is using or working on a very very heavy dataset and the configuration from their VM or virtual workstation, isn't up to snuff because of the such a large dataset, all they need to do is call up IT and say, I need more resource. And literally in a couple of minutes time, they can actually have that resource, again, improving that productivity, reducing that time. So it's really really important. And just a final note here as well, with having all that data and all that resource in the cloud, version control tools, really do help bring that efficiency as it's all built into the applications and that data sets really, really exciting staff and ultimately, bring in that productivity and reducing that time and errors down. >> I could see your point too because, when you don't bring it to the cloud, people are going to be bored, waiting for things to happen. And they say I want to take a shortcut. Shortcuts equal mistakes. So, I can see that the G4ad with focus for artists is cool because it's purpose-built for what you're talking about. So take me through how you see the improved efficiencies in the development pipeline with cloud computing around this area because, obviously it makes a lot of sense. Everything's in the cloud, you've got the instances there. Now what happens next? How does the coding all work? What's going on around the game development pipeline? >> 3D applications today, particularly at use in the game industry, I'll be honest, they are still based on legacy hardware. And what I mean by this is that the applications typically require higher CPU Hertz the typically single threaded, maybe some kind of multi threaded functionality there. But generally they are limited by what the traditional workstation has been. And obviously why not? They've been built over the last 10-15 years to access that type of data. Now that is great, but it's not accessing what could be, all the resources that are available in the cloud. And this is what's really really exciting in my part. So ultimately what we're saying is that is that you have this great virtual workstation experience. You have all your applications running on there, you can be efficient, but then there's these really specific and really interesting use cases that aren't accessing the cloud. And I've got a couple of examples, so first off there's a feature inside Unreal 4 engine, called Unreal Swarm. And this feature helps actually reduce the time it takes, in this case and to bake light maps into auto scale, to bake light maps into a game. And this is done by auto scaling, the compiling in AWS cloud. So for example, after making the amends to a light map, we're ready to essentially recompile, but instead of doing this on the local workstation, using the traditional CPU and memory resource, which you would expect to see in a workstation, and actually in this case, it takes around about 50 minutes to do. When you actually use Unreal Swarm, you can, the coordinator as part of this functionality, bursts the requirement or the actual compiling into the cloud. And actually in this case, it's using, like, 10 C5a instances. So these are all CPU high-performance computing instances. And because you have this ability to auto-scale, you actually essentially bring that time, that original 50 minutes, down to 4 minutes. And this type of kind of functionality or this type of task that you would typically see with a 3d artist or with a programmer, basically happens multiple times a day. So when you start factoring in a saving of 45 minutes multiple times a day, it starts really bringing down, the amount of time saved, and obviously the amount of cost saved as well for that artist's time. So it's really really exciting and, certainly something to talk about. >> That's totally cool. I got to ask you since you're here, because it brings up the question that pops into my head, which is okay. What's the state of the art development trends that you're seeing because, on the cloud side, on non gaming world, so shift left to security. You start to see more agile kind of methods around what used to be different modules, right? So you mentioned compiling, acceleration, what's going on in the actual workflows for the developers? What are some of the cool things that you could share that people might not know about that are important? >> Well certainly it's really about finding, those bursty computational expensive and time consuming processes, and actually moving them to the cloud. So really, from a compiling standpoint, they are usually CPU bound. So essentially the GPU does all the work when it comes to the view pole, all that high rendering frames per second, that's what it's really designed for. And it does a very good job with that. But actually the compiling aspect, the compute aspect is all done on the CPU side. And, the work that we've been doing with AWS and the game tech team is actually finding certain ways of actually helping to reduce the compiling nature because ultimately that is always restricted by the amount of calls that you actually have on a local device. So again, another example is there's a company out there called Incredibuild, and they specialize in accelerating the development of that programming code. And obviously in this case, it's the game code. And if an artist, entered a clean source code built on unreal engine full, it would take approximately around about 60 minutes to do on a local machine. However, using the Incredibuild solution to accelerate that type of workload, you can complete it in just 6 minutes. Because again, it's auto scaled out that compiling to several in this case 16 C5a large instances, which essentially reduces all that time for the artist freeing them up to do more stuff. >> And the more creativity is just the classic use case of the clouds, beautiful thing. It's just reminds me of how good this is, because, when you think about what you guys are doing, pushing the envelope for cloud with the creators. gaming is such a state-of-the-art pressure point to make high performance come better. It really is putting a lot of pressure on AMD and everyone else's to get faster and stronger because, it truly is pushing state-of-the-art in general. It's always been that way. If you look at the gaming world. This is a whole 'nother level. I mean, you starting to see that. What's your view on that? If you look at the gaming as a tail sign for the trends and the tech side, better, faster, cheaper processors and speeds and feeds, and how codes work in between processes GPU's and CPU's, all this is cool. All kind of new, if you will. New patterns, new usage, what's your view on that? >> Well certainly, cloud gaming is a really exciting topic and, we believe that cloud gaming with the introduction of various key elements are reading revolutionalize the way that some people are actually using their complaint gamings and interacting with games. And what I mean by this is like, today we can do cloud gaming, it's a fantastic experience. You're usually hardwired, using a broadband connection to actually play those games. And you tend to try and be close to an actual data sensors, to try to reduce that latency. However this is only going to get better with the introduction of 5G coverage and also just, as important edge computing. And because of these two elements, what we're going to be seeing is very high speeds wirelessly, and more importantly, low latency. And this is very important for, that very dynamic cinematic gaming experiences. But not only this, what it can actually do is bring, 4k, 8K gaming to people wirelessly. It can also bring VR and AR experiences wirelessly, and also it can access, these new emerging technologies that are making higher fidelity gaming experiences like hardware retraces. All this can be done with these new technologies. And it's incredibly incredibly exciting. But more importantly, what's really great about this is, from a game publisher perspective, because it's actually helping them simplify their business processes, particularly from a game development standpoint. And actually what I mean by this is, if we take a typical example of what a game developer has to do for a mobile game, there's certain considerations that they need to think about when they actually comes to developing and validate. First off they'll have to understand what type of OS to account for. And actually what type of version of that OS to account for. What type of IPA they're going to be building on. And also finally, what type of resources, are actually on that end point device. So there's a lot of considerations here, and a lot of testing. So ultimately a lot of work to get that game out, to those gamers who might be on a couple of these different mobile platforms. However, when it comes to game streaming, it really does kind of change all this because ultimately what the game developer is actually doing is that they're developing and they're validating on one source. And that is going to be the server that is essentially pairing that game streaming service. Because how game streaming works is that we essentially trans code the actual game via H.264 to a software client on any end point device. So this could be those mobile devices I just mentioned. It can also be TVs, it could be consoles, it can be even low powered laptops. And what's very exciting is that, from an end user perspective, they're getting the ultimate in gaming experiences and usually these types of solutions are traditionally subscription-based. So you're actually reducing the requirement of this kind of high-end thousands of dollars gaming solution or simply a high-end next gen console. All of this is actually been given to you and delivered as part of a game streaming service. So it's very very exciting and, certainly we can see the adoption on both the game development side, as well as the gamer's side. That's a great way to put an end to this awesome segment. I think that business model innovation around making it easier, and making it better to develop environment, that's just how they work. So that's good, check. But really the business model here, the gaming as a service, you're making it possible for the developer and the artist to see an outcome faster. That's the cloud way. >> Thank you >> And they doubled down on success and they could do that. So again, this is all new and exciting and certainly the edge and having data being processed at the edge as well. Again, all this is coming in to create more good choice. Thank you so much for coming on and sharing that insight with us from the AMD perspective. And again, more power, more speed, we always say, no one's going to complain, they get more compute, that's what I always. >> Absolutely absolutely. >> Thanks for coming I appreciate it. >> Thank you. >> theCUBE coverage here at AWS re:Invent 2021. I'm John Furrier host of theCUBE. Thanks for watching. (upbeat music)

(upbeat music) >> Welcome back to HPE Discover 2021, theCUBE's virtual coverage, continuous coverage of HPE's Annual Customer Event. My name is Dave Vellante, and we're going to dive into the intersection of high-performance computing, data and AI with Doctor Eng Lim Goh, who's a Senior Vice President and CTO for AI at Hewlett Packard Enterprise. Doctor Goh, great to see you again. Welcome back to theCUBE. >> Hello, Dave, great to talk to you again. >> You might remember last year we talked a lot about Swarm intelligence and how AI is evolving. Of course, you hosted the Day 2 Keynotes here at Discover. And you talked about thriving in the age of insights, and how to craft a data-centric strategy. And you addressed some of the biggest problems, I think organizations face with data. That's, you've got a, data is plentiful, but insights, they're harder to come by. >> Yeah. >> And you really dug into some great examples in retail, banking, in medicine, healthcare and media. But stepping back a little bit we zoomed out on Discover '21. What do you make of the events so far and some of your big takeaways? >> Hmm, well, we started with the insightful question, right, yeah? Data is everywhere then, but we lack the insight. That's also part of the reason why, that's a main reason why Antonio on day one focused and talked about the fact that we are in the now in the age of insight, right? And how to try thrive in that age, in this new age? What I then did on a Day 2 Keynote following Antonio is to talk about the challenges that we need to overcome in order to thrive in this new age. >> So, maybe we could talk a little bit about some of the things that you took away in terms of, I'm specifically interested in some of the barriers to achieving insights. You know customers are drowning in data. What do you hear from customers? What were your takeaway from some of the ones you talked about today? >> Oh, very pertinent question, Dave. You know the two challenges I spoke about, that we need to overcome in order to thrive in this new age. The first one is the current challenge. And that current challenge is, you know, stated is now barriers to insight, when we are awash with data. So that's a statement on how do you overcome those barriers? What are the barriers to insight when we are awash in data? In the Day 2 Keynote, I spoke about three main things. Three main areas that we receive from customers. The first one, the first barrier is in many, with many of our customers, data is siloed, all right. You know, like in a big corporation, you've got data siloed by sales, finance, engineering, manufacturing and so on supply chain and so on. And there's a major effort ongoing in many corporations to build a federation layer above all those silos so that when you build applications above, they can be more intelligent. They can have access to all the different silos of data to get better intelligence and more intelligent applications built. So that was the first barrier we spoke about, you know? Barriers to insight when we are awash with data. The second barrier is that we see amongst our customers is that data is raw and disperse when they are stored. And you know, it's tough to get at, to tough to get a value out of them, right? And in that case, I use the example of, you know, the May 6, 2010 event where the stock market dropped a trillion dollars in terms of minutes. We all know those who are financially attuned with know about this incident but that this is not the only incident. There are many of them out there. And for that particular May 6 event, you know, it took a long time to get insight. Months, yeah, before we, for months we had no insight as to what happened. Why it happened? Right, and there were many other incidences like this and the regulators were looking for that one rule that could mitigate many of these incidences. One of our customers decided to take the hard road they go with the tough data, right? Because data is raw and dispersed. So they went into all the different feeds of financial transaction information, took the tough, you know, took a tough road. And analyze that data took a long time to assemble. And they discovered that there was caught stuffing, right? That people were sending a lot of trades in and then canceling them almost immediately. You have to manipulate the market. And why didn't we see it immediately? Well, the reason is the process reports that everybody sees, the rule in there that says, all trades less than a hundred shares don't need to report in there. And so what people did was sending a lot of less than a hundred shares trades to fly under the radar to do this manipulation. So here is the second barrier, right? Data could be raw and dispersed. Sometimes it's just have to take the hard road and to get insight. And this is one great example. And then the last barrier has to do with sometimes when you start a project to get insight, to get answers and insight, you realize that all the data's around you, but you don't seem to find the right ones to get what you need. You don't seem to get the right ones, yeah? Here we have three quick examples of customers. One was a great example, right? Where they were trying to build a language translator or machine language translator between two languages, right? By not do that, they need to get hundreds of millions of word pairs. You know of one language compare with the corresponding other. Hundreds of millions of them. They say, well, I'm going to get all these word pairs. Someone creative thought of a willing source and a huge, it was a United Nations. You see? So sometimes you think you don't have the right data with you, but there might be another source and a willing one that could give you that data, right? The second one has to do with, there was the sometimes you may just have to generate that data. Interesting one, we had an autonomous car customer that collects all these data from their their cars, right? Massive amounts of data, lots of sensors, collect lots of data. And, you know, but sometimes they don't have the data they need even after collection. For example, they may have collected the data with a car in fine weather and collected the car driving on this highway in rain and also in snow. But never had the opportunity to collect the car in hill because that's a rare occurrence. So instead of waiting for a time where the car can drive in hill, they build a simulation by having the car collected in snow and simulated him. So these are some of the examples where we have customers working to overcome barriers, right? You have barriers that is associated. In fact, that data silo, they federated it. Virus associated with data, that's tough to get at. They just took the hard road, right? And sometimes thirdly, you just have to be creative to get the right data you need. >> Wow! I tell you, I have about a hundred questions based on what you just said, you know? (Dave chuckles) And as a great example, the Flash Crash. In fact, Michael Lewis, wrote about this in his book, the Flash Boys. And essentially, right, it was high frequency traders trying to front run the market and sending into small block trades (Dave chuckles) trying to get sort of front ended. So that's, and they chalked it up to a glitch. Like you said, for months, nobody really knew what it was. So technology got us into this problem. (Dave chuckles) I guess my question is can technology help us get out of the problem? And that maybe is where AI fits in? >> Yes, yes. In fact, a lot of analytics work went in to go back to the raw data that is highly dispersed from different sources, right? Assembled them to see if you can find a material trend, right? You can see lots of trends, right? Like, no, we, if humans look at things that we tend to see patterns in Clouds, right? So sometimes you need to apply statistical analysis math to be sure that what the model is seeing is real, right? And that required, well, that's one area. The second area is you know, when this, there are times when you just need to go through that tough approach to find the answer. Now, the issue comes to mind now is that humans put in the rules to decide what goes into a report that everybody sees. Now, in this case, before the change in the rules, right? But by the way, after the discovery, the authorities changed the rules and all shares, all trades of different any sizes it has to be reported. >> Right. >> Right, yeah? But the rule was applied, you know, I say earlier that shares under a hundred, trades under a hundred shares need not be reported. So, sometimes you just have to understand that reports were decided by humans and for understandable reasons. I mean, they probably didn't wanted a various reasons not to put everything in there. So that people could still read it in a reasonable amount of time. But we need to understand that rules were being put in by humans for the reports we read. And as such, there are times we just need to go back to the raw data. >> I want to ask you... >> Oh, it could be, that it's going to be tough, yeah. >> Yeah, I want to ask you a question about AI as obviously it's in your title and it's something you know a lot about but. And I'm going to make a statement, you tell me if it's on point or off point. So seems that most of the AI going on in the enterprise is modeling data science applied to, you know, troves of data. But there's also a lot of AI going on in consumer. Whether it's, you know, fingerprint technology or facial recognition or natural language processing. Well, two part question will the consumer market, as it has so often in the enterprise sort of inform us is sort of first part. And then, there'll be a shift from sort of modeling if you will to more, you mentioned the autonomous vehicles, more AI inferencing in real time, especially with the Edge. Could you help us understand that better? >> Yeah, this is a great question, right? There are three stages to just simplify. I mean, you know, it's probably more sophisticated than that. But let's just simplify that three stages, right? To building an AI system that ultimately can predict, make a prediction, right? Or to assist you in decision-making. I have an outcome. So you start with the data, massive amounts of data that you have to decide what to feed the machine with. So you feed the machine with this massive chunk of data, and the machine starts to evolve a model based on all the data it's seeing. It starts to evolve, right? To a point that using a test set of data that you have separately kept aside that you know the answer for. Then you test the model, you know? After you've trained it with all that data to see whether its prediction accuracy is high enough. And once you are satisfied with it, you then deploy the model to make the decision. And that's the inference, right? So a lot of times, depending on what we are focusing on, we in data science are, are we working hard on assembling the right data to feed the machine with? That's the data preparation organization work. And then after which you build your models you have to pick the right models for the decisions and prediction you need to make. You pick the right models. And then you start feeding the data with it. Sometimes you pick one model and a prediction isn't that robust. It is good, but then it is not consistent, right? Now what you do is you try another model. So sometimes it gets keep trying different models until you get the right kind, yeah? That gives you a good robust decision-making and prediction. Now, after which, if it's tested well, QA, you will then take that model and deploy it at the Edge. Yeah, and then at the Edge is essentially just looking at new data, applying it to the model that you have trained. And then that model will give you a prediction or a decision, right? So it is these three stages, yeah. But more and more, your question reminds me that more and more people are thinking as the Edge become more and more powerful. Can you also do learning at the Edge? >> Right. >> That's the reason why we spoke about Swarm Learning the last time. Learning at the Edge as a Swarm, right? Because maybe individually, they may not have enough power to do so. But as a Swarm, they may. >> Is that learning from the Edge or learning at the Edge? In other words, is that... >> Yes. >> Yeah. You do understand my question. >> Yes. >> Yeah. (Dave chuckles) >> That's a great question. That's a great question, right? So the quick answer is learning at the Edge, right? And also from the Edge, but the main goal, right? The goal is to learn at the Edge so that you don't have to move the data that Edge sees first back to the Cloud or the Call to do the learning. Because that would be the reason, one of the main reasons why you want to learn at the Edge. Right? So that you don't need to have to send all that data back and assemble it back from all the different Edge devices. Assemble it back to the Cloud Site to do the learning, right? Some on you can learn it and keep the data at the Edge and learn at that point, yeah. >> And then maybe only selectively send. >> Yeah. >> The autonomous vehicle, example you gave is great. 'Cause maybe they're, you know, there may be only persisting. They're not persisting data that is an inclement weather, or when a deer runs across the front. And then maybe they do that and then they send that smaller data setback and maybe that's where it's modeling done but the rest can be done at the Edge. It's a new world that's coming through. Let me ask you a question. Is there a limit to what data should be collected and how it should be collected? >> That's a great question again, yeah. Well, today full of these insightful questions. (Dr. Eng chuckles) That actually touches on the the second challenge, right? How do we, in order to thrive in this new age of insight? The second challenge is our future challenge, right? What do we do for our future? And in there is the statement we make is we have to focus on collecting data strategically for the future of our enterprise. And within that, I talked about what to collect, right? When to organize it when you collect? And then where will your data be going forward that you are collecting from? So what, when, and where? For what data to collect? That was the question you asked, it's a question that different industries have to ask themselves because it will vary, right? Let me give you the, you use the autonomous car example. Let me use that. And we do have this customer collecting massive amounts of data. You know, we're talking about 10 petabytes a day from a fleet of their cars. And these are not production autonomous cars, right? These are training autonomous cars, collecting data so they can train and eventually deploy commercial cars, right? Also this data collection cars, they collect 10, as a fleet of them collect 10 petabytes a day. And then when they came to us, building a storage system you know, to store all of that data, they realized they don't want to afford to store all of it. Now here comes the dilemma, right? What should I, after I spent so much effort building all this cars and sensors and collecting data, I've now decide what to delete. That's a dilemma, right? Now in working with them on this process of trimming down what they collected, you know, I'm constantly reminded of the 60s and 70s, right? To remind myself 60s and 70s, we called a large part of our DNA, junk DNA. >> Yeah. (Dave chuckles) >> Ah! Today, we realized that a large part of that what we call junk has function as valuable function. They are not genes but they regulate the function of genes. You know? So what's junk in yesterday could be valuable today. Or what's junk today could be valuable tomorrow, right? So, there's this tension going on, right? Between you deciding not wanting to afford to store everything that you can get your hands on. But on the other hand, you worry, you ignore the wrong ones, right? You can see this tension in our customers, right? And then it depends on industry here, right? In healthcare they say, I have no choice. I want it all, right? Oh, one very insightful point brought up by one healthcare provider that really touched me was you know, we don't only care. Of course we care a lot. We care a lot about the people we are caring for, right? But who also care for the people we are not caring for? How do we find them? >> Uh-huh. >> Right, and that definitely, they did not just need to collect data that they have with from their patients. They also need to reach out, right? To outside data so that they can figure out who they are not caring for, right? So they want it all. So I asked them, so what do you do with funding if you want it all? They say they have no choice but to figure out a way to fund it and perhaps monetization of what they have now is the way to come around and fund that. Of course, they also come back to us rightfully, that you know we have to then work out a way to help them build a system, you know? So that's healthcare, right? And if you go to other industries like banking, they say they can afford to keep them all. >> Yeah. >> But they are regulated, seemed like healthcare, they are regulated as to privacy and such like. So many examples different industries having different needs but different approaches to what they collect. But there is this constant tension between you perhaps deciding not wanting to fund all of that, all that you can install, right? But on the other hand, you know if you kind of don't want to afford it and decide not to start some. Maybe those some become highly valuable in the future, right? (Dr. Eng chuckles) You worry. >> Well, we can make some assumptions about the future. Can't we? I mean, we know there's going to be a lot more data than we've ever seen before. We know that. We know, well, not withstanding supply constraints and things like NAND. We know the prices of storage is going to continue to decline. We also know and not a lot of people are really talking about this, but the processing power, but the says, Moore's law is dead. Okay, it's waning, but the processing power when you combine the CPUs and NPUs, and GPUs and accelerators and so forth actually is increasing. And so when you think about these use cases at the Edge you're going to have much more processing power. You're going to have cheaper storage and it's going to be less expensive processing. And so as an AI practitioner, what can you do with that? >> Yeah, it's a highly, again, another insightful question that we touched on our Keynote. And that goes up to the why, uh, to the where? Where will your data be? Right? We have one estimate that says that by next year there will be 55 billion connected devices out there, right? 55 billion, right? What's the population of the world? Well, of the other 10 billion? But this thing is 55 billion. (Dave chuckles) Right? And many of them, most of them can collect data. So what do you do? Right? So the amount of data that's going to come in, it's going to way exceed, right? Drop in storage costs are increasing compute power. >> Right. >> Right. So what's the answer, right? So the answer must be knowing that we don't, and even a drop in price and increase in bandwidth, it will overwhelm the, 5G, it will overwhelm 5G, right? Given the amount of 55 billion of them collecting. So the answer must be that there needs to be a balance between you needing to bring all of that data from the 55 billion devices of the data back to a central, as a bunch of central cost. Because you may not be able to afford to do that. Firstly bandwidth, even with 5G and as the, when you'll still be too expensive given the number of devices out there. You know given storage costs dropping is still be too expensive to try and install them all. So the answer must be to start, at least to mitigate from to, some leave most a lot of the data out there, right? And only send back the pertinent ones, as you said before. But then if you did that then how are we going to do machine learning at the Core and the Cloud Site, if you don't have all the data? You want rich data to train with, right? Sometimes you want to mix up the positive type data and the negative type data. So you can train the machine in a more balanced way. So the answer must be eventually, right? As we move forward with these huge number of devices all at the Edge to do machine learning at the Edge. Today we don't even have power, right? The Edge typically is characterized by a lower energy capability and therefore lower compute power. But soon, you know? Even with low energy, they can do more with compute power improving in energy efficiency, right? So learning at the Edge, today we do inference at the Edge. So we data, model, deploy and you do inference there is. That's what we do today. But more and more, I believe given a massive amount of data at the Edge, you have to start doing machine learning at the Edge. And when you don't have enough power then you aggregate multiple devices, compute power into a Swarm and learn as a Swarm, yeah. >> Oh, interesting. So now of course, if I were sitting and fly on the wall and the HPE board meeting I said, okay, HPE is a leading provider of compute. How do you take advantage of that? I mean, we're going, I know it's future but you must be thinking about that and participating in those markets. I know today you are, you have, you know, Edge line and other products. But there's, it seems to me that it's not the general purpose that we've known in the past. It's a new type of specialized computing. How are you thinking about participating in that opportunity for the customers? >> Hmm, the wall will have to have a balance, right? Where today the default, well, the more common mode is to collect the data from the Edge and train at some centralized location or number of centralized location. Going forward, given the proliferation of the Edge devices, we'll need a balance, we need both. We need capability at the Cloud Site, right? And it has to be hybrid. And then we need capability on the Edge side that we need to build systems that on one hand is an Edge adapter, right? Meaning they environmentally adapted because the Edge differently are on it, a lot of times on the outside. They need to be packaging adapted and also power adapted, right? Because typically many of these devices are battery powered. Right? So you have to build systems that adapts to it. But at the same time, they must not be custom. That's my belief. It must be using standard processes and standard operating system so that they can run a rich set of applications. So yes, that's also the insight for that Antonio announced in 2018. For the next four years from 2018, right? $4 billion invested to strengthen our Edge portfolio. >> Uh-huh. >> Edge product lines. >> Right. >> Uh-huh, Edge solutions. >> I could, Doctor Goh, I could go on for hours with you. You're just such a great guest. Let's close. What are you most excited about in the future of, certainly HPE, but the industry in general? >> Yeah, I think the excitement is the customers, right? The diversity of customers and the diversity in the way they have approached different problems of data strategy. So the excitement is around data strategy, right? Just like, you know, the statement made for us was so was profound, right? And Antonio said, we are in the age of insight powered by data. That's the first line, right? The line that comes after that is as such we are becoming more and more data centric with data that currency. Now the next step is even more profound. That is, you know, we are going as far as saying that, you know, data should not be treated as cost anymore. No, right? But instead as an investment in a new asset class called data with value on our balance sheet. This is a step change, right? Right, in thinking that is going to change the way we look at data, the way we value it. So that's a statement. (Dr. Eng chuckles) This is the exciting thing, because for me a CTO of AI, right? A machine is only as intelligent as the data you feed it with. Data is a source of the machine learning to be intelligent. Right? (Dr. Eng chuckles) So, that's why when the people start to value data, right? And say that it is an investment when we collect it it is very positive for AI. Because an AI system gets intelligent, get more intelligence because it has huge amounts of data and a diversity of data. >> Yeah. >> So it'd be great, if the community values data. >> Well, you certainly see it in the valuations of many companies these days. And I think increasingly you see it on the income statement. You know data products and people monetizing data services. And yeah, maybe eventually you'll see it in the balance sheet. I know Doug Laney, when he was at Gartner Group, wrote a book about this and a lot of people are thinking about it. That's a big change, isn't it? >> Yeah, yeah. >> Dr. Goh... (Dave chuckles) >> The question is the process and methods in valuation. Right? >> Yeah, right. >> But I believe we will get there. We need to get started. And then we'll get there. I believe, yeah. >> Doctor Goh, it's always my pleasure. >> And then the AI will benefit greatly from it. >> Oh, yeah, no doubt. People will better understand how to align, you know some of these technology investments. Dr. Goh, great to see you again. Thanks so much for coming back in theCUBE. It's been a real pleasure. >> Yes, a system is only as smart as the data you feed it with. (Dave chuckles) (Dr. Eng laughs) >> Excellent. We'll leave it there. Thank you for spending some time with us and keep it right there for more great interviews from HPE Discover 21. This is Dave Vellante for theCUBE, the leader in Enterprise Tech Coverage. We'll be right back. (upbeat music)

>>Welcome back to Vienna on 2021 you're watching the Cube and my name is Dave Volonte. You know, the last 10 years of cloud, they were largely about spinning up virtualized compute infrastructure and accessing cheap and simple object storage and some other things like networking. The cloud was largely though a set of remote resources that simplify deployment and supported the whole spate of native applications that have emerged to power the activity of individuals and businesses the next decade, however, promises to build on the troves of data that live in the cloud, make connections to on premises applications and support new application innovations that are agile, iterative, portable and span resources in all in all the clouds, public clouds, private clouds, cross cloud connections all the way out to the near and far edge. In a linchpin of this new application development model is container platforms and container orchestration, which brings immense scale and capability to technology driven organizations, especially as they have evolved from supporting stateless applications to underpinning mission critical workloads as such containers bring complexities and risks that need to be addressed, not the least of which is protecting the massive amounts of data that are flowing through these systems. And with me to discuss these exciting and challenging trends or Danny Allen, who's the ceo of in and Niraj Tolia, the president at Kasten Bivins gentlemen welcome to the cube. >>Thank you delighted to be here with you Dave. >>Likewise, very excited to be a Dave. >>Okay, so Danny big M and a move. Great little acquisition. You're now seeing others try to make similar moves. Why what did you see in cast in? What was the fit? Why'd you make that move? >>Well, I think you nailed it. Dave's. We've seen an evolution in the infrastructure that's being used over the last two decades. So if you go back 20 years, there was a massive digital transformation to enable users to be self service with digital applications. About 2000 or so, 2010, everything started being virtualized. I know virtualization came along before that but virtualization really started to take off because it gave return on investment and gave flexibility all kinds of benefits. But now we're in a third wave which is built on containers. And the amazing thing about containers is that as you said, it allows you to connect multi cloud, hybrid cloud the edge to the core. And they're designed for the consumption world. If you think about the cloud, you can provision things deep provisions things. That's the way that containers are designed the applications and so because they're designed for a consumption based world because they are designed for portability across all of these different infrastructures, it only made sense for us to invest in the industry's leading provider of data protection for kubernetes. And that of course is costume, >>there's some garage, I mean take us back. I mean, you know, container has been around forever. But then, you know, they started to, you know, hit go mainstream and and and and at first, you know, they were obviously ephemeral, stateless apps, kind of lightweight stuff. But but you at the time you and the team said, okay, these are gonna become more complex microservices. Maybe so micro, but you had to have the vision and you made a bet uh maybe take us back to sort of how you saw that and where where's containers have have come from? >>Sure. So let's rewind the clock right. As you said, containers, old technology in the same way virtualization started with IBM mainframes, right, containers in different forms have been around for a while. But I think when the light bulb went off for me was very early days in 2015 when my engineering team, a previous company started complaining. And the reason they were complaining about different other engineering groups and the reason they were complaining was because the right things, things were coming together sooner. We're identifying things sooner. And that's when I said, this is going to be the next wave of infrastructure. The same way watch a light virtualization revolutionized how people built deployed apps. We saw that with containers and in particular in those days we made that bet on commodities. Right? So we said from first Principles and that's where you know, you had other things like Docker, swarm esos, etcetera and we said community, that's going to be the way to go because it is just so powerful and it is, you know, at the end of the day, what we all do is infrastructure. But what we saw was that containers optimizing for the developer, they were optimizing for the people that really build applications, deliver value to all of their and customers. And that is what made us see that even though the initially we only saw stateless applications state will was going to happen because there's just so much momentum behind it And the writing for us at least was on the wall. And that's how we started off on this journey in 2017. >>What are the unique nuances and differences really in terms of protecting containers from a, from a technical standpoint, what what's different? >>So there are a couple of subtle things. Right again, the jokers, you know, I say, is that I'm a recovering infrastructure person have always worked in infrastructure systems in the past and recovering them. But in this case we really had to flip things around right. I've come at it from the cloud disks volumes. VMS perspective, in this case to do the right thing by the customer needed a clean slate approach of coming out from the application down. So what we look at is what does the application look like? And that means protecting, not just the stuff that sits on disk, what your secrets in networking information, all those hundreds of pieces that make up a cloud native application and that involves scale challenges, work, visualisation challenges for admins, KPI So all of that shifts in a very dramatic way. >>So Danny, I mean typically VM you guys haven't done a ton of acquisitions, uh, you've grown organically. So now you, you, you poppin cast in, what does that mean for you from a platform perspective? You know, IBM has this term blue washing when they buy a company did you green wash cast and how did that all work? And again, what does what does it mean from the, from the platform perspective? >>Well, so our platform is designed for this type of integration and the first type of integration we do with any of our technologies because we do have native technologies, if you think about what we do being back up for AWS for Azure, for G C p, we have backup for Acropolis Hyper Visor. These are all native purpose built solutions for those environments and we integrate with what we call being platform services. And one of the first steps that we do of course is we take the data from those native solutions and send it into the repository and the benefit that you get from that is that you have this portable, self describing format that you can move around the vein platform. And so the platform was already designed for this Now. We already showed this at demon. You saw this on the main stage where we have this integration at a data level but it goes beyond that beam platform services allows us to do not just day one operations, but day two operations. Think about um updating the components of those infrastructures or those software components that also allows reporting. So for example you can report on what is protected, what's not protected. So the platform was already designed for this integration model. But the one thing I want to stress is we will always have that stand alone product for kubernetes for uh you know, for the container world. And the reason for that is the administrator for Kubernetes wants their own purpose build solution. They want it running on kubernetes. They want to protect the uniqueness of their infrastructure. If you think about a lot of the container based systems there, They're using structured data. Non structured data. Sure. But they're also using object based storage. They're using message queues. And so they have their nuances. And we want to maintain that in a stand alone product but integrated back into the Corvin platform. >>So we do these we have a data partner called GTR Enterprise Technology Research. They do these quarterly surveys and and they have this metric called net score is a measure of spending momentum and for the last, I don't know, 8, 10, 12 quarters the big four have been robotic process automation. That's hot space. Cloud obviously is hot and then A I of course. And but containers and container orchestration right up there. Those are the Big four that outshine everything else, even things like security and other infrastructure etcetera. So that's good. I mean you guys skating to the puck back in 2015 rush, you've made some announcements and I'm and I'm wondering sort of how they fit into the trends in the industry. Uh, what what's, what's significant about those announcements and you know, what's new that we need to know about. >>Sure. So let me take that one day. So we've made a couple of big interesting announcement. The most recent one of those was four dot release after casting by women platform, right? We call it kitten and right. We've known rate since a couple of weeks colonial pipeline ransom. Where has been in the news in the US gas prices are being driven up because of that. And that's really what we're seeing from customers where we are >>seeing this >>increase in communities adoption today. We have customers from the world's largest banks all the way to weakly connected cruise ships that one could burn. It is on them. People's data is precious. People are running a large fleet of notes for communities, large number of clusters. So what we said is how do you protect against these malicious attacks that want to lock people out? How do you bring in mutability so that even someone with keys to the kingdom can't go compromise your backups and restores, right? So this echoes a lot of what we hear from customers and what we hear about in the news so well protected that. But we still help through to some of the original vision behind cast. And that is, it's not just saying, hey, I give you ransomware protection. We'll do it in such an easy way. The admin barely notices. This new feature has been turned on if they wanted Do it in a way that gives them choice right. If you're running in a public cloud, if you're running at the edge you have choice of infrastructure available to you and do it in a way that you have 100% automation when you have 100 clusters when you deploy on ships, right, you're not going to be able to have we spoke things. So how do you hook into CHED pipelines and make the job of the admin easier? Is what we focused on in that last >>night. And and that's because you're basically doing this at the point of writing code and it's essentially infrastructure as code. We always talk about, you know, you want to you don't want to bolt on data protection as an afterthought, but that's what we've done forever. Uh This you can't >>so in fact I would say step before that day, right are the most leading customers we work with. Right to light up one of the U. S. Government's largest contractors. Um Hey do this before the first line of code is written right there on the scalp cloud as an example. But with the whole shift left that we all hear the cube talks a lot about. We see at this point where as you bring up infrastructure, you bring up a complete development environment, a complete test environment. And within that you want to deploy security, you want to deploy backup your to deploy protection at day zero before the developer in so it's the first line of cordon. So you protected every step of the journey while trying to bolt it on the sound. Seemingly yes, I stitched together a few pieces of technology but it fundamentally impacts how we're going to build the next generation of secure applications >>Danny, I think I heard you say or announced that this is going to be integrated into Wien backup and replication. Um can you explain what that took? Why? That's important. >>Yeah. So the the timeline on this and when we do integrations from these native solutions into the core platform, typically it begins with the data integration, in other words, the data being collected by the backup tool is sent to a repository and that gives us all the benefits of course of things like instant recovery and leveraging, de doop storage appliances and all of that step to typically is around day to operations, things like pushing out updates to that native solutions. So if you look at what we're doing with the backup for AWS and Azure, we can deploy the components, we can deploy the data proxies and data movers. And then lastly there's also a reporting aspect to this because we want to centralize the visibility for the organization across everywhere. So if your policy says hey I need two weeks of backups and after two weeks and I need weekly backups for X amount of time. This gives you the ability to see and manage across the organization. So what we've demonstrated already is this data level integration between the two platforms and we expect this to continue to go deeper and deeper as we move forward. The interesting thing right now is that the containers team often is different than the standard data center I. T. Team but we are quickly seeing the merge and I think the speed of that merging will also impact how quickly we integrate them within our platform. >>Well I mean obviously you see this for cloud developers and now you're bringing this to any developers and you know, if I'm a developer and I'm living in an insurance company, I've been, you know, writing COBOL code for a while, I want to be signed me up. I want to get trained on this, right? Because it's gonna I'm gonna become more valuable. So this is this is where the industry is headed. You guys talk about modern data protection. I wondered if you could you could paint a picture for us of sort of what what this new world of application development and deployment and and data protection looks like and how it's different from the old world. >>Mhm. So I think that if you mentioned the most important word, which is developer, they come first, they are the decision makers in this environment, the other people that have the most bull and rightly so. Oh, so I think that's the biggest thing at the cultural level that is, developers are saying this is what we want and this is what we need to get the job done, we want to move quickly. So some of the things are let's not slow them down. Let's enable them, let's give them any P I to work with. Right? No. Where in bulk of production, use will be api based versus EY base. Let's transparently integrate into the environment. So therefore protection for security, they need zero lines have changed code. Mm So those are some of the ways we approach things. Now when you go look at the requirements of the developers, they said I have a Ci cd pipeline to integrate into that. I have a development pipeline to integrate into that. I deploy across multiple clouds sometimes. Can you integrate into that and work seamlessly across all those environments? And we see those category of us coming up over and over again from people. >>So the developer rights once and it doesn't have to worry about where it's running. Uh it's got the right security, there are a protection and those policies go with it, so that's that's definitely a different world. Um Okay, last question. Uh maybe you guys could each give your opinion on sort of where we're headed, uh what we can expect from the the acquisition, the the integration, what should we look forward to and what should we pay attention to? >>Well, the one obvious thing that you're going to see is tremendous growth on the company's side and that's because Kubernetes is taking off cloud is taking off um SaAS is taking off and so there's obvious growth there. And one of the things that were clearly doing is um we're leveraging the power of of, you know, a few 1000 sales people to bring this out to market. Um, and so there is emerging of of sales and marketing activities and leveraging that scale. But what you shouldn't expect to see anything different on is this obsessive focus on the product, on quality, on making sure that we're highly differentiated that we have a product that the company that our customers and companies actually need no garage. >>Yeah. So I'll agree with everything down, he said. But a couple of things. Excite me a lot. Dave we've been roughly eight months or so since acquisition and I particularly love how last what in this quarter have gone in terms of how we focuses on solving customer problems. All right. So we'll always have that independent support for a cloud date of customers, but I'm excited about not just working with the broadest side of customers and as we scale the team that's going to happen, but providing a bridge to all the folks that grew up in the virtualization world, right? Grew up in the physical wall of physical service, etcetera and saying, how do we make it easy for you to come over to this new container Ization world? What is the on ramps bridging that gap serving as the on ramp? And we're doing a lot of work there from the product integration and independent product features that just make it easy. Right? And we're already seeing feel very good feedback for that from the field right now. >>I really like your position. I just dropped my quarterly cloud update. I focused, I look at the Big Four, the Big Four last year, spent $100 billion on Capex. And I always say that is a gift to companies like yours because you can be that connection point between the virtualization crowd, the on prem cloud, any cloud. Eventually we'll be, we'll be more than just talking about the Edge will actually be out there, you know, doing real work. Uh, and I just see great times ahead for you guys. So thanks so much for coming on the cube explaining this really exciting new area. Really appreciate it. >>Thank you so much. >>Thank you everybody for watching this day. Volonte for the Cube and our continuous coverage of the mon 2021, the virtual edition. Keep it right there. >>Mm mm mm

>> From "The Cube studios" in Palo Alto and Boston, connecting with thought leaders all around the world. This, is a cube conversation. >> Welcome to this Cube Virtual conversation. I'm Lisa Martin and I'm excited to be talking to one of our cube alumni again, very socially distant, Derek Manky joins me the chief security insights and global for alliances, Fortinet's FortiGuard labs, Derek it's great to see you, even though virtually >> Yep, better safe better safe these days, right? But yeah, it's great to see you again and um I'm really looking forward to a great conversation, as always. >> Yeah! So Wow Has a lot changed since I last saw you? I-I think that's an epic understatement.. But each year we talk with you about the upcoming What's coming up in the threat landscape, what you guys are seeing Some of the attack trends. What are some of the things that you've seen in this very eventful year since we last spoke? >> Yeah.. a lot of a lot of things.. um.. Obviously.. uh.. with the pandemic there has been this big shift in landscape, right? So particularly uh Q3 Q4. So the last half of the year uh now we have a lot of things that were traditionally in corporate safeguards um you know, actual workstations, laptops that were sitting within networks and perimeters of-of organizations, that have obviously moved to work from home. And So, with that, comes a lot of new a-attack opportunities Um We track as, you know, threat until at 40 minutes, so 40 guard labs on a daily basis. And.. uh.. we are clearly seeing that and we're seeing a huge rise in things like um IOT targets, being the number one attacks, so consumer grade routers, um IOT devices, like printers and network attached storage. Those are um some of the most, favorite attack vehicles that cyber criminals are using to get into the-those devices. Of course, once they get in those devices, they can then move, laterally to compromise the..uh corporate laptop as an example. So those are-are very concerning The other thing has been that email that traditionally has been our number one um Another favorite attack platform always has! It's not going away but for the first time this year in.. um in about September, the second half, we saw a web based attacks taking priority for attackers and that's because of this new working environment. A lot of people I'm serving the websites from Again, these devices that were, not, were previously within Um you know, organizations email security is centralized a lot of the times but the web security always isn't. So that's another another shift that we've seen. We're now in the full-blown midst of the online shopping season um action and shopping season is almost every day now (laughter) since this summer >> Yep.. Yep.. >> And we've clearly seen that And we- Just from September up to October we saw over a trillion, not a billion, but a trillion new flows to shopping websites uh In just one month Um So that can- than number continues to rise and continues to rising quickly. >> Yeah. So the- the expanding threat landscape I've talked to a number of Companies the last few months that we're in this situation where it's suddenly It was a maybe 100% onsite workforce now going to work from home taking uh either desktops from uh their offices or using personal devices and that was a huge challenge that we were talking about with respect to endpoint and laptop security But interesting that you- you're seeing now this web security, I know phishing emails are getting more personal but the fact that um That website attacks are going up What are some of the things that you think, especially yo-you bring up a point we are we are now and maybe even s- more supercharged e-commerce season. How can businesses prepare a-and become proactive to defend against some of these things that, since now the threat surface is even bigger? >> Yeah. Multi-pronged approach. You know, Lisa, like we always say that, first of all, it's just like we have physical distancing, cyber distancing, just like we're doing now on this call. But same thing for reuse. I think there's always a false sense of security, right? When you're just in the home office, doing some browsing to a site, you really have to understand that these sites just by touching, literally touching it by going to the URL and clicking on that link you can get infected that easily. We're seeing that, there's a lot of these attacks being driven So, education, there's a lot of free programs. We have one on Fortinet information security awareness training. That is something that we continually need to hone the skills of end users first of all, so that's an easy win I would say, to my eyes in terms of organizations, but then this multi-pronged approach, right? So things like having EDR endpoint detection response, and being able to manage those end users while they're on on their devices at home Being able to have security and making sure those are up to date in terms of patches. So centralized management is important, two factor authentication, or multi-factor authentication Also equally as important. Doing things like network segmentation. For end users and the devices too. So there's a lot of these Things that you look at the risk that's associated The risk is always way higher than the investment upfront in terms of hours, in terms of security platforms. So the good thing is there's a lot of Solutions out there and it doesn't have to be complicated. >> That's good because we have enough complication everywhere else. But you bring up a point, you know, about humans, about education. We're kind of always that weakest link, but so many of us, now that are home, have distractions going on all around. So you might be going, "I've got to do some bill pay and go onto your bank" without thinking that that's that's now a threat landscape. What are some of the things that you're seeing that you think we're going to face in 2021, which is just around the corner? >> Yeah so So we're just talking about those IOT devices They're the main culprit right now. They can continue to be for a while We have this new class of threat emerging technology, which is edge computing. So people always talked about the perimeter of the perimeter being dead in other words, not just building up a wall on the outside, but understanding what's inside, right? That's been the case of IOT, but now edge computing is the emerging technology The main difference You know, we say, is that the edge devices are virtual assistant is the best example I could give, right? That, that users will be aware of in-home networks. Because these devices, traditionally, have more processing power, they handle more data, they have more access and privilege to devices like things like security systems, lights, as an example Beyond home networks, these edge devices are also As an example, being put into military and defense into critical infrastructure, field units for oil and gas and electricity as an example. So this is the new emerging threat, more processing power, more access and privilege, smarter decisions that are being made on those devices Those devices, are going to be targets for cyber criminals. And that's something, I think next year, we're going to see a lot of because it's a Bigger reward to the cyber criminal if they can get into it. And So targeting the edge is going to be a big thing. I think there's going to be a new class of threats. I'm calling these, I haven't heard this coined in the industry yet, but I'm calling these or "EAT"s or "Edge Access Trojans" because that's what it is, they compromise these devices. They can then control and get access to the data. If you think of a virtual assistant, and somebody that can actually compromise that device, think about that data. Voice data that's flowing through those devices that they can then use as a cleverly engineered, you know, attack a social engineering attack to phish a user as an example. >> Wow! I never thought about it from that perspective before Do you think, with all the talk about 5G, and what's coming with 5G, is that going to be an accelerator of some of these trends? Of some of these "EAT"s that you talk about? >> Yeah, definitely. Yeah So 5G is just a conduit. It's an accelerator. Absolutely um Catalyst called, if you will, It's here. Um, it's been deployed, not worldwide, but in many regions, it's going to continue to be 5G is all about, um, speed.. Um right? And so if you think about how swiftly these attacks are moving, you be abl- you need to be able to keep up with that from a defense standpoint, um Threats move without borders, they move without Uh, uh, Unfortunately, without restriction a lot of the time, right? Cyber crime has no borders. Um, the-they don't have rules, or if they have, they don't care about rules (laughter) So break those rules. So they are able to move quickly, right? And that's th- the problem with 5G, of course, is that these devices now can communicate quicker, they can launch even larger scale things like "DDOS", "Distributed Denial Of Service attacks". And That is, is a very big threat. And it also allows the other thing about 5G, Lisa, is that it allows.. um.. Peer to peer connectivity too. Right? So it's like Bluetooth, Um, Bluetooth's um enhanced in a sense, because now you have devices that interact with each other as well, by interacting with each other Um that also uh, you know, what are they talking about? What data are they passing? That's a whole new security inspection point that we need to And that's what I mean about this.. Um that's just It reconfirms that the.. Perimeters that. >> Right. Something we've been talking about, as you said for a while, but That's some pretty hard hitting evidence that it is, indeed, a thing of the past Something that we've talked to you about - with you in the past is Swarm attacks. Ho- What's, What's going on there? How are they progressing? >> Yeah, so this is a real threat, but there's good news, bad news. The Good news is this is a long progressing threat, which means we have more time to prepare. Bad news is we have seen developments in terms of weaponizing this, It's like anything.. Swarm is a tool. It can be as good.. DARPA, as an example, has invested a lot into this from military research, it's all around us now in terms of good applications things like for redundancy, right? Robotics, as an example, there's a lot of good things that come from Swarm technology, but.. There's use for If it's weaponized, It can have some very scary prospects. And that's what we're starting to see. There's a new botnet that was created this year. It is called the "HTH" this is written in Golang. So it's a language that basically allows it to infect any number of devices. It's not just your PC Right? It's the same, it's the same virus, but it can morph into all these different platforms, devices, whether it's a, an IOT device, an edge device But the main, characteristic of this is that it's able to actually have communication. They built a communication protocol into it. So the devices can pass files between each other, talk to each other They don't have a machine learning models yet, so in other words, they're not quote-in-quote "smart" yet, but that's coming. Once that intelligence starts getting baked in, then we have the weaponized Swarm technology And what this means, is that you know, when you have those devices that are making decisions on their own, talking to each other >> A: they're harder to kill. You take one down, another one takes its place. >> B: um They are able to move very swiftly, especially when that piggybacking leveraging on things like 5G. >> So . the I'm just blown away at all these things that you're talking about They are so So talk about how companies, and even individuals, can defend against this and become proactive. As we know one of the things we know about 2020 is all the uncertainty, we're going to continue to see uncertainty, but we also know that we- there's expectation.. globally, that a good amount of people are going to be working from home and connecting to corporate networks for a very long time. So, how can companies and people become proactive against these threats? >> Yes People process procedures and technology. So, we talked, as I really looked at this as a stacked approach, first of all, threats, as it is said, they're becoming quicker, the attack surface is larger, you need threat intelligence visibility This comes down to security platforms from a technology piece. So a security driven networking, AI driven security operations Centers These are new. But it's, it's becoming, as you can imagine, when we talked about critical, to fill that gap, to be able to move as quickly as the attackers you need to be able to use intelligent technology on your end. So people are just too slow. But we can still use people from the process, you know, making sure You know, Trying to understand what the risk is. So looking at threat intelligence reports, we put out weekly threat intelligence briefs as an example of as Fortiguard Labs, to be able to understand what the threats are, how to respond to those, how to prioritize them and then put the proper security measures in place. So, there are absolutely relevant technologies that exist today, And in fact now I think is the time to really get those in deployment before this becomes worse, as we're talking about. And then as I said earlier, there's also free things that can be just part of our daily lives, right? So we don't have this false sense of security. So understanding that that threat is real following up on the threat and being on doing education There's phishing services Again, phishing can be a good tool when it's used in a non-malicious way, to test people's skills sets as an example. So all of that combined is But the biggest thing is definitely relying on things like machine learning, artificial intelligence, to be able to work at speed with these threats. >> Right. So, you also have global threat alliances under your portfolio. Talk to me about how 40 net is working with global Alliance partners to fight this growing attack surface. >> Yeah. So this is the ecosystem. Every, every organization, whether it's private or public sector, has a different role to play in essence, right? So you look at things in the public sector, you have law enforcement, they're focused on attribution, so when we look at cyber crime, and if we find It's the hardest thing to do, but if we find out who these cyber criminals are, we can bring them to justice. Right? Our whole goal is to make it more expensive for the cyber criminals to operate, So by doing this, if we work with law enforcement and it leads to a successful arrest and prosecution, because we've done it in the past, that takes them off line to hit somewhere it hurts Law enforcement will typically work with intelligence leads to freeze assets, as an example from maybe ransom attacks that are happening. So that's one aspect, but then you have other things like working with national computer emergency response. So disrupting cyber crime, we work with national series. If we know that, you know, the bad guys are hosting stolen data or communication infrastructure in public, you know, servers, we can work with them to actually disrupt that, to take those servers offline. Then you have the private space. So this, you know Fortinet we're a founding member of the Cyber Threat Alliance. I'm on the steering committee there. And this is working with even competitors around in our space where we can share quickly up-to-date intelligence on, on attackers. We remain competitive on the technology itself, but, you know, we're working together to actually share as much as we know about the bad guys. And recently we're also a founding member of the "Center for Cyber Security", "C for C" with World Economic Forum. And This is another crucial effort that is basically trying to bridge all of that. To mend all of that together, right? Law enforcement, prosecutors, security vendors, intelligence organizations, all under one roof because we really do need that. It's an entire ecosystem to make this an effective fight. So it's, it's interesting because a lot of people, I don't think see what's happening behind the scenes a lot of the times, but there is a tremendous effort globally that's happening between all the players. So that's really good news. And the industry piece is something close to my heart. I've been involved in a lot of time and we continue to support. >> That's exciting. And that's something that is, you know, unfortunately, so very, very needed and will continue to be as emerging technologies evolve and we get to use them for good things. And to your point, that bad actors also get to take advantage of that for nefarious things as well. Derek it's always great to have you on the program, any particular things on the 40 net website that you would point viewers to to learn more about like the 20, 20 front landscape? >> Sure. You can always check out our blogs, So it's on blogged@fortynet.com, under "Threat Research", As I said on 40 guard.com, we also have our playbooks on there. We have podcasts, we have our updated threat intelligence briefs too. So those are always great to check out and just be rest assured that, you know, everything I've been talking about, we're doing a lot of that heavy lift on the backend. So by having working with managing security service providers and having all this intelligence baked in, organizations don't have to go and have a huge OPEX by you know, hiring, you know, trying to create a massive security center on their own. I mean, it's about this technology working together and that's that's what we're here for, its we can ask what do you guard lapse? >> Awesome Derek, thank you so much for joining me today in this Cube Conversation. Lots of exciting stuff going on at 40 net and 40 guard labs as always, which we expect, it's been great to have you. Thank you. >> It's a pleasure. Thanks Lisa. >> For Derek Manky. I'm Lisa Martin. You're watching the Virtual Cube.

>>Hello, My name is John John Sheikh from Iran Tous. Welcome to our session on new extensions for doctors CLI as we all know, containers air everywhere. Kubernetes is coming on strong and the CNC F cloud landscape slide has become a marvel to behold its complexities about to surpass that of the photo. Letha dies used to fabricate the old intel to 86 and future generations of the diagram will be built out and up into multiple dimensions using extreme ultraviolet lithography. Meanwhile, complexity is exploding and uncertainty about tools, platform details, processes and the economic viability of our companies in changing and challenging times is also increasing. Mirant ous, as you've already heard today, believes that achieving speed is critical and that speed results from balancing choice with simplicity and security. You've heard about Dr Enterprise Container Cloud, a new framework built on kubernetes, the less you deploy compliant, secure by default. Cooper nineties clusters on any infrastructure, providing a seamless self service capable cloud experience to developers. Get clusters fast, Justus, you need them, Update them seamlessly. Scale them is needed all while keeping workloads running smoothly. And you've heard how Dr Enterprise Container Cloud also provides all the day one and Day two and observe ability, tools, the integration AP ICE and Top Down Security, Identity and Secrets management to run operations efficiently. You've also heard about Lens, an open source i D for kubernetes. Aimed at speeding up the most banding, tightest inner loop of kubernetes application development. Lens beautifully meets the needs of a new class of developers who need to deal with multiple kubernetes clusters. Multiple absent project sufficiently developers who find themselves getting bogged down and seal I only coop CTL work flows and context switches into and out of them. But what about Dr Developers? They're working with the same core technologies all the time. They're accessing many of the same amenities, including Docker, engine Enterprise, Docker, Trusted registry and so on. Sure, their outer loop might be different. For example, they might be orchestrating on swarm. Many companies are our future of Swarm session talks about the ongoing appeal of swarm and Miranda's commitment to maintaining and extending the capabilities of swarm Going forward. Dr Enterprise Container Cloud can, of course, deployed doctor enterprise clusters with 100% swarm orchestration on computes just Aziza Leah's. It can provide kubernetes orchestration or mixed swarming kubernetes clusters. The problem for Dr Dev's is that nobody's given them an easy way to use kubernetes without a learning curve and without getting familiar with new tools and work flows, many of which involved buoys and are somewhat tedious for people who live on the command line and like it that way until now. In a few moments you'll meet my colleagues Chris Price and Laura Powell, who enact a little skit to introduce and demonstrate our new extended docker CLI plug in for kubernetes. That plug in offers seamless new functionality, enabling easy context management between the doctor Command Line and Dr Enterprise Clusters deployed by Dr Enterprise Container Cloud. We hope it will help Dev's work faster, help them adapt decay. TSA's they and their organizations manage platform coexistence or transition. Here's Chris and Laura, or, as we like to call them, developer A and B. >>Have you seen the new release of Docker Enterprise Container Cloud? I'm already finding it easier to manage my collection of UCP clusters. >>I'm glad it's helping you. It's great we can manage multiple clusters, but the user interface is a little bit cumbersome. >>Why is that? >>Well, if I want to use docker cli with a cluster, I need to download a client bundle from UCP and use it to create a contact. I like that. I can see what's going on, but it takes a lot of steps. >>Let me guess. Are these the steps? First you have to navigate to the web. You i for docker Enterprise Container Cloud. You need to enter your user name and password. And since the cluster you want to access is part of the demo project, you need to change projects. Then you have to choose a cluster. So you choose the first demo cluster here. Now you need to visit the U C p u I for that cluster. You can use the link in the top right corner of the page. Is that about right? >>Uh yep. >>And this takes you to the UCP you. I log in page now you can enter your user name and password again, but since you've already signed in with key cloak, you can use that instead. So that's good. Finally, you've made it to the landing page. Now you want to download a client bundle what you can do by visiting your user profile, you'll generate a new bundle called Demo and download it. Now that you have the bundle on your local machine, you can import it to create a doctor context. First, let's take a look at the context already on your machine. I can see you have the default context here. Let's import the bundle and call it demo. If we look at our context again, you can see that the demo context has been created. Now you can use the context and you'll be able to interact with your UCP cluster. Let's take a look to see if any stacks are running in the cluster. I can see you have a stack called my stack >>in >>the default name space running on Kubernetes. We can verify that by checking the UCP you I and there it iss my stack in the default name space running on Kubernetes. Let's try removing the stack just so we could be sure we're dealing with the right cluster and it disappears. As you can see. It's easy to use the Docker cli once you've created a context, but it takes quite a bit of effort to create one in the first place. Imagine? >>Yes. Imagine if you had 10 or 20 or 50 clusters toe work with. It's a management nightmare. >>Haven't you heard of the doctor Enterprise Container Cloud cli Plug in? >>No, >>I think you're going to like it. Let me show you how it works. It's already integrated with the docker cli You start off by setting it up with your container cloud Instance, all you need to get started is the base. You are all of your container cloud Instance and your user name and password. I'll set up my clothes right now. I have to enter my user name and password this one time only. And now I'm all set up. >>But what does it actually dio? >>Well, we can list all of our clusters. And as you can see, I've got the cluster demo one in the demo project and the cluster demo to in the Demo project Taking a look at the web. You I These were the same clusters we're seeing there. >>Let me check. Looks good to me. >>Now we can select one of these clusters, but let's take a look at our context before and after so we can understand how the plug in manages a context for us. As you can see, I just have my default contact stored right now, but I can easily get a context for one of our clusters. Let's try demo to the plug in says it's created a context called Container Cloud for me and it's pointing at the demo to cluster. Let's see what our context look like now and there's the container cloud context ready to go. >>That's great. But are you saying once you've run the plug in the doctor, cli just works with that cluster? >>Sure. Let me show you. I've got a doctor stack right here and it deploys WordPress. Well, the play it to kubernetes for you. Head over to the U C P u I for the cluster so you can verify for yourself. Are you ready? >>Yes. >>First I need to make sure I'm using the context >>and >>then I can deploy. And now we just have to wait for the deployment to complete. It's as easy as ever. >>You weren't lying. Can you deploy the same stack to swarm on my other clusters? >>Of course. And that should also show you how easy it is to switch between clusters. First, let's just confirm that our stack has reported as running. I've got a stack called WordPress demo in the default name space running on Kubernetes to deploy to the other cluster. First I need to select it that updates the container cloud context so I don't even need to switch contexts, since I'm already using that one. If I check again for running stacks, you can see that our WordPress stack is gone. Bring up the UCP you I on your other cluster so you can verify the deployment. >>I'm ready. >>I'll start the deployment now. It should be appearing any moment. >>I see the services starting up. That's great. It seems a lot easier than managing context manually. But how do I know which cluster I'm currently using? >>Well, you could just list your clusters like So do you see how this one has an asterisk next to its name? That means it's the currently selected cluster >>I'm sold. Where can I get the plug in? >>Just go to get hub dot com slash miran tous slash container dash cloud dash cli and follow the instructions

>> In this session, we will be reviewing the power and benefits of implementing a secure software supply chain and how we can gain a cloud like experience with the flexibility, speed and security of modern software delivering. Hi, I'm Matt Bentley and I run our technical pre-sales team here at Mirantis. I spent the last six years working with customers on their containerization journey. One thing almost every one of my customers has focused on is how they can leverage the speed and agility benefits of containerizing their applications while continuing to apply the same security controls. One of the most important things to remember is that we are all doing this for one reason and that is for our applications. So now let's take a look at how we can provide flexibility to all layers of the stack from the infrastructure on up to the application layer. When building a secure supply chain for container focused platforms, I generally see two different mindsets in terms of where their responsibilities lie between the developers of the applications and the operations teams who run the middleware platforms. Most organizations are looking to build a secure, yet robust service that fits their organization's goals around how modern applications are built and delivered. First, let's take a look at the developer or application team approach. This approach falls more of the DevOps philosophy, where a developer and application teams are the owners of their applications from the development through their life cycle, all the way to production. I would refer to this more of a self service model of application delivery and promotion when deployed to a container platform. This is fairly common, organizations where full stack responsibilities have been delegated to the application teams. Even in organizations where full stack ownership doesn't exist, I see the self service application deployment model work very well in lab development or non production environments. This allows teams to experiment with newer technologies, which is one of the most effective benefits of utilizing containers. In other organizations, there is a strong separation between responsibilities for developers and IT operations. This is often due to the complex nature of controlled processes related to the compliance and regulatory needs. Developers are responsible for their application development. This can either include dock at the development layer or be more traditional, throw it over the wall approach to application development. There's also quite a common experience around building a center of excellence with this approach where we can take container platforms and be delivered as a service to other consumers inside of the IT organization. This is fairly prescriptive in the manner of which application teams would consume it. Yeah when examining the two approaches, there are pros and cons to each. Process, controls and compliance are often seen as inhibitors to speed. Self-service creation, starting with the infrastructure layer, leads to inconsistency, security and control concerns, which leads to compliance issues. While self-service is great, without visibility into the utilization and optimization of those environments, it continues the cycles of inefficient resource utilization. And a true infrastructure as a code experience, requires DevOps, related coding skills that teams often have in pockets, but maybe aren't ingrained in the company culture. Luckily for us, there is a middle ground for all of this. Docker Enterprise Container Cloud provide the foundation for the cloud like experience on any infrastructure without all of the out of the box security and controls that our professional services team and your operations teams spend their time designing and implementing. This removes much of the additional work and worry around ensuring that your clusters and experiences are consistent, while maintaining the ideal self service model. No matter if it is a full stack ownership or easing the needs of IT operations. We're also bringing the most natural Kubernetes experience today with Lens to allow for multi-cluster visibility that is both developer and operator friendly. Lens provide immediate feedback for the health of your applications, observability for your clusters, fast context switching between environments and allowing you to choose the best in tool for the task at hand, whether it is the graphic user interface or command line interface driven. Combining the cloud like experience with the efficiencies of a secure supply chain that meet your needs brings you the best of both worlds. You get DevOps speed with all the security and controls to meet the regulations your business lives by. We're talking about more frequent deployments, faster time to recover from application issues and better code quality. As you can see from our clusters we have worked with, we're able to tie these processes back to real cost savings, real efficiency and faster adoption. This all adds up to delivering business value to end users in the overall perceived value. Now let's look and see how we're able to actually build a secure supply chain to help deliver these sorts of initiatives. In our example secure supply chain, where utilizing Docker desktop to help with consistency of developer experience, GitHub for our source control, Jenkins for our CACD tooling, the Docker trusted registry for our secure container registry and the Universal Control Plane to provide us with our secure container runtime with Kubernetes and Swarm, providing a consistent experience, no matter where our clusters are deployed. You work with our teams of developers and operators to design a system that provides a fast, consistent and secure experience. For my developers, that works for any application, Brownfield or Greenfield, Monolith or Microservice. Onboarding teams can be simplified with integrations into enterprise authentication services, calls to GitHub repositories, Jenkins access and jobs, Universal Control Plan and Docker trusted registry teams and organizations, Kubernetes namespace with access control, creating Docker trusted registry namespaces with access control, image scanning and promotion policies. So, now let's take a look and see what it looks like from the CICD process, including Jenkins. So let's start with Docker desktop. From the Docker desktop standpoint, we'll actually be utilizing visual studio code and Docker desktop to provide a consistent developer experience. So no matter if we have one developer or a hundred, we're going to be able to walk through a consistent process through Docker container utilization at the development layer. Once we've made our changes to our code, we'll be able to check those into our source code repository. In this case, we'll be using GitHub. Then when Jenkins picks up, it will check out that code from our source code repository, build our Docker containers, test the application that will build the image, and then it will take the image and push it to our Docker trusted registry. From there, we can scan the image and then make sure it doesn't have any vulnerabilities. Then we can sign them. So once we've signed our images, we've deployed our application to dev, we can actually test our application deployed in our real environment. Jenkins will then test the deployed application. And if all tests show that as good, we'll promote our Docker image to production. So now, let's look at the process, beginning from the developer interaction. First of all, let's take a look at our application as it's deployed today. Here, we can see that we have a change that we want to make on our application. So our marketing team says we need to change containerize NGINX to something more Mirantis branded. So let's take a look at visual studio code, which we'll be using for our ID to change our application. So here's our application. We have our code loaded and we're going to be able to use Docker desktop on our local environment with our Docker desktop plugin for visual studio code, to be able to build our application inside of Docker, without needing to run any command line specific tools. Here with our code, we'll be able to interact with Docker maker changes, see it live and be able to quickly see if our changes actually made the impact that we're expecting our application. So let's find our updated tiles for application and let's go ahead and change that to our Mirantis sized NGINX instead of containerized NGINX. So we'll change it in a title and on the front page of the application. So now that we've saved that changed to our application, we can actually take a look at our code here in VS code. And as simple as this, we can right click on the Docker file and build our application. We give it a name for our Docker image and VS code will take care of the automatic building of our application. So now we have a Docker image that has everything we need in our application inside of that image. So, here we can actually just right click on that image tag that we just created and do run. This will interactively run the container for us. And then once our containers running, we can just right click and open it up in a browser. So here we can see the change to our application as it exists live. So, once we can actually verify that our applications working as expected, we can stop our container. And then from here, we can actually make that change live by pushing it to our source code repository. So here, we're going to go ahead and make a commit message to say that we updated to our Mirantis branding. We will commit that change and then we'll push it to our source code repository. Again, in this case, we're using GitHub to be able to use as our source code repository. So here in VS code, we'll have that pushed here to our source code repository. And then, we'll move on to our next environment, which is Jenkins. Jenkins is going to be picking up those changes for our application and it checked it out from our source code repository. So GitHub notifies Jenkins that there's a change. Checks out the code, builds our Docker image using the Docker file. So we're getting a consistent experience between the local development environment on our desktop and then in Jenkins where we're actually building our application, doing our tests, pushing it into our Docker trusted registry, scanning it and signing our image in our Docker trusted registry and then deploying to our development environment. So let's actually take a look at that development environment as it's been deployed. So, here we can see that our title has been updated on our application, so we can verify that it looks good in development. If we jump back here to Jenkins, we'll see that Jenkins go ahead and runs our integration tests for our development environment. Everything worked as expected, so it promoted that image for our production repository in our Docker trusted registry. We're then, we're going to also sign that image. So we're assigning that yes, we've signed off that has made it through our integration tests and it's deployed to production. So here in Jenkins, we can take a look at our deployed production environment where our application is live in production. We've made a change, automated and very secure manner. So now, let's take a look at our Docker trusted registry, where we can see our name space for our application and our simple NGINX repository. From here, we'll be able to see information about our application image that we've pushed into the registry, such as the image signature, when it was pushed by who and then, we'll also be able to see the results of our image. In this case, we can actually see that there are vulnerabilities for our image and we'll actually take a look at that. Docker trusted registry does binary level scanning. So we get detailed information about our individual image layers. From here, these image layers give us details about where the vulnerabilities were located and what those vulnerabilities actually are. So if we click on the vulnerability, we can see specific information about that vulnerability to give us details around the severity and more information about what exactly is vulnerable inside of our container. One of the challenges that you often face around vulnerabilities is how exactly we would remediate that in a secure supply chain. So let's take a look at that. In the example that we were looking at, the vulnerability is actually in the base layer of our image. In order to pull in a new base layer for our image, we need to actually find the source of that and update it. One of the ways that we can help secure that as a part of the supply chain is to actually take a look at where we get our base layers of our images. Docker hub really provides a great source of content to start from, but opening up Docker hub within your organization, opens up all sorts of security concerns around the origins of that content. Not all images are made equal when it comes to the security of those images. The official images from Docker hub are curated by Docker, open source projects and other vendors. One of the most important use cases is around how you get base images into your environment. It is much easier to consume the base operating system layer images than building your own and also trying to maintain them. Instead of just blindly trusting the content from Docker hub, we can take a set of content that we find useful such as those base image layers or content from vendors and pull that into our own Docker trusted registry, using our mirroring feature. Once the images have been mirrored into a staging area of our Docker trusted registry, we can then scan them to ensure that the images meet our security requirements. And then based off of the scan result, promote the image to a public repository where you can actually sign the images and make them available to our internal consumers to meet their needs. This allows us to provide a set of curated content that we know is secure and controlled within our environment. So from here, we can find our updated Docker image in our Docker trusted registry, where we can see that the vulnerabilities have been resolved. From a developer's point of view, that's about as smooth as the process gets. Now, let's take a look at how we can provide that secure content for our developers in our own Docker trusted registry. So in this case, we're taking a look at our Alpine image that we've mirrored into our Docker trusted registry. Here, we're looking at the staging area where the images get temporarily pulled because we have to pull them in order to actually be able to scan them. So here we set up mirroring and we can quickly turn it on by making it active. And then we can see that our image mirroring, we'll pull our content from Docker hub and then make it available in our Docker trusted registry in an automatic fashion. So from here, we can actually take a look at the promotions to be able to see how exactly we promote our images. In this case, we created a promotion policy within Docker trusted registry that makes it so that content gets promoted to a public repository for internal users to consume based off of the vulnerabilities that are found or not found inside of the Docker image. So our actual users, how they would consume this content is by taking a look at the public to them, official images that we've made available. Here again, looking at our Alpine image, we can take a look at the tags that exist and we can see that we have our content that has been made available. So we've pulled in all sorts of content from Docker hub. In this case, we've even pulled in the multi architecture images, which we can scan due to the binary level nature of our scanning solution. Now let's take a look at Lens. Lens provides capabilities to be able to give developers a quick opinionated view that focuses around how they would want to view, manage and inspect applications deployed to a Kubernetes cluster. Lens integrates natively out of the box with Universal Control Plane clam bundles. So you're automatically generated TLS certificates from UCP, just work. Inside our organization, we want to give our developers the ability to see their applications in a very easy to view manner. So in this case, let's actually filter down to the application that we just employed to our development environment. Here, we can see the pod for application. And when we click on that, we get instant detailed feedback about the components and information that this pod is utilizing. We can also see here in Lens that it gives us the ability to quickly switch contexts between different clusters that we have access to. With that, we also have capabilities to be able to quickly deploy other types of components. One of those is helm charts. Helm charts are a great way to package up applications, especially those that may be more complex to make it much simpler to be able to consume and inversion our applications. In this case, let's take a look at the application that we just built and deployed. In this case, our simple NGINX application has been bundled up as a helm chart and is made available through Lens. Here, we can just click on that description of our application to be able to see more information about the helm chart. So we can publish whatever information may be relevant about our application. And through one click, we can install our helm chart. Here, it will show us the actual details of the helm charts. So before we install it, we can actually look at those individual components. So in this case, we can see this created an ingress rule. And then this will tell Kubernetes how did it create this specific components of our application. We'd just have to pick a namespace to deploy it to and in this case, we're actually going to do a quick test here because in this case, we're trying to deploy the application from Docker hub. In our Universal Control Plane, we've turned on Docker content trust policy enforcement. So this is actually going to fail to deploy. Because we're trying to employ our application from Docker hub, the image hasn't been properly signed in our environment. So the Docker content trust policy enforcement prevents us from deploying our Docker image from Docker hub. In this case, we have to go through our approved process through our secure supply chain to be able to ensure that we know where our image came from and that meets our quality standards. So if we comment out the Docker hub repository and comment in our Docker trusted registry repository and click install, it will then install the helm chart with our Docker image being pulled from our DTR, which then it has a proper signature. We can see that our application has been successfully deployed through our home chart releases view. From here, we can see that simple NGINX application and in this case, we'll get details around the actual deployed helm chart. The nice thing is, is that Lens provides us this capability here with helm to be able to see all of the components that make up our application. From this view, it's giving us that single pane of glass into that specific application, so that we know all of the components that is created inside of Kubernetes. There are specific details that can help us access the applications such as that ingress rule that we just talked about, gives us the details of that, but it also gives us the resources such as the service, the deployment and ingress that has been created within Kubernetes to be able to actually have the application exist. So to recap, we've covered how we can offer all the benefits of a cloud like experience and offer flexibility around DevOps and operations control processes through the use of a secure supply chain, allowing our developers to spend more time developing and our operators, more time designing systems that meet our security and compliance concerns.

>> So, hi, my name is Daniel Terry, I work as Lead Designer at SEB. So, today we will go through why we are why we are Mirantis' customer, why we choose Docker Enterprise, and mainly what challenges we were facing before we chose to work with Docker, and where we are today, and our keys to success. >> Hi, my name is Johan, I'm a senior developer and a Tech Lead at SEB. I was in the beginning with Docker for like, four years ago. And as Daniel was saying here, we are going to present to you our journey with Docker and the answers. >> Yeah, who are we? We are SEB group. So we are a classic, financial large institutions. So, classic and traditional banking services. In Sweden, we are quite a big bank, one of the largest. And we are on a journey of transforming the bank so it has to be online 24-seven. People can do their banking business every day, whenever they want, nothing should stop them to be online. So this is putting a lot of pressure on us on infrastructure to be able to give them that service. (drum fill) >> So our timeline here. Is look, we started out with how to facilitate the container technology it has to be. 2016. And, in 2018, we had the first Docker running in SEB in a standalone mode. You need that. We didn't have any swarm, or given up this cluster since a while. For 2019, we have our first Docker-prise enterprise cluster at SEB. And today, 2020, we have the latest and greatest version of Docker installed. We are running around approximately two and a fifth at 450 specs. Around a thousand services and around 1500 containers. So, developer challenges. As for me as a developer, previous to Docker was really, really hard to get things in production. Times. It took big things and ordering services and infrastructures was a pain in the... yeah, you know what I mean? So for me, it was all about processes. We use natural processes and meaning that I wasn't able to, to see maintaining my system in production. I was handing that over to our operations teams and operation teams in that time, they didn't know how the application works. They didn't know how to troubleshoot it and see, well, what's going wrong. They were experts on the infrastructure and the platforms, but not on our applications. We were working in silos, meaning that I as a developer, only did developing things. The operations side did their things, and the security side did their things. But we didn't work as a team. I mean, today we have a completely different way of working. We will not see shapes. I mean, we have persons that were really good in maybe MQ technologies, or in some programming language and so on, but we didn't have the knowledge in the team techs to solve things, as we should have. Long lead times. I mean, everything we were trying to do had to follow the processes as we had. I mean that we should fill in some forms, send it away, hopefully someone was getting, getting back to us and saying, yeah guys, we can help you out with these services or this infrastructure, but it takes a really long time to do that. I mean, ordering infrastructure is when you're not an expert on that really hard to do. And often the orders we made or placed were wrong. When we have forms to fill in, it wasn't possible for us to do things automatically. Meaning that we didn't have the code, or the infrastructure as code. Meaning that if we didn't get the right persons into the meetings the first time, we didn't have the possibility to do it the right way, meaning that we had to redo and redo, and hopefully sometimes we got the right. We didn't have consistent set ups between the environments. When we order, as for example, a test environment, we could maybe order it with some minor resources, less CPU, so less memory, less disc or whatever. Or actually less performance on the hardware, but then we moved up to production. We realized that we have different hardware, different discs, different memories, and that could actually cause some serious problems in applications, access-wise. I mean, everyone likes to have exercise, especially if you are the maintainer of the system. That was really, really hard to get. I mean, every system has their own services, their own service, and therefore they need to apply for access to those other services. But today there's a complete difference since we only have one class to produce. Since we don't have infrastructure as a code back then, there were really lots of human errors. I mean, everyone was doing things manually. When you're coming from the Windows perspective, everything is a UI. You tend to prefer that way of working, meaning that if you used to click something in between the environments, the environments will not look the same. Life cycles. I mean, just imagine. When we have the server installed, it's like a pet. You have everything configured all from certificates to port openings, cartels, install patches, you name it. And then imagine that Windows are terminating a version and you need to reinstall that. Everything needs to be redone from the beginning. So there was a really long time taking to, to do the LCM activities, General lack of support of Microservice architecture was really also, a thing that are driving us forward with the containers technology, since we can't scale our applications in the same way as for containers. We, for example, couldn't have two applications or two processes using the same TCP port. For example, if you'd like to scale a web server, you can't do that on the same hardware. You need to have two different servers. And just imagine replacing all the excesses, replacing all the orders again for more hardware, and then manually a setting up there. The low balancer in front is a really huge task to do. And necessarily if you don't have the knowledge how the infrastructure is where you're working, then it's also really hard for you as a developer to do things right. Traditionalist. I mean, the services for us are like pets. They were really, really hard to set up. It'd take maybe a week or so. And if something was wrong with them, we will try to fix them as a pet. I mean, we couldn't just kill them and throw them away. It will actually destroy the application as this, our, like a unit box where all our things are installed. >> So, coming in from the infrastructure part of this, we've also seen challenges. For my team, we're coming from a Windows environment. So doing like a DevOps journey, which we want to do, makes it harder due to our nature in our environments. We are not used to, maybe use API, so we are not used to giving open APIs to our developers to do changes on the servers. Since we are a bank, we don't allow users to log into the servers, which means we have to do things for them all the time. This was very time consuming. And a lot of the challenges we actually still are seeing is the existing infrastructure. You can't just put that container platform on it, and thinking you're sold and everything. One of the biggest issues for us is, has been to getting servers. Windows servers usually takes like 15 minutes, Linux servers can takes up to two week in a bad day. So we really lack like, infrastructure as code. If we want a low balancer, that is also an order form. If we want the firewall opening, that's an order form. Hopefully they will not deny it. So it will go faster. So it's a lot of old processes that we need to go through. So what we wanted to do is that we want to move all of these things to the developers, so they can do it. They can own up their problems, but with our old infrastructure, that wasn't possible. We are a heavily ITIL-based organization, meaning that everything went from a cab. Still does in some way, we have one major service window every month where we take everything down. There is a lot of people involved in everything. So it's quite hard to know what will be done during the maintenance window. We lack supporting tools, or we lacked supporting tools, like log-in, good log-in tools. We have a bunch of CI/CD tools, but the maturity level of the infrastructure team wasn't that good. Again, order form and processes. If we want to, like, procure, do our procurement on a new like, storage system, or a backup system, we talk about here. So to do it is, for us, with containers, it would solve a lot of problems, because we cause we would then move the problems, not maybe move the problems to the developer, but we would make it able for them to own their own problems. So everything that we have talked about up till now boils down to business drivers. So the management's gave- gave us some policies to, or what they, how they want to change the company, so we can be this agile and fast moving bank. So one of the biggest drivers are cloud readiness, where Containers comes in perfectly. So we can build it on premises, and then we can move it to the cloud when we are ready but we can't, but we also need an exit strategy to move it back on premises if we need, due to hard regulations. Maybe you can throw it in the air. >> Absolutely. I definitely can. You're absolutely right. We need to develop things in a certain way. So we can move from infrastructure to infrastructure depending, or regardless of the vendor. Meaning that if we are able to run it on-prem, we should be able to run it in cloud or vice versa. We should also be able to move between clouds, and not be forced into one cloud provider. So that's really important for us at SEB. Short time to market is also a thing here. I mean, we are working with the huge customers. I can't name them, but they're really huge. And they need to have us being moving forward. I mean, able to really fast switch from one technology, maybe to another, we are here for them. And it's really important to us to be really fast for us to get new things out in production. All right, maybe. Nothing else? >> I don't, don't really. From the upside, we are in a huge staff DevOps transition. So, or a forced DevOps transition, which means we need to start looking at new infrastructure solutions, maybe deploy our infrastructure parts inside of containers to be able to use it the same way in the cloud. That's what we do prior, do here on premises, we have private clouds which are built on techno- technology, container technology today. So this fits quite good to have the Docker platform being one part of that one. >> Yeah. And this is solid, we are also working really, really actively on open source platforms and open source drivers. We can see that we have a huge amount of vendors in SEB, really huge ones, but we can also see that we can, facilitate open source platforms, and open source technology as well. So container technology will bring that for us. I mean, instead of having a SaaS platform and SaaS services, we can actually instantiate our own with containers and stuff. >> Also we are, since we are quite heavily regulated, the process of going through to you as like a SaaS service can take up to two years for us to go through, and then maybe the SaaS service, is it, is it what we want to use anymore? So, also we want to develop the things in our own premises and maybe, and scale it to the cloud if we need. And also we want to be an attractive employer, where maybe it's not that, the coolest thing for a young student to work in mainframe, we have a mainframe it's, it's not going anywhere, but it's hard to get people, and we want to be an attractive employer, and everyone is talking Kubernetics and containers or, and clouds. So we need to transition into those technologies. >> Yeah, we need to be open minded and necessarily facilitate the new technologies. So we can actually attract new employees. So it's really important to us to have an open mind. Our experience with Docker Containers. I mean, as I said before, scalability is a really important thing for us today. When we are using a more microservice architecture, we need to be able to Skype. We need to be scaling horizontally instead of vertically. So for that, containers are perfect storage. As we said before, we have a huge problem with environments being differently set up, since it was often manually done. Today, as we have a infrastructure as a code, it's really, really nice to have the same things exactly configured, the same in all environments. And we also have the same tooling, meaning that if I can run it on my machine, it's the same tooling I will be using to run it for test purposes or in production. That's a huge benefit for us as a developer. Time to market. I mean, today, we don't have to order service, we are using the service approach here. So we have a container cluster that are actually just sitting there waiting for our services to be hosted. So no more forms, no more calls, no more meetings before we can set up anything. We also own our problems. I mean, before, as I said, we have the processes, meaning that we ship our applications to any server. And then the operation sites take over. That's not the case now. We are actually using this as we should in DevOps. Meaning the other teams are actually responsible for all their errors as well. Even if it's on the infrastructure part, it's completely different if it's a platform's problem, because then it's the platform's team, and we can use different windows. We can try stuff out, we have an open mind. And that says that I can download and try any container image I would like on my developer machine. It's not maybe, okay to run it in production without having the security people look at it. But normally it's really, really much faster instead of waiting maybe six months, we can maybe wait one week or so. And of course less to none LCM activities. I mean, as I said before, it will take months, maybe, to do an LCM activity on multiple servers. Today, our LCM activities more or less are just switching to a new version of the image from Docker hub. That's all we have to do. So that's actually maintained during the processes we have in CI/CD pipelines. >> And the last one. So our keys to success: you should get demanded from the managers and management that everything should be a container. All the new development has to go through a container before you start ordering servers. Everything shall go through a CI/CD pipeline. We don't actually, here at SEB. Our developers build their own CI/CD pipeline. We just provide a platform for them to use it against, and the CI/CD to systems, but they build everything for themselves. Cause they know how their application works, how it should be deployed, with what tools. We just provide them with a tool set. Build a Cross Team. So you should incorporate all the processes that you need, but you should focus on the developer part, because you are building a platform for the developers, not for operations or security. >> And then maybe >> A lot of... >> you'll be able to take flight >> Yeah. Luck has nothing to do with it? Yes, it has. Of course, luck has something to do with it, even if you're really passionate, even if you're really good at some things. I mean, we got some really nice help from Dr. Inc. We were really... Came in with the technology in the right time for us to be, and we had really engaged people with these projects and that's a really luck for us to have. >> Yeah. And also we... I want to thank our colleagues, because we have another container team who started before us. And they have actually run into a lot of organizational problems, which they have sold, so we could piggyback on that, on those solutions. Also, start small and scale it. This is where Docker swarm comes, fits perfectly. So we have actually, we started with swarm. We are moving into Kubernetics in this platform. We will not force-move anything. The developers just should show us, what their- fits their needs. Thank you! >> Thank you very much.

>> Hello, everyone. I'm Khalil Ahmad, Senior Director, Architecture at S&P Global. I have been working with S&P Global for six years now. Previously, I worked for Citigroup and Prudential. Overall, I have been part of IT industry for 30 years, and most of my professional career has been within financial sector in New York City metro area. I live in New Jersey with my wife and son, Daniel Khalil. I have a Master degree in software engineering from the University of Scranton, and Master in mathematics University of Punjab, Lahore. And currently I am pursuing TRIUM global Executive MBA. A joint program from the NYU Stern, LSE and HEC Paris. So today, I'm going to talk about building multi-cluster scalable container platform, supporting on-prem hybrid and multicloud use cases, how we leverage that with an S&P Global and what was our best story. As far as the agenda is concerned, I will go over, quickly the problem statement. Then I will mention the work of our core requirements, how we get solutioning, how Docker Enterprise helped us. And at the end, I will go over the pilot deployment for a proof of concept which we leverage. So, as far as the problem statement is concerned. Containers, as you all know, in the enterprise are becoming mainstream but expertise remains limited and challenges are mounting as containers enter production. Some companies are building skills internally and someone looking for partners that can help catalyze success, and choosing more integrated solutions that accelerate deployments and simplify the container environment. To overcome the challenges, we at S&P Global started our journey a few years back, taking advantage of both options. So, first of all, we met with all the stakeholder, application team, Product Manager and we define our core requirements. What we want out of this container platform, which supports multicloud and hybrid supporting on-prem as well. So, as you see my core requirements, we decided that we need first of all a roadmap or container strategy, providing guidelines on standards and specification. Secondly, with an S&P Global, we decided to introduce Platform as a Service approach, where we bring the container platform and provide that as a service internally to our all application team and all the Product Managers. Hosting multiple application on-prem as well as in multicloud. Third requirement was that we need Linux and Windows container support. In addition to that, we would also require hosted secure image registry with role based access control and image security scanning. In addition to that, we also started DevOps journey, so we want to have a full support of CI/CD pipeline. Whatever the solution we recommend from the architecture group, it should be easily integrated to the developer workstation. And developer workstation could be Windows, Mac or Linux. Orchestration, performance and control were few other parameter which we'll want to keep in mind. And the most important, dynamic scaling of container clusters. That was something we were also want to achieve, when we introduce this Platform as a Service. So, as far as the standard specification are concerned, we turn to the Open Container Initiative, the OCI. OCI was established in June 2015 by Docker and other leaders in the technology industry. And OCI operates under Linux Foundation, and currently contains two specification, runtime specification and image specification. So, at that time, it was a no brainer, other than to just stick with OCI. So, we are following the industry standard and specifications. Now the next step was, okay, the container platform. But what would be our runtime engine? What would be orchestration? And how we support, in our on-prem as well as in the multicloud infrastructure? So, when it comes to runtime engine, we decided to go with the Docker. Which is by default, runtime engine and Kubernetes. And if I may mention, DataDog in one of their public report, they say Docker is probably the most talked about infrastructure technology for the past few years. So, sticking to Docker runtime engine was another win-win game and we saw in future not bringing any challenge or issues. When it comes to orchestration. We prefer Kubernetes but that time there was a challenge, Kubernetes did not support Windows container. So, we wanted something which worked with a Linux container, and also has the ability or to orchestrate Windows containers. So, even though long term we want to stick to Kubernetes, but we also wanted to have a Docker swarm. When it comes to on-prem and multicloud, technically you could only support as of now, technology may change in future, but as of now, you can only support if you bring your own orchestration too. So, in our case, if we have control over orchestration control and not locked in with one cloud provider, that was the ideal situation. So, with all that, research, R&D and finding, we found Docker Enterprise. Which is securely built, share and run modern applications anywhere. So, when we come across Docker Enterprise, we were pleased to see that it meets our most of the core requirements. Whether it is coming on the developer machine, to integrating their workstation, building the application. Whether it comes to sharing those application, in a secure way and collaborating with our pipeline. And the lastly, when it comes to the running. If we run in hybrid or multicloud or edge, in Kubernetes, Docker Enterprise have the support all the way. So, three area one I just call up all the Docker Enterprise, choice, flexibility and security. I'm sure there's a lot more features in Docker Enterprise as a suite. But, when we looked at these three words very quickly, simplified hybrid orchestration. Define application centric policies and boundaries. Once you define, you're all set. Then you just maintain those policies. Manage diverse application across mixed infrastructure, with secure segmentation. Then it comes to secure software supply chain. Provenance across the entire lifecycle of apps and infrastructure through enforceable policy. Consistently manage all apps and infrastructure. And lastly, when it comes to infrastructure independence. It was easily forever lift and shift, because same time, our cloud journey was in the flight. We were moving from on-prem to the cloud. So, support for lift and shift application was one of our wishlist. And Docker Enterprise did not disappoint us. It also supported both traditional and micro services apps on any infrastructure. So, here we are, Docker Enterprise. Why Docker Enterprise? Some of the items in previous slides I mentioned. But in addition to those industry-leading platform, simplifying the IT operations, for running modern application at scale, anywhere. Docker Enterprise also has developer tools. So, the integration, as I mentioned earlier was smooth. In addition to all these tools, the main two components, the Universal Control Plane and the Docker Trusted Registry, solve lot of our problems. When it comes to the orchestration, we have our own Universal Control Plane. Which under the hood, manages Kubernetes and Docker swarm both clusters. So, guess what? We have a Windows support, through Docker swarm and we have a Linux support through Kubernetes. Now that paradigm has changed, as of today, Kubernetes support Windows container. So, guess what? We are well after the UCP, because we have our own orchestration tool, and we start managing Kubernetes cluster in Linux and introduce now, Windows as well. Then comes to the Docker Trusted Registry. Integrated Security and role based access control, made a very smooth transition from our RT storage to DTR. In addition to that, binary level scanning was another good feature from the security point of view. So that, these all options and our R&D landed the Docker Enterprise is the way to go. And if we go over the Docker Enterprise, we can spin up multiple clusters on-prem and in the cloud. And we have a one centralized location to manage those clusters. >> Khalil: So, with all that, now let's talk about how what was our pilot deployment, for proof of concept. In this diagram, you can see we, on the left side is our on-prem Data Center, on the right side is AWS, US East Coast. We picked up one region three zones. And on-prem, we picked up our Data Center, one of the Data Center in the United States of America, and we started the POC. So, our Universal Control Plane had a five nodes cluster. Docker Trusted Registry, also has a five node cluster. And the both, but in our on-prem Data Center. When it comes to the worker nodes, we have started with 18 node cluster, on the Linux side and the four node cluster on the Windows side. Because the major footprint which we have was on the Linux side, and the Windows use cases were pretty small. Also, this is just a proof of concept. And in AWS, we mimic the same web worker nodes, virtual to what we have on-prem. We have a 13 nodes cluster on Linux. And we started with four node cluster of Windows container. And having the direct connect from our Data Center to AWS, which was previously existing, so we did not have any connectivity or latency issue. Now, if you see in this diagram, you have a centralized, Universal Control Plane and your trusted registry. And we were able to spin up a cluster, on-prem as well as in the cloud. And we made this happen, end to end in record time. So later, when we deploy this in production, we also added another cloud provider. So, what you see the box on the right side, we just duplicate test that box in another cloud platform. So, now other orchestration tool, managing on-prem and multicloud clusters. Now, in your use case, you may find this little, you know, more in favor of on-prem. But that fit in our use case. Later, we did have expanded the cluster of Universal Control Plane and DTR in the cloud as well. And the clusters have gone and hundreds and thousands of worker nodes span over two cloud providers, third being discussed. And this solution has been working so far, very good. We did not see any downtime, not a single instance. And we were able to provide multicloud platform, container Platform as a Service for our S&P Global. Thank you for your time. If any questions, I have put my LinkedIn and Twitter account holder, you're welcome to ask any question