>>Good afternoon, friends. My name is Savannah Peterson here in the Cube Studios live from Detroit, Michigan, where we're at Cuban and Cloud Native Foundation, Cloud Native Con all week. Our last interview of the day served me a real treat and one that I wasn't expecting. It turns out that I am in the presence of two caddies. It's a literal episode of Caddy Shack up here on Cube. John Furrier. I don't think the audience knows that you were a caddy. Tell us about your caddy days. >>I used to caddy when I was a kid at the local country club every weekend. This is amazing. Double loops every weekend. Make some bang, two bags on each shoulder. Caddying for the members where you're going. Now I'm >>On show. Just, just really impressive >>Now. Now I'm caddying for the cube where I caddy all this great content out to the audience. >>He's carrying the story of emerging brands and established companies on their cloud journey. I love it. John, well played. I don't wanna waste any more of this really wonderful individual's time, but since we now have a new trend of talking about everyone's Twitter handle here on the cube, this may be my favorite one of the day, if not Q4 so far. Drew, not reply. AKA Drew ne Drew Nielsen, excuse me, there is here with us from Teleport. Drew, thanks so much for being here. >>Oh, thanks for having me. It's great to be here. >>And so you were a caddy on a whole different level. Can you tell us >>About that? Yeah, so I was in university and I got tired after two years and didn't have a car in LA and met a pro golfer at a golf course and took two years off and traveled around caddying for him and tried to get 'em through Q School. >>This is, this is fantastic. So if you're in school and your parents are telling you to continue going to school, know that you can drop out and be a caddy and still be a very successful television personality. Like both of the gentlemen at some point. >>Well, I never said my parents like >>That decision, but we'll keep our day jobs. Yeah, exactly. And one of them is Cloud Native Security. The hottest topic here at the show. Yep. I want to get into it. You guys are doing some really cool things. Are we? We hear Zero Trust, you know, ransomware and we even, I even talked with the CEO of Dockets morning about container security issues. Sure. There's a lot going on. So you guys are in the middle of teleport. You guys have a unique solution. Tell us what you guys got going on. What do you guys do? What's the solution and what's the problem you solve? >>So Teleport is the first and only identity native infrastructure access solution in the market. So breaking that down, what that really means is identity native being the combination of secret list, getting rid of passwords, Pam Vaults, Key Vaults, Yeah. Passwords written down. Basically the number one source of breach. And 50 to 80% of breaches, depending on whose numbers you want to believe are how organizations get hacked. >>But it's not password 1 23 isn't protecting >>Cisco >>Right >>Now. Well, if you think about when you're securing infrastructure and the second component being zero trust, which assumes the network is completely insecure, right? But everything is validated. Resource to resource security is validated, You know, it assumes work from anywhere. It assumes the security comes back to that resource. And we take the combination of those two into identity, native access where we cryptographically ev, validate identity, but more importantly, we make an absolutely frictionless experience. So engineers can access infrastructure from anywhere at any time. >>I'm just flashing on my roommates, checking their little code, changing Bob login, you know, dongle essentially, and how frustrating that always was. I mean, talk about interrupting workflow was something that's obviously necessary, but >>Well, I mean, talk about frustration if I'm an engineer. Yeah, absolutely. You know, back in the day when you had these three tier monolithic applications, it was kind of simple. But now as you've got modern application development environments Yeah, multi-cloud, hybrid cloud, whatever marketing term around how you talk about this, expanding sort of disparate infrastructure. Engineers are sitting there going from system to system to machine to database to application. I mean, not even a conversation on Kubernetes yet. Yeah. And it's just, you know, every time you pull an engineer or a developer to go to a vault to pull something out, you're pulling them out for 10 minutes. Now, applications today have hundreds of systems, hundreds of microservices. I mean 30 of these a day and nine minutes, 270 minutes times 60. And they also >>Do the math. Well, there's not only that, there's also the breach from manual error. I forgot to change the password. What is that password? I left it open, I left it on >>Cognitive load. >>I mean, it's the manual piece. But even think about it, TR security has to be transparent and engineers are really smart people. And I've talked to a number of organizations who are like, yeah, we've tried to implement security solutions and they fail. Why? They're too disruptive. They're not transparent. And engineers will work their way around them. They'll write it down, they'll do a workaround, they'll backdoor it something. >>All right. So talk about how it works. But I, I mean, I'm getting the big picture here. I love this. Breaking down the silos, making engineers lives easier, more productive. Clearly the theme, everyone they want, they be gonna need. Whoever does that will win it all. How's it work? I mean, you deploying something, is it code, is it in line? It's, >>It's two binaries that you download and really it starts with the core being the identity native access proxy. Okay. So that proxy, I mean, if you look at like the zero trust principles, it all starts with a proxy. Everything connects into that proxy where all the access is gated, it's validated. And you know, from there we have an authorization engine. So we will be the single source of truth for all access across your entire infrastructure. So we bring machines, engineers, databases, applications, Kubernetes, Linux, Windows, we don't care. And we basically take that into a single architecture and single access platform that essentially secures your entire infrastructure. But more importantly, you can do audit. So for all of the organizations that are dealing with FedRAMP, pci, hipaa, we have a complete audit trail down to a YouTube style playback. >>Oh, interesting. We're we're California and ccpa. >>Oh, gdpr. >>Yeah, exactly. It, it, it's, it's a whole shebang. So I, I love, and John, maybe you've heard this term a lot more than I have, but identity native is relatively new to me as as a term. And I suspect you have a very distinct way of defining identity. How do you guys define identity internally? >>So identity is something that is cryptographically validated. It is something you have. So it's not enough. If you look at, you know, credentials today, everyone's like, Oh, I log into my computer, but that's my identity. No, it's not. Right. Those are attributes. Those are something that is secret for a period of time until you write it down. But I can't change my fingerprint. Right. And now I >>Was just >>Thinking of, well no, perfect case in point with touch ID on your meth there. Yeah. It's like when we deliver that cryptographically validated identity, we use these secure modules in like modern laptops or servers. Yeah. To store that identity so that even if you're sitting in front of your computer, you can't get to it. But more importantly, if somebody were to take that and try to be you and try to log in with your fingerprint, it's >>Not, I'm not gonna lie, I love the apple finger thing, you know, it's like, you know, space recognition, like it's really awesome. >>It save me a lot of time. I mean, even when you go through customs and they do the face scan now it actually knows who you are, which is pretty wild in the last time you wanna provide ones. But it just shifted over like maybe three months ago. Well, >>As long as no one chops your finger off like they do in the James Bond movies. >>I mean, we try and keep it a light and fluffy here on the queue, but you know, do a finger teams, we can talk about that >>Too. >>Gabby, I was thinking more minority report, >>But you >>Knows that's exactly what I, what I think of >>Hit that one outta bounds. So I gotta ask, because you said you're targeting engineers, not IT departments. What's, is that, because I in your mind it is now the engineers or what's the, is always the solution more >>Targeted? Well, if you really look at who's dealing with infrastructure on a day-to-day basis, those are DevOps individuals. Those are infrastructure teams, Those are site reliability engineering. And when it, they're the ones who are not only managing the infrastructure, but they're also dealing with the code on it and everything else. And for us, that is who is our primary customer and that's who's doing >>It. What's the biggest problem that you're solving in this use case? Because you guys are nailing it. What's the problem that your identity native solution solves? >>You know, right out of the backs we remove the number one source of breach. And that is taking passwords, secrets and, and keys off the board. That deals with most of the problem right there. But there are really two problems that organizations face. One is scaling. So as you scale, you get more secrets, you get more keys, you get all these things that is all increasing your attack vector in real time. Oh >>Yeah. Across teams locations. I can't even >>Take your pick. Yeah, it's across clouds, right? Any of it >>On-prem doesn't. >>Yeah. Any of it. We, and we allow you to scale, but do it securely and the security is transparent and your engineers will absolutely love it. What's the most important thing about this product Engineers. Absolutely. >>What are they saying? What are some of those examples? Anecdotally, pull boats out from engineering. >>You're too, we should have invent, we should have invented this ourselves. Or you know, we have run into a lot of customers who have tried to home brew this and they're like, you know, we spend an in nor not of hours on it >>And IT or they got legacy from like Microsoft or other solutions. >>Sure, yeah. Any, but a lot of 'em is just like, I wish I had done it myself. Or you know, this is what security should be. >>It makes so much sense and it gives that the team such a peace of mind. I mean, you never know when a breach is gonna come, especially >>It's peace of mind. But I think for engineers, a lot of times it deals with the security problem. Yeah. Takes it off the table so they can do their jobs. Yeah. With zero friction. Yeah. And you know, it's all about speed. It's all about velocity. You know, go fast, go fast, go fast. And that's what we enable >>Some of the benefits to them is they get to save time, focus more on, on task that they need to work on. >>Exactly. >>And get the >>Job done. And on top of it, they answer the audit and compliance mail every time it comes. >>Yeah. Why are people huge? Honestly, why are people doing this? Because, I mean, identity is just such an hard nut to crack. Everyone's got their silos, Vendors having clouds have 'em. Identity is the most fragmented thing on >>The planet. And it has been fragmented ever since my first RSA conference. >>I know. So will we ever get this do over? Is there a driver? Is there a market force? Is this the time? >>I think the move to modern applications and to multi-cloud is driving this because as those application stacks get more verticalized, you just, you cannot deal with the productivity >>Here. And of course the next big thing is super cloud and that's coming fast. Savannah, you know, You know that's Rocket. >>John is gonna be the thought leader and keyword leader of the word super cloud. >>Super Cloud is enabling super services as the cloud cast. Brian Gracely pointed out on his Sunday podcast of which if that happens, Super Cloud will enable super apps in a new architectural >>List. Please don't, and it'll be super, just don't. >>Okay. Right. So what are you guys up to next? What's the big hot spot for the company? What are you guys doing? What are you guys, What's the idea guys hiring? You put the plug in. >>You know, right now we are focused on delivering the best identity, native access platform that we can. And we will continue to support our customers that want to use Kubernetes, that want to use any different type of infrastructure. Whether that's Linux, Windows applications or databases. Wherever they are. >>Are, are your customers all of a similar DNA or are you >>No, they're all over the map. They range everything from tech companies to financial services to, you know, fractional property. >>You seem like someone everyone would need. >>Absolutely. >>And I'm not just saying that to be a really clean endorsement from the Cube, but >>If you were doing DevOps Yeah. And any type of forward-leaning shift, left engineering, you need us because we are basically making security as code a reality across your entire infrastructure. >>Love this. What about the team dna? Are you in a scale growth stage right now? What's going on? Absolutely. Sounds I was gonna say, but I feel like you would have >>To be. Yeah, we're doing, we're, we have a very positive outlook and you know, even though the economic time is what it is, we're doing very well meeting. >>How's the location? Where's the location of the headquarters now? With remote work is pretty much virtual. >>Probably. We're based in downtown Oakland, California. >>Woohoo. Bay area representing on this stage right now. >>Nice. Yeah, we have a beautiful office right in downtown Oakland and yeah, it's been great. Awesome. >>Love that. And are you hiring right now? I bet people might be. I feel like some of our cube watchers are here waiting to figure out their next big play. So love to hear that. Absolutely love to hear that. Besides Drew, not reply, if people want to join your team or say hello to you and tell you how brilliant you looked up here, or ask about your caddy days and maybe venture a guest to who that golfer may have been that you were CAD Inc. For, what are the best ways for them to get in touch with you? >>You can find me on LinkedIn. >>Great. Fantastic. John, anything else >>From you? Yeah, I mean, I just think security is paramount. This is just another example of where the innovation has to kind of break through without good identity, everything could cripple. Then you start getting into the silos and you can start getting into, you know, tracking it. You got error user errors, you got, you know, one of the biggest security risks. People just leave systems open, they don't even know it's there. So like, I mean this is just, just identity is the critical linchpin to, to solve for in security to me. And that's totally >>Agree. We even have a lot of customers who use us just to access basic cloud consoles. Yeah. >>So I was actually just gonna drive there a little bit because I think that, I'm curious, it feels like a solution for obviously complex systems and stacks, but given the utility and what sounds like an extreme ease of use, I would imagine people use this for day-to-day stuff within their, >>We have customers who use it to access their AWS consoles. We have customers who use it to access Grafana dashboards. You know, for, since we're sitting here at coupon accessing a Lens Rancher, all of the amazing DevOps tools that are out there. >>Well, I mean true. I mean, you think about all the reasons why people don't adopt this new federated approach or is because the IT guys did it and the world we're moving into, the developers are in charge. And so we're seeing the trend where developers are taking the DevOps and the data and the security teams are now starting to reset the guardrails. What's your >>Reaction to that? Well, you know, I would say that >>Over the top, >>Well I would say that you know, your DevOps teams and your infrastructure teams and your engineers, they are the new king makers. Yeah. Straight up. Full stop. >>You heard it first folks. >>And that's >>A headline right >>There. That is a headline. I mean, they are the new king makers and, but they are being forced to do it as securely as possible. And our job is really to make that as easy and as frictionless as possible. >>Awesome. >>And it sounds like you're absolutely nailing it. Drew, thank you so much for being on the show. Thanks for having today. This has been an absolute pleasure, John, as usual a joy. And thank all of you for tuning in to the Cube Live here at CU Con from Detroit, Michigan. We look forward to catching you for day two tomorrow.

>>Good afternoon everyone, and welcome back to Cuan where my cohost John Farer and I are broadcasting live, along with Lisa Martin from Cuan Detroit, Michigan. We are joined this afternoon by two very interesting gentlemen who also happen to be legends on the cube. John, how long have you known the next few? They've, >>They've made their mark on the cube with Jerry Chen from Greylock was one of our most attended cube guests. He's a VC partner at Greylock and an investor and this company that just launched their new cloud observability platform should be a great segment. >>Well, I'm excited. I are. Are you excited? Should I string this out just a little bit longer? No, I won't. I won't do that to you. Please welcome Martin and Jeff from Chronosphere Martin. Jeff, thank you so much for being >>Here. Thank you for having us. Thank you. >>I noticed right away that you have raised a mammoth series C. Yeah. 200 million if I'm not mistaken. >>That is correct. >>Where's the company at? >>Yeah, so we raised that series C a year ago. In fact, we were just talking about it a year ago at Cub Con. Since then, at the time we're about 80 employees or so. Since then, we've tripled the headcount, so we're over 200 people. Casual, triple casual, triple of the headcount. Yeah. Luckily it was the support of business, which is also tripled in the last year. So we're very lucky from that perspective as well. And a couple of other things we're pretty proud of last year. We've had a hundred percent customer retention, which is always a great thing to have as a SaaS platform there. >>Real metric if you've had a hundred percent. I'm >>Kidding. It's a good metric to, to put out there if you had a hundred percent. I would say for sure. It's an A for sure and exactly welcome to meet >>Anyone else who's had a hundred percent >>Customer attention here at coupon this week and 90% of our customers are using more of the service and, and you know, therefore paying more for the service as well. So those are great science for us and I think it shows that we're clearly doing something right on the product side. I would say. And >>Last and last time you're on the cube. We're talking about about the right data. Not so much a lot of data, if I remember correctly. Yeah, a hundred percent. And that was a unique approach. Yeah, it's a data world on relative observability. And you guys just launched a new release of your platform, cloud native platform. What's new in the platform? Can you share an update on what you guys release? >>Yeah, well we did and, and you, you bring up a great point. You know, like it's not just in observably but overall data is exploding. Alright, so three things there. It's like, hey, can your platform even handle the explosion of data? Can it control it over time and make sure that as your business grows, the data doesn't continue explode at the same time. And then for the end users, can they make sense of all this data? Cuz what's the point of having it if the end users can't make sense of it? So actually our product announcement this time is a pretty big refresh of, of a lot of features in our, in our platform. And it actually tackles all three of these particular components. And I'll let Jeff, our head of product, Doug, >>You, you run product, you get the keys to the kingdom, I do product roadmap. People saying, Hey this, take this out. You're under a lot of pressure. What makes the platform platform a great observability product? >>So the keystone of what we do that's different is helping you control the data, right? As we're talking about there's an infinite amount of data. These systems are getting more and more and more complicated. A lot of what we do is help you understand the utility of the telemetry so that you can optimize for keeping and storing and paying for the data that's actually helpful as opposed to the stuff that isn't. >>What's the benefit now with observability, with all the noise out in the marketplace, there's been a shift over the past couple years. Cloud native at scale, you're seeing a lot more automation, almost a set to support the growth for more application development. We had a Docker CEO on earlier today, he said there are more applications being deployed in the past year than in the history of open source. So more and more apps are being deployed, more data's being generated. What's the key to observability right now that's gonna separate the winners from the losers? >>Yeah, I think, you know, not only are there more applications being deployed, but there are smaller and small applications being deployed mostly on containers these days more than if they, hence this conference gets larger and larger every year. Right? So, you know, I think the key is a can your system handle this data explosion is, is the first thing. Not only can it handle the data explosion, but you know, APM solutions have been around for a very long time and those were really introspecting into an application. Whereas these days what's more important is, well how is your application interfacing with every other application in your distributed architecture there, right? So the use case is slightly different there. And then to what Jeff was saying is like once the data is there, not only making use of what is actually useful to you, but then having the end user make sense of it. >>Because we, we, we always think about the technology changes. We forget that the end users are different now we used to have IT operations team operating everything and the developers would write the application, just throw it over the wall. These days the developers have to actually operate this thing in production. So the end users of these systems are very different as well. And you can imagine these are folks, your average developer as maybe not operated things for many years in production before. So they need to, that they need to pick up a new skill set, they need to use new tooling in order to, to do that. So yeah, it's, it's, >>And you got the developer persona, you got a developer that's building products for builders and developers that are building products to be consumed. So they're not, they're not really infrastructure builders, they're just app developers. >>Exactly. Exactly. That's right. And that's what a lot of the new functionality that we're introducing here at the show is all about is helping developers who build software by day and are on call by night, actually get in context. There's so much data chances of when that, when one of those pages goes off and your number comes up, that the problem happens to be in the part of the system that you know a lot about are pretty low, chances are you're gonna get bothered about something else. So we've built a feature, we call it collections that's about putting you in the right context and connecting you into the piece of the system where the problem is to orient you and to get you started. So instead of waiting through, through hundreds of millions of things, you're waiting through the stuff that's in the immediate neighborhood of where the >>Problem is. Yeah. To your point about data, you can't let it go unchecked. That's right. You gotta gotta understand that. And we were talking about containers again with, again with docker, you know, nuance point, but oh, scan your container. But not everyone's scanning the containers security nightmare, right? I mean, >>Well I think one of the things that I, I loved in reading the notes in preparation for you coming up is you've actually created cloud native observability with the goal of eliminating engineering burnout. And what you're talking about there is actually the cognitive burden of when things happen. Yeah, for sure. We we're, you know, we're not just designing for when everything goes right, You need to be prepared for when everything goes wrong and that poor lonely individual in the middle of the night has, it's >>A tough job. >>Has to navigate that >>And, and observability is just one thing you gotta mean like security is another thing. So, so many more things have been piled on top of the developer in addition to actually creating the application. Right? It is. There is a lot. And you know, observably is one of those key things you need to do your job. So as much as, as much as we can make that easier, that's a better bit. Like there are so many things being piled on right now. >>That's the holy grail right there. Because they don't want to be doing exactly >>The work. Exactly. They're not observability experts. >>Exactly. And automating that in. So where do you guys weigh in on the automation wave? Everything's automation. Yeah. Is that kind of a hand waving or what's going on? What's the reality? What's actually happening? >>Yeah, I think automation I think is key. You hear a lot of ai ml ops there. I, I don't know if I really believe in that or having a machine self heal itself or anything like that. But I think automation is key because there are a lot of repeatable tasks in a lot of what you're doing. So once you detect that something goes wrong, generally if you've seen it before, you know what the fix is. So I think automation plays a key on the sense that once it's detected again the second time, the third time, okay, I know what I did the previous time, let, let's make sure we can do that again. So automation I think is key. I think it helps a lot with the burnout. I dunno if I'd go as far as the >>Same burnout's a big deal. >>Well there's an example again in the, in the stuff we're releasing this week, a new feature we call query accelerator. That's a form of automation. Problem is you got all this data, mountain of data, put you in the right context so you're at least in the right neighborhood, but now you need to query it. You gotta get the data to actually inform the specific problem you're trying to solve. And the burden on the developer in that situation is really high. You have to know what you're looking for and you have to know how to efficiently ask for it. So you're not waiting for a long time and >>We >>Built a feature, you tell us what you want, we will figure out how to get it for you efficiently. That's the kind of automation that we're focused on. That's actually a good service. How can we, it >>Sounds >>Blissful. How can we accelerate and optimize what you were gonna do anyway, rather than trying to read your mind or predict the future. >>Yes, >>Savannah, some community forward. Yeah, I, I'm, so I'm curious, you, you clearly lead with a lot of empathy, both of you and, and putting your, well you probably have experience with this as well, but putting your mind or putting yourself in the mind to the developer are, what's that like for you from a product development standpoint? Are you doing a lot of community engagement? Are you talking to developers to try and anticipate what they're gonna be needing next in terms of, of your offering? Or how has that work >>For you? Oh, for sure. So, so I run product, I have a lot of product managers who work for me. Somebody that I used to work with, she was accusing me, but what she called, she called me an anthropologist of a product manager. I >>Get these kind of you, the very good design school vibes from you both of you, which >>Is, and the reason why she said the way you do this, you go and you live with them in order to figure out what a day in their life is really like, what the job is really like, what's easy, what's hard. And that's what we try to aim at and try to optimize for. So that's very much the way that we do all of >>Our work. And that's really also highlights the fact that we're in a market that requires acute realtime data from the customer. Cause it's, and it's all new data. Well >>Yeah, it's all changing. The tools change every day. I mean if we're not watching how, and >>So to your point, you need it in real time as well. The whole point of moving to cloud native is you have a reliable product or service there. And like if you need to wait a few minutes to even know that something's wrong, like you've already lost at that point, you've already lost a ton of customers, potentially. You've already lost a ton of business. You know, to your point about the, the community earlier, one other thing we're trying to do is also give back to the community a little bit. So actually two days ago we just announced the open source of a tool that we've been using in our product for a very long time. But of course our product is, is a paid product, right? But actually open source a part of that tool thus that the broader community can benefit as well. And that tool which, which tool is that? It's, it's called Prom lens. And it's actually the Prometheus project is the open sourced metrics project that everybody uses. So this is a query builder that helps developers understand how to create queries in a much more efficient way. We've had in our product for a long time, but we're like, let's give that back to the community so that the broader community of developers out there can have a much easier time creating these queries as well. What's >>Been the feedback? >>We only now it's two days ago so I'm not, I'm not exactly sure. I imagine >>It's great. They're probably playing with it right now. >>Exactly. Exactly. Exactly. For sure. I imagine. Great. >>Yeah, you guys mentioned burnout before and we heard this a lot now you mentioned in terms of data we've been hearing and reporting about Insta security world, which is also data specific observability ties right into security. Yep. How does a company figure out, first of all, burnout's a big problem. It's more and more data coming. It's like, it's like doesn't stop and the breaches are coming too. How does a company know when they need that their observability strategy is broken? Is there sig signs of you know, burnout? Is there signs of breaches? I mean, what are some of the tell signs that if I'm a CSO I go, you know what, maybe I should check out promisee. When do, when do you guys match in and go we're a perfect fit to solve that problem? >>Yeah, I, I would say, you know, because we're focused on the observability side, less so on the security side, some of those signals are like how many incidents do you have? How many outages do you have? What's the occurrence of these things and how long does it take to recover from from from these particular incidents? How >>Upsetting are we finding customers? >>Upsetting are >>Customer. Exactly. >>And and one trend was seeing >>Not churn happening. Exactly. >>And one trend we're seeing in the industry is that 68% of companies are saying that they're having more incidents over time. Right. And if you have more incidents, you can imagine more engineers are being paid, are being woken up and they're being put under more stress. And one thing you said that very interesting is, you know, I think generally in the observability world, you ideally actually don't want to figure out the problem when it goes wrong. Ideally what you want to do these days is figure out how do I remediate this and get the business back to a running state as quickly as I can. And then when the business isn't burning, let me go and figure out what the underlying root cause is. So the strategy there is changed as well from the APM days where like I don't want to figure out the problem in real time. I wanna make sure my business and my service is running as it should be. And then separately from that, once it is then I wanna go >>Under understand that assume it's gonna happen, be ready to close that isolate >>The >>Fire. Exactly. Exactly. And, and you know, you can imagine, you know the whole movement towards C I C D, like generally when you don't touch a system, nothing goes wrong. You deploy change, first thing you do is not figure out why you change break thing. Get that back like underplay that change roll that change back, get your business back to a estate and then take the time where you're not under pressure, you're not gonna be burnt out to figure out what was it about my change that that broke everything. So, yeah. Got >>It. >>Well it's not surprising that you've added some new exciting customers to the roster. We have. We have. You want to tell the audience who they might >>Be? Yes. It's been a few big names in the last year we're pretty excited about. One is Snapchat, I think everybody knows, knows that application And one is Robin Hood. So you know, you can imagine very large, I'll say tech forward companies that have completed their migrations to, to cloud native or a wallet on their way to Cloudnative and, and we like helping those customers for sure. We also like helping a lot of startups out there cause they start off in the cloud native world. Like if you're gonna build a business today, you're gonna use Kubernetes from day one. Right? But we're actually interestingly seeing more and more of is traditional enterprises who are just early, pretty early on in their cloudnative migration then now starting to adopt cloud native at scale and now they're running to the same problems. As well >>Said, the Gartner data last year was something like 85% of companies had not made that transformation. Right. So, and that, I mean that's looking at larger scale companies, obviously >>A hundred, you're >>Right on the pulse. They >>Have finished it, but a lot of them are starting it now. So we're seeing pilot >>Projects, testing and cadence. And I imagine it's a bit of a different pace when you're working with some of those transforming companies versus those startups that are, are just getting rolling. I >>Love and you know, you have a lot of legacy use case you have to, like, if you're a startup, you can imagine there's no baggage, there's no legacy. You're just starting brand new, right? If you're a large enterprise, you have to really think about, okay, well how do I get my active business moved over? But yeah. >>Yeah. And how do you guys see the whole cloud native scale moving with the hyper scales? Like aws? You've got a lot of multi-cloud conversation. We call it super cloud in our narrative, but there's now this new, we're gonna get some of common services being identified. We're seeing a, we're seeing a lot more people recognize and with Kubernetes that hey, you know what, you could get some common services maybe across clouds with SOS doing storage. We got Min iOS doing some storage. Yeah. Cloud flare, I mean starting to see a lot more non-hyper scale systems. >>Yeah, I mean I, and I think that's the pattern there and I think it, it's, especially for enterprise at the top end, right? You see a, a lot of companies are trying to de-risk by saying, Hey, I, I don't want to bet maybe on one cloud provider, I sort of need to hedge my bets a little bit. And Kubernetes is a great tool to go do that. You can imagine some of these other tools you mentioned is a great way to do that. Observability is another great way to do that. Or the cloud providers have their observability or monitoring tooling, but it's really optimized just for that cloud provider, just for those services there. So if you're really trying to run either your custom applications or a multi-cloud approach, you really can't use one cloud providers solution to go solve that problem. Do you >>Guys see yourselves with that unifying >>Layer? We, we, we are a little bit as that lay because it's agnostic to each of the cloud providers. And the other thing is we actually like to understand where our customers run and then try to run their observability stack on a different cloud provider. Cuz we use the cloud ourselves. We're not running our own data centers of course, but it's an interesting thing where everybody has a common dependency on the cloud provider. So when us e one ofs hate to call them out, but when us E one ofs goes down, imagine half the internet goes down, right? And that's the time that you actually need observability. Right? Seriously. And every other tooling there. So we try to find out where do you run and then we try to actually run you elsewhere. But yeah, >>I like that. And nobody wants to see the ugly bits anyway. Exactly. And we all know who when we're all using someone when everything >>Exactly. Exactly, exactly. >>People off the internet. So it's very, I, I really love that. Martin, Jeff, thank you so much for being here with us. Thank you. What's next? What, how do people find out, how do they get one of the jobs since three Xing your >>Employee growth? We're hiring a lot. I think the best thing is to go check out our website chronosphere.io. You'll find out a lot about our, our, our careers, our job openings, the culture we're trying to build here. Find out a lot about the product as well. If you do have an observability problem, like that's the best place to go to find out about that as well. Right. >>Fantastic. Well if you want to join a quarter billion, a quarter of a billion dollar rocket ship over here and certainly a unicorn, get in touch with Martin and Jeff. John, thank you so much for joining me for this very special edition and thank all of you for tuning in to the Cube live here from Motor City. My name's Savannah Peterson and we'll see you in a little bit. >>Robert Herbeck. People obviously know you from Shark Tanks, but the Herbeck group has been really laser focused on cyber security. So I actually helped to bring my.

(upbeat music) >> The cloud is evolving. You know, it's no longer a set of remote services somewhere off in the cloud, in the distance. It's expanding. It's moving to on-prem. On-prem workloads are connecting to the cloud. They're spanning clouds in a way that hides the plumbing and simplifies deployment, management, security, and governance. So hybrid multicloud is the next big thing in infrastructure, and at the recent Nutanix .NEXT conference, we got a major dose of that theme, and with me to talk about what we heard at that event, what we learned, why it matters, and what it means to customers are Monica Kumar, who's the senior vice president of marketing and cloud go-to-market at Nutanix, and Tarkan Maner, who's the chief commercial officer at Nutanix. Guys, great to see you again. Welcome to the theCUBE. >> Great to be back here. >> Great to see you, Dave. >> Okay, so you just completed another .NEXT. As an analyst, I like to evaluate the messaging at an event like this, drill into the technical details to try to understand if you're actually investing in the things that you're promoting in your keynotes, and then talk to customers to see how real it is. So with that as a warning, you guys are all in on hybrid multicloud, and I have my takeaways that I'd be happy to share, but, Tarkan, what were your impressions, coming out of the event? >> Look, you had a great entry. Our goal, as Monica is going to outline, too, cloud is not a destination. It's an operating model. Our customers are basically using cloud as a business model, as an operating model. It's not just a bunch of techno mumbo-jumbo, as, kind of, you outlined. We want to make sure we make cloud invisible to the customer so they can focus on what they need to focus on as a business. So as part of that, we want to make sure the workloads, the apps, they can run anywhere the way the customer wants. So in that context, you know, our entire story was bringing customer workloads, use-cases, partner ecosystem with ISVs and cloud providers and service providers and ISPs we're working with like Citrix on end user computing, like Red Hat on cloud native, and also bringing the right products, both in terms of infrastructure capability and management capability for both operators and application developers. So bringing all these pieces together and make it simple for the customer to use the cloud as an operating model. That was the biggest goal here. >> Great, thank you. Monica, anything you'd add in terms of your takeaways? >> Well, I think Tarkan said it right. We are here to make cloud complexity invisible. This was our big event to get thousands of our customers, partners, our supporters together and unveil our product portfolio, which is much more simplified, now. It's a cloud platform. And really have a chance to show them how we are building an ecosystem around it, and really bringing to life the whole notion of hybrid multicloud computing. >> So, Monica, could you just, for our audience, just summarize the big news that came out of .NEXT? >> Yeah, we actually made four different announcements, and most of them were focused around, obviously, our product portfolio. So the first one was around enhancements to our cloud platform to help customers build modern, software-defined data centers to speed their hybrid multicloud deployments while supporting their business-critical applications, and that was really about the next version of our flagship, AOS six, availability. We announced the general availability of that, and key features really included things like built-in virtual networking, disaster recovery enhancements, security enhancements that otherwise would need a lot of specialized hardware, software, and skills are now built into our platform. And, most importantly, all of this functionality being managed through a single interface, right? Which significantly decreases the operational overhead. So that was one announcement. The second announcement was focused around data services and really making it easy for customers to simplify data management, also optimize big data and database workloads. We announced capability that now improves performances of database workloads by 2x, big data workloads by 3x, so lots of great stuff there. We also announced a new service called Nutanix Data Lens, which is a new unstructured data governance service. So, again, I don't want to go into a lot of details here. Maybe we can do it later. That was our second big announcement. The third announcement, which is really around partnerships, and we'll talk more about that, is with Microsoft. We announced the preview of Nutanix Clusters and Azure, and that's really taking our entire flagship Nutanix platform and running it on Azure. And so, now, we are in preview on that one, and we're super excited about that. And then, last but not least, and I know Tarkan is going to go into a lot more detail, is we announced a strategic partnership with Citrix around the whole future of hybrid work. So lots of big news coming out of it. I just gave you a quick summary. There's a lot more around this, as well. >> Okay. Now, I'd like to give you my honest take, if you guys don't mind, and, Tarkan, I'll steal one of your lines. Don't hate me, okay? So the first thing I'm going to say is I think, Nutanix, you have the absolute right vision. There's no question in my mind. But what you're doing is not trivial, and I think it's going to play out. It's going to take a number of years. To actually build an abstraction layer, which is where you're going, as I take it, as a platform that can exploit all the respective cloud native primitives and run virtually any workload in any cloud. And then what you're doing, as I see it, is abstracting that underlying technology complexity and bringing that same experience on-prem, across clouds, and as I say, that's hard. I will say this: the deep dives that I got at the analyst event, it convinced me that you're committed to this vision. You're spending real dollars on focused research and development on this effort, and, very importantly, you're sticking to your true heritage of making this simple. Now, you're not alone. All the non-hyperscalers are going after the multicloud opportunity, which, again, is really challenging, but my assessment is you're ahead of the game. You're certainly focused on your markets, but, from what I've seen, I believe it's one of the best examples of a true hybrid multicloud-- you're on that journey-- that I've seen to date. So I would give you high marks there. And I like the ecosystem-building piece of it. So, Tarkan, you could course-correct anything that I've said, and I'd love for you to pick up on your comments. It takes a village, you know, you're sort of invoking Hillary Clinton, to bring the right solution to customers. So maybe you could talk about some of that, as well. >> Look, actually, you hit all the right points, and I don't hate you for that. I love you for that, as you know. Look, at the end of the day, we started this journey about 10 years ago. The last two years with Monica, with the great executive team, and overall team as a whole, big push to what you just suggested. We're not necessarily, you know, passionate about cloud. Again, it's a business model. We're passionate about customer outcomes, and some of those outcomes sometimes are going to also be on-prem. That's why we focus on this terminology, hybrid multicloud. It is not multicloud, it's not just private cloud or on-prem and non-cloud. We want to make sure customers have the right outcomes. So based on that, whether those are cloud partners or platform partners like HPE, Dell, Supermicro. We just announced a partnership with Supermicro, now, we're selling our software. HPE, we run on GreenLake. Lenovo, we run on TruScale. Big support for Lenovo. Dell's still a great partner to us. On cloud partnerships, as Monica mentioned, obviously Azure. We had a big session with AWS. Lots of new work going on with Red Hat as an ISV partner. Tying that also to IBM Cloud, as we move forward, as Red Hat and IBM Cloud go hand in hand, and also tons of workarounds, as Monica mentioned. So it takes a village. We want to make sure customer outcomes deliver value. So anywhere, for any app, on any infrastructure, any cloud, regardless standards or protocols, we want to make sure we have an open system coverage, not only for operators, but also for application developers, develop those applications securely and for operators, run and manage those applications securely anywhere. So from that perspective, tons of interest, obviously, on the Citrix or the UC side, as Monica mentioned earlier, we also just announced the Red Hat partnership for cloud services. Right before that, next we highlighted that, and we are super excited about those two partnerships. >> Yeah, so, when I talked to some of your product folks and got into the technology a little bit, it's clear to me you're not wrapping your stack in containers and shoving it into the cloud and hosting it like some do. You're actually going much deeper. And, again, that's why it's hard. You could take advantage of those things, but-- So, Monica, you were on the stage at .NEXT with Eric Lockhart of Microsoft. Maybe you can share some details around the focus on Azure and what it means for customers. >> Absolutely. First of all, I'm so grateful that Eric actually flew out to the Bay Area to be live on stage with us. So very super grateful for Eric and Azure partnership there. As I said earlier, we announced the preview of Nutanix Clusters and Azure. It's a big deal. We've been working on it for a while. What this means is that a select few organizations will have an opportunity to get early access and also help shape the roadmap of our offering. And, obviously, we're looking forward to then announcing general availability soon after that. So that's number one. We're already seeing tremendous interest. We have a large number of customers who want to get their hands on early access. We are already working with them to get them set up. The second piece that Eric and I talked about really was, you know, the reason why the work that we're doing together is so important is because we do know that hybrid cloud is the preferred IT model. You know, we've heard that in spades from all different industries' research, by talking to customers, by talking to people like yourselves. However, when customers actually start deploying it, there's lots of issues that come up. There's limited skill sets, resources, and, most importantly, there's a disparity between the on-premises networking security management and the cloud networking security management. And that's what we are focused on, together as partners, is removing that barrier, the friction between on-prem and Azure cloud. So our customers can easily migrate their workloads in Azure cloud, do cloud disaster recovery, create a burst into cloud for elasticity if they need to, or even use Azure as an on-ramp to modernize applications by using the Azure cloud services. So that's one big piece. The second piece is our partnership around Kubernetes and cloud native, and that's something we've already provided to the market. It's GA with Azure and Nutanix cloud platform working together to build Kubernetes-based applications, container-based applications, and run them and manage them. So there's a lot more information on nutanix.com/azure. And I would say, for those of our listeners who want to give it a try and who want their hands on it, we also have a test drive available. You can actually experience the product by going to nutanix.com/azure and taking the test drive. >> Excellent. Now, Tarkan, we saw recently that you announced services. You've got HPE GreenLake, Lenovo, their Azure service, which is called TruScale. We saw you with Keith White at HPE Discover. I was just with Keith White this week, by the way, face to face. Awesome guy. So that's exciting. You got some investments going on there. What can you tell us about those partnerships? >> So, look, as we talked through this a little bit, the HPE relationship is a very critical relationship. One of our fastest growing partnerships. You know, our customers now can run a Nutanix software on any HPE platform. We call it DX, is the platform. But beyond that, now, if the customers want to use HPE service as-a-service, now, Nutanix software, the entire stack, it's not only hybrid multicloud platform, the database capability, EUC capability, storage capability, can run on HPE's service, GreenLake service. Same thing, by the way, same way available on Lenovo. Again, we're doing similar work with Dell and Supermicro, again, giving our customers choice. If they want to go to a public club partner like Azure, AWS, they have that choice. And also, as you know, I know Monica, you're going to talk about this, with our GSI partnerships and new service provider program, we're giving options to customers because, in some other regions, HPE might not be their choice or Azure not be choice, and a local telco might the choice in some country like Japan or India. So we give options and capability to the customers to run Nutanix software anywhere they like. >> I think that's a really important point you're making because, as I see all these infrastructure providers, who are traditionally on-prem players, introduce as-a-service, one of the things I'm looking for is, sure, they've got to have their own services, their own products available, but what other ecosystem partners are they offering? Are they truly giving the customers choice? Because that's, really, that's the hallmark of a cloud provider. You know, if we think about Amazon, you don't always have to use the Amazon product. You can use actually a competitive product, and that's the way it is. They let the customers choose. Of course, they want to sell their own, but, if you innovate fast enough, which, of course, Nutanix is all about innovation, a lot of customers are going to choose you. So that's key to these as-a-service models. So, Monica, Tarkan mentioned the GSIs. What can you tell us about the big partners there? >> Yeah, definitely. Actually, before I talk about GSIs, I do want to make sure our listeners understand we already support AWS in a public cloud, right? So Nutanix totally is available in general, generally available on AWS to use and build a hybrid cloud offering. And the reason I say that is because our philosophy from day one, even on the infrastructure side, has been freedom of choice for our customers and supporting as large a number of platforms and substrates as we can. And that's the notion that we are continuing, here, forward with. So to talk about GSIs a bit more, obviously, when you say one platform, any app, any cloud, any cloud includes on-prem, it includes hyperscalers, it includes the regional service providers, as well. So as an example, TCS is a really great partner of ours. We have a long history of working together with TCS, in global 2000 accounts across many different industries, retail, financial services, energy, and we are really focused, for example, with them, on expanding our joint business around mission critical applications deployment in our customer accounts, and specifically our databases with Nutanix Era, for example. Another great partner for us is HCL. In fact, HCL's solution SKALE DB, we showcased at .NEXT just yesterday. And SKALE DB is a fully managed database service that HCL offers which includes a Nutanix platform, including Nutanix Era, which is our database service, along with HCL services, as well as the hardware/software that customers need to actually run their business applications on it. And then, moving on to service providers, you know, we have great partnerships like with Cyxtera, who, in fact, was the service provider partner of the year. That's the award they just got. And many other service providers, including working with, you know, all of the edge cloud, Equinix. So, I can go on. We have a long list of partnerships, but what I want to say is that these are very important partnerships to us. All the way from, as Tarkan said, OEMs, hyperscalers, ISVs, you know, like Red Hat, Citrix, and, of course, our service provider, GSI partnerships. And then, last but not least, I think, Tarkan, I'd love for you to maybe comment on our channel partnerships as well, right? That's a very important part of our ecosystem. >> No, absolutely. You're absolutely right. Monica. As you suggested, our GSI program is one of the best programs in the industry in number of GSIs we support, new SP program, enterprise solution providers, service provider program, covering telcos and regional service providers, like you suggested, OVH in France, NTT in Japan, Yotta group in India, Cyxtera in the US. We have over 50 new service providers signed up in the last few months since the announcement, but tying all these things, obviously, to our overall channel ecosystem with our distributors and resellers, which is moving very nicely. We have Christian Alvarez, who is running our channel programs globally. And one last piece, Dave, I think this was important point that Monica brought up. Again, give choice to our customers. It's not about cloud by itself. It's outcomes, but cloud is an enabler to get there, especially in a hybrid multicloud fashion. And last point I would add to this is help customers regardless of the stage they're in in their cloud migration. From rehosting to replatforming, repurchasing or refactoring, rearchitecting applications or retaining applications or retiring applications, they will have different needs. And what we're trying to do, with Monica's help, with the entire team: choice. Choice in stage, choice in maturity to migrate to cloud, and choice on platform. >> So I want to close. First of all, I want to give some of my impressions. So we've been watching Nutanix since the early days. I remember vividly standing around the conference call with my colleague at the time, Stu Miniman. The state-of-the-art was converged infrastructure, at the time, bolting together storage, networking, and compute, very hardware centric. And the founding team at Nutanix told us, "We're going to have a software-led version of that." And you popularized, you kind of created the hyperconverged infrastructure market. You created what we called at the time true private cloud, scaled up as a company, and now you're really going after that multicloud, hybrid cloud opportunity. Jerry Chen and Greylock, they just wrote a piece called Castles on the Cloud, and the whole concept was, and I say this all the time, the hyperscalers, last year, just spent a hundred billion dollars on CapEx. That's a gift to companies that can add value on top of that. And that's exactly the strategy that you're taking, so I like it. You've got to move fast, and you are. So, guys, thanks for coming on, but I want you to both-- maybe, Tarkan, you can start, and Monica, you can bring us home. Give us your wrap up, your summary, and any final thoughts. >> All right, look, I'm going to go back to where I started this. Again, I know I go back. This is like a broken record, but it's so important we hear from the customers. Again, cloud is not a destination. It's a business model. We are here to support those outcomes, regardless of platform, regardless of hypervisor, cloud type or app, making sure from legacy apps to cloud native apps, we are there for the customers regardless of their stage in their migration. >> Dave: Right, thank you. Monica? >> Yeah. And I, again, you know, just the whole conversation we've been having is around this but I'll remind everybody that why we started out. Our journey was to make infrastructure invisible. We are now very well poised to helping our customers, making the cloud complexity invisible. So our customers can focus on business outcomes and innovation. And, as you can see, coming out of .NEXT, we've been firing on all cylinders to deliver this differentiated, unified hybrid multicloud platform so our customers can really run any app, anywhere, on any cloud. And with the simplicity that we are known for because, you know, our customers love us. NPS 90 plus seven years in a row. But, again, the guiding principle is simplicity, portability, choice. And, really, our compass is our customers. So that's what we are focused on. >> Well, I love not having to get on planes every Sunday and coming back every Friday, but I do miss going to events like .NEXT, where I meet a lot of those customers. And I, again, we've been following you guys since the early days. I can attest to the customer delight. I've spent a lot of time with them, driven in taxis, hung out at parties, on buses. And so, guys, listen, good luck in the next chapter of Nutanix. We'll be there reporting and really appreciate your time. >> Thank you so much. >> Thank you so much, Dave. >> All right, and thank you for watching, everybody. This is Dave Vellante for theCUBE, and, as always, we'll see you next time. (light music)

(bright music) >> Welcome to this next session of AWS Storage Day. I'm your host, Dave Vellante of theCUBE. And right now we're going to explore how to simplify and evolve your data lake backup disaster recovery and analytics in the cloud. And we're joined by Kevin Miller who's the general manager of Amazon S3. Kevin, welcome. >> Thanks Dave. Great to see you again. >> Good to see you too. So listen, S3 started as like a small ripple in the pond and over the last 15 years, I mean, it's fundamentally changed the storage market. We used to think about storage as, you know, a box of disc drives that either store data in blocks or file formats and then object storage at the time it was, kind of used in archival storage, it needed specialized application interfaces, S3 changed all that. Why do you think that happened? >> Well, I think first and foremost, it's really just, the customers appreciated the value of S3 and being fully managed where, you know, we manage capacity. Capacity is always available for our customers to bring new data into S3 and really therefore to remove a lot of the constraints around building their applications and deploying new workloads and testing new workloads where they know that if something works great, it can scale up by a 100x or a 1000x. And if it doesn't work, they can remove the data and move on to the next application or next experiment they want to try. And so, you know, really, it's exciting to me. Really exciting when I see businesses across essentially every industry, every geography, you know, innovate and really use data in new and really interesting ways within their business to really drive actual business results. So it's not just about building data, having data to build a report and have a human look at a report, but actually really drive the day-to-day operations of their business. So that can include things like personalization or doing deeper analytics in industrial and manufacturing. A customer like Georgia-Pacific for example, I think is one of the great examples where they use a big data lake and collect a lot of sensor data, IoT sensor data off of their paper manufacturing machines. So they can run them at just the right speed to avoid tearing the paper as it's going through, which really just keeps their machines running more and therefore, you know, just reduce their downtime and costs associated with it. So you know, it's just that transformation again, across many industries, almost every industry that I can think of. That's really what's been exciting to see and continue to see. I think we're still in the really early days of what we're going to see as far as that innovation goes. >> Yeah, I got to agree. I mean, it's been pretty remarkable. Maybe you could talk about the pace of innovation for S3. I mean, if anything, it seems to be accelerating. How Kevin, does AWS, how has it thought about innovation over the past decade plus and where do you see it headed? >> Yeah, that's a great question Dave, really innovation is at our core as part of our core DNA. S3 launched more than 15 years ago, almost 16 years old. We're going to get a learner's permit for it next year. But, you know, as it's grown to exabytes of storage and trillions of objects, we've seen almost every use case you can imagine. I'm sure there's a new one coming that we haven't seen yet, but we've learned a lot from those use cases. And every year we just think about what can we do next to further simplify. And so you've seen that as we've launched over the last few years, things like S3 Intelligent Tiering, which was really the clouds first storage class to automatically optimize and reduce customer's costs for storage, for data that they were storing for a long time. And based on, you know, variable access patterns. We launched S3 Access Points to provide a simpler way to have different applications operating on shared data sets. And we launched earlier this year S3 Object Lambda, which really is, I think, cool technology. We're just starting to see how it can be applied to simplify serverless application development. Really the next wave, I think, of application development that doesn't need, not only is the storage fully managed, but the compute is fully managed as well. Really just simplify that whole end to end application development. >> Okay, so we heard this morning in the keynote, some exciting news. What can you tell us, Kevin? >> Yeah, so this morning we launched S3 Multi-Region Access Points and these are access points that give you a single global endpoint to access data sets that can span multiple S3 buckets in different AWS regions around the world. And so this allows you to build these multi-region applications and multi-region architectures with, you know, with the same approach that you use in a single region and then run these applications anywhere around the world. >> Okay. So if I interpret this correctly, it's a good fit for organizations with clients or operations around the globe. So for instance, gaming, news outlets, think of content delivery types of customers. Should we think about this as multi-region storage and why is that so important in your view? >> Absolutely. Yeah, that is multi-region storage. And what we're hearing is seeing as customers grow and we have multinational customers who have operations all around the world. And so as they've grown and their data needs grow around the world, they need to be using multiple AWS regions to store and access that data. Sometimes it's for low latency so that it can be closer to their end users or their customers, other times it's for regions where they just have a particular need to have data in a particular geography. But this is really a simple way of having one endpoint in front of data, across multiple buckets. So for applications it's quite easy, they just have that one end point and then the data, the requests are automatically routed to the nearest region. >> Now earlier this year, S3 turned 15. What makes S3 different, Kevin in your view? >> Yeah, it turned 15. It'll be 16 soon, you know, S3 really, I think part of the difference is it just operates at really an unprecedented scale with, you know, more than a hundred trillion objects and regularly peaking to tens of millions of requests per second. But it's really about the resiliency and availability and durability that are our responsibility and we focus every single day on protecting those characteristics for customers so that they don't have to. So that they can focus on building the businesses and applications that they need to really run their business and not worry about the details of running highly available storage. And so I think that's really one of the key differences with S3. >> You know, I first heard the term data lake, it was early last decade. I think it was around 2011, 2012 and obviously the phrase has stuck. How are S3 and data lakes simpatico, and how have data lakes on S3 changed or evolved over the years? >> Yeah. You know, the idea of data lakes, obviously, as you say, came around nine or 10 years ago, but I actually still think it's really early days for data lakes. And just from the standpoint of, you know, originally nine or 10 years ago, when we talked about data lakes, we were looking at maybe tens of terabytes, hundreds of terabytes, or a low number of petabytes and for a lot of data lakes, we're still seeing that that's the kind of scale that currently they're operating at, but I'm also seeing a class of data lakes where you're talking about tens or hundreds of petabytes or even more, and really just being used to drive critical aspects of customer's businesses. And so I really think S3, it's been a great place to run data lakes and continues to be. We've added a lot of capability over the last several years, you know, specifically for that data lake use case. And we're going to continue to do that and grow the feature set for data lakes, you know, over the next many years as well. But really, it goes back to the fundamentals of S3 providing that 11 9s of durability, the resiliency of having three independent data centers within regions. So the customers can use that storage knowing their data is protected. And again, just focus on the applications on top of that data lake and also run multiple applications, right? The idea of a data lake is you're not limited to one access pattern or one set of applications. If you want to try out a new machine learning application or something, do some advanced analytics, that's all possible while running the in-flight operational tools that you also have against that data. So it allows for that experimentation and for transforming businesses through new ideas. >> Yeah. I mean, to your point, if you go back to the early days of cloud, we were talking about storing, you know, gigabytes, maybe tens of terabytes that was big. Today, we're talking about hundreds and hundreds of terabytes, petabytes. And so you've got huge amount of information customers that are of that size and that scale, they have to optimize costs. Really that's top of mind, how are you helping customers save on storage costs? >> Absolutely. Dave, I mean, cost optimization is one of the key things we look at every single year to help customers reduce their costs for storage. And so that led to things like the introduction of S3 Intelligent Tiering, 10 years ago. And that's really the only cloud storage class that just delivers the automatic storage cost savings, as data access patterns change. And, you know, we deliver this without performance impact or any kind of operational overhead. It's really intended to be, you know, intelligent where customers put the data in. And then we optimize the storage cost. Or for example, last year we launched S3 Storage Lens, which is really the first and only service in the cloud that provides organization-wide visibility into where customers are storing their data, what the request rates are and so forth against their storage. So when you talk about these data lakes of hundreds of petabytes or even smaller, these tools are just really invaluable to help customers reduce their storage costs year after year. And actually, Dave I'm pleased, you know, today we're also announcing the launch of some improvements to S3 Intelligent Tiering, to actually further automate the cost savings. And what we're doing is we're actually removing the minimum storage duration. Previously, Intelligent Tiering had a 30 day minimum storage duration, and we're also eliminating our monitoring and automation charge for small objects. So previously there was that monitoring and automation charge applied to all objects independent of size. And now any object less than 120 kilobytes is not charged at that charge. So, and I think some pretty critical innovations on Intelligent Tiering that will help customers use that for an even wider set of data lake and other applications. >> That's three, it's ubiquitous. The innovation continues. You can learn more by attending the Storage Day S3 deep dive right after this interview. Thank you, Kevin Miller. Great to have you on the program. >> Yeah, Dave, thanks for having me. Great to see you. >> You're welcome, this is Dave Vellante and you're watching theCUBE's coverage of AWS Storage Day. Keep it right there. (bright music)

>> We continue with cube on cloud. We here with Mai-Lan Tomsen Bukovec who's the vice president of block and object storage at AWS which comprises elastic block storage, AWS S3 and Amazon glacier. Mai-Lan Great to see you again. Thanks so much for coming on the program. >> Nice to be here. Thanks for having me, Dave. >> You're very welcome. So here we're unpacking the future of cloud and we'd love to get your perspectives on how customers should think about the future of infrastructure things like applying machine intelligence to their data but just to set the stage, when we look back at the history of storage and the cloud has obviously started with S3 and then a couple of years later AWS introduced EBS for block storage and those are the most well-known services in the portfolio but there's more of this cold storage and new capabilities that you announced recently at reinvent around, you know, super-duper block storage and in tiering is another example. But it looks like AWS is really starting to accelerate and pick up the pace of customer options in storage. So my first question is how should we think about this expanding portfolio? >> Well, I think you have to go all the way back to what customers are trying to do with their data Dave. The path to innovation is paved by data. If you don't have data, you don't have machine learning. You don't have the next generation of analytics applications that helps you chart a path forward into a world that seems to be changing every week. And so in order to have that insight in order to have that predictive forecasting that every company needs, regardless of what industry that you're in today, it all starts from data. And I think the key shift that I've seen is how customers are thinking about that data, about being instantly usable. Whereas in the past, it might've been a backup. Now it's part of a data lake. And if you can bring that data into a data lake you can have not just analytics or machine learning or auditing applications, it's really what does your application do for your business and how can it take advantage of that vast amount of shared data set in your business? >> Awesome, so thank you. So I want to make sure we're hitting on the big trends that you're seeing in the market that kind of are informing your strategy around the portfolio, and what you're seeing with customers. Instant usability, you know, you bring in machine learning into the equation. I think people have really started to understand the benefits of cloud storage as a service and the pay by the drink. and that whole model. Obviously COVID has accelerated that, you know, cloud migration is accelerated. Anything else we're missing there? What are the other big trends that you see? If any. >> Well, Dave, you did a good job of capturing a lot of the drivers. The one thing I would say that just sits underneath all of it is the massive growth of digital data year over year. IDC says digital data is growing at a rate of 40% year over year. And that has been true for a while and it's not going to stop. It's going to keep on growing because the sources of that data acquisition keeps on expanding and whether it's IOT devices whether it is a content created by users, that data is going to grow and everything you're talking about depends on the ability to not just capture it and store it. But as you say, use it. >> Well, you know, and we talk about data growth a lot and sometimes it can, it becomes bromide. But I think the interesting thing that I've observed over the last couple of decades really is that the growth is non-linear and it's really the curve is starting to shape exponentially. You guys always talk about that flywheel effect it's really hard to believe, you know people say trees don't grow to the moon. It seems like data does. >> It does and what's interesting about working in a world of AWS storage Dave is that it's counter-intuitive but our goal with a data growth is to make it cost effective. And so year over year how can we make it cheaper and cheaper? It is have customers store more and more data so they can use it. But it's also to think about the definition of usage and what kind of data is being tapped by businesses for their insights and make that easier than it's ever been before. >> Let me ask you a follow up question on that Mai-Lan. Cause I get asked this a lot, or I hear comments a lot that yes AWS continuously and rigorously reduces pricing but it's just kind of following the natural curve of Moore's law or whatever. How do you respond to that? Are there other factors involved? Obviously labor is another, you know, cost reducing factor, but what's the trend line say? >> Well, cost efficiency is in our DNA, Dave we come to work every day in AWS across all of our services and we ask ourselves, how can we lower our costs and be able to pass that along to customers. As you say, there are many different aspects to costs. There's a cost to the storage itself There's a cost to the data center. And that's really what we've seen impact a lot of customers that were slower or just getting started with a move to the cloud, is they entered 2020 and then they found out exactly how expensive that data center was to maintain because they had to put in safety equipment and they had to do all the things that you have to do in a pandemic, in a data center. And so sometimes that cost is a little bit hidden or it won't show up until you really don't need to have it land. But the costs of managing that explosive growth of data is very real. And when we're thinking about costs, we're thinking about costs in terms of how can I lower it on a per gigabyte per month basis, but we're also building into the product itself, adaptive discounts. Like we have a storage class in S3 that's called intelligent tiering. And in intelligent tiering we have built-in monitoring where if particular objects aren't frequently accessed in a given month, a customer will automatically get a discounted price for that storage or a customer can, you know, as of late last year say that they want to automatically move storage in the storage class that has been stored for example longer than 180 days and saves 95% by moving it into deep archive storage. And so it's not just, you know relentlessly going after and lowering the cost of storage. It's also building into the products these new ways where we can adaptively discount storage based on what a customer's storage is actually doing. >> Right, and I would add to already is the other thing Gatos has done is it's really forced transparency almost the same way that Amazon has done on retail. And now Mai-Lan when we talked last I mentioned that S3 was an object store. And of course that's technically correct but your comment to me was Dave, it's more than that. And you started to talk about SageMaker and AI and bringing in machine learning. And I wonder if you could talk a little bit about the future of how storage is going to be leveraged in the cloud. That's maybe different than what we've been used to in the early days of S3. And how your customers should be thinking about infrastructure, not as bespoke services, but as a suite of capabilities and maybe some of those adjacent services that you see as most leverageable for customers and why? >> Well, to tell this story, Dave, we're going to have to go a little bit back in time, all the way back to the 1990s or before then. When all you had was a set of hardware appliance vendors that sold you appliances that you put in your data center and inherently created a data silo because those hardware appliances were hardwired to your application. And so an individual application that was dealing with auditing as an example wouldn't really be able to access the storage for another application, because you know, the architecture of that legacy world is tied to a data silo and S3 came out launched in 2006 and introduced very low cost storage. That is an object. And I'll tell you, Dave, you know, over the last 10 plus years we have seen all kinds of data coming to S3. Whereas before it might've been backups or it might've been images and videos. Now a pretty substantial data set is our parquet files and work files. These files are there for business analytics for more real-time type of processing. And that has really been the trend of the future, is taking these different files putting them in a shared file layer, so any application today or in the future can tap into that data. And so this idea of the shared file layer is a major trend that has been taking off for the last I would say five or six years. And I expect that to not only keep on going but to really open up the type of services that you can then do on that shared file layer. And whether that's Sage maker or some of the machine learning introduced by our connect service, it's bringing together the data as a starting point and then the applications can evolve very rapidly on top of that. >> I want to ask your opinion about big data architectures. One of our guests Chamakh Tigani, she's amazing data architect. And she's put forth this notion of a distributed global mesh. And picking up on some of the comments, Andy Jassy made it at re-invent how essentially, "Hey we're bringing AWS to the edge. "We see the data center is just another edge node." So you're seeing this massive distributed system evolving. You guys have talked about that for a while and data by its very nature is distributed but we've had this tendency to put it into a monolithic data Lake or a data warehouse and it's sort of antithetical to that distributed nature. So how do you see that playing out? What do you see customers in the future doing in terms of their big data architectures and what does that mean for storage? >> It comes down to the nature of the data and again the usage and Dave that's where I see the biggest difference in these modern data architectures from the legacy of 20 years ago, is the idea that the data need drives the data storage. So let's take an example of the type of data that you always want to have on the edge. We have customers today that need to have storage in the field and whether the field of scientific research or oftentimes it's content creation in the film industry, or if it's for military operations there's a lot of data that needs to be captured and analyzed in the field. And for us, what that means is that, you know we have a suite of products called snow ball and whether it's snow ball or snow cone, take your pick. That whole portfolio of AWS services is targeted at customers that need to do work with storage at the edge. And so, you know, if you think about the need for multiple applications acting on the same data set that's when you keep it in an AWS region. And what we've done in AWS storage is we've recognized that depending on the need of usage where you put your data and how you interact with it may vary. But we've built a whole set of services like data transfer to help make sure that we can connect data from, for example that new snow cone into a region automatically. And so our goal Dave is to make sure that when customers are operating at the edge or they're operating in the region they have the same quality of storage service and they have easy ways to go between them. You shouldn't have to pick, you should be able to do it all. >> So in the spirit of do it all there's this sort of age old dynamic in the tech business where you've got the friction between the best of breed and the integrated suite. And my question is around what you're optimizing for customers. And can you have your cake and eat it too? In other words, why AWS storage? What makes it compelling? Is it because it's kind of a best of breed storage service or is it because it's integrated with AWS? Would you ever sub optimize one in order to get an advantage to the other? Or can you actually, you know have your cake and eat it too? >> The way that we build storage is to focus on being both the breadth of capabilities and the depth of capabilities. And so where we identify a particular need where we think that it takes a whole new service to deliver we'll go build that service. And an example for that as FTP our AWS SFTP service, which, you know, there's a lot of SFTP usage out there and there will be for a while because of the, you know, the legacy B2B type of architectures that still live in the business world today. And so we looked at that problem. We said, how are we going to build that in the best depth way, in the best focus? And we launched a separate service for that. And so our goal is to take the individual building blocks of EBS and glacier and S3 and make the best of class and the most comprehensive in the capabilities of what we can do and where we identify a very specific need. We'll go build a service for it. But Dave, you know as an example for that idea of both depth and breadth, S3 Storage Lens is a great example of that. S3 Storage Lens is a new capability that we launched late last year. And what it does is it lets you look across all your regions and all your accounts and get a summary view of all your S3 storage and whether that's buckets or the most active prefixes that you have and be able to drill down from that. And that is built in to the S3 service and available for any customer that wants to turn it on in the AWS management console. >> Right, and we saw just recently made, I called it super-duper block storage but you can make some improvements in really addressing the highest performance. I want to ask you, so we've all learned about an experience that benefits of cloud over the last several years and especially in the last 10 months during the pandemic but one of the challenges and it's particularly acute with IO is of course latency and moving data around and accessing data remotely. It's a challenge for customers, you know, due to speed of light, et cetera. So my question is how was AWS thinking about all that data that's still resides on premises? I think we heard at reinvent, that's still on 90% of the opportunity is, or the the workloads are still on prem that live inside a customer's data centers. So how do you tap into those and help customers innovate with on-prem data, particularly from a storage angle? >> Well, we always want to provide the best of class solution for those little latency workloads. And that's why we launched Block Express just late last year at reinvent. And Block Express has a new capability in preview on top of our IO to provisioned IOPS volume type. And what's really interesting about block express Dave is that the way that we're able to deliver the performance of Block Express, which is sound performance with cloud elasticity is that we went all the way down to the network layer and we customize the hardware software. And at the network layer we built Block Express on something called SRD which stands for a scalable reliable diagrams. And basically what it's letting us do is offload all of our EBS operations for Block Express on the nitrile card on hardware. And so that type of innovation where we're able to, you know, take advantage of modern cop commodity, multi-tenant data center networks, where we're sending in this new network protocol across a large number of network paths. And that type of innovation all the way down to that protocol level helps us innovate in a way that's hard. In fact, I would say impossible for other sound providers to kind of really catch up and keep up. And so we feel that the amount of innovation that we have for delivering those low latency workloads in our AWS cloud storage is unlimited really because of that ability to customize software hardware and network protocols as we go along without requiring upgrades from a customer it just gets better. And the customer benefits. Now, if you want to stay in your data center that's why we build outposts. And for outposts, we have UVS and we have S3 for outposts and our goal there is that some customers will have workloads where they want to keep them resident in the data center. And for those customers we want to give them that AWS storage opportunities as well. >> So thank you for coming back to Block Express. So you call it, you know, sand in the cloud. So is that essentially it comprises a custom built essentially storage network. Is that right? What you just described SRD? I think you called it. >> Yeah, it's a SRD is used by other AWS services as well but it is a custom network protocol that we designed to deliver the lowest latency experience and we're taking advantage of it with Block Express. >> So sticking with traditional data centers for a moment I'm interested in your thoughts on the importance of the cloud pricing approach, I.e the consumption model to pay by the drink. Obviously it's one of the most attractive features, and I asked that because we're seeing what Andy Jassy refers to as the old guard Institute, flexible pricing models two of the biggest storage companies, HP with GreenLake and Dell has this thing called apex. They've announced such models for on-prem and presumably cross cloud. How do you think this is going to impact your customers leverage of AWS cloud storage? Is it something that you have an opinion on? >> Yeah, I think it all comes down to, again that usage of the storage, and this is where I think there's an inherent advantage for our cloud storage. So there might be an attempt by the old guard to lower prices or add flexibility but at the end of the day it comes down to what the customer actually needs to tune. And if you think about gp3 which is the new EBS volume. The idea with gp3 is we're going to pass a long savings to the customer by making the storage 20% cheaper than gp2. And we're going to make the product better by giving a great, reliable baseline performance. But we're also going to let customers who want to run workloads like Cassandra on EBS tune their throughput separately, for example from their capacity. So if you're running Cassandra sometimes you don't need to change your capacity. Your storage capacity works just fine. But what happens with, for example Cassandra workload is that you may need more throughput. And if you're buying hardware appliance you just have to buy for your peak. You have to buy for the max of what you think your throughput and the max of what your storage is. And this inherent flexibility that we have for AWS storage and being able to tune throughput separate from up separate from capacity like you do for gp3 that is really where the future is for customers having control over costs and control over customer experience without compromising or trading off either one. >> Awesome, thank you for that. So in the time we have remaining Mai-Lan, I want to talk about the topic of diversity social impact, and as a woman leader, women executive, and I really want to get your perspectives on this. And I've shared with the audience previously, one of my breaking analysis segments, your boxing video which is awesome. And so, you've got a lot of unique non-traditional aspects to your life and I love it, but I want to ask you this. So it's obviously, you know, certainly politically and socially correct to talk about diversity, the importance of diversity, there's data that suggests that diversity is good both economically, not just socially, and of course it's the right thing to do. But there are those, you know, Peter teal is probably the most prominent but there are others that say, "You know what? "Forget that, just hire people, just like you'll be able "to go faster, ramp up more quickly, hit escape "velocity it's natural." And that's what you should do. Why is that not the right approach? Why is diversity both, of course, socially, you know responsible, but also, you know, good for business >> For Amazon we think about diversity as something that is essential to how we think about innovation. And so, Dave, as you know, from listening to some of the announcements at reinvent, we launch a lot of new ideas, like new concepts and new services in AWS. And just bringing that lens down to storage. Astri has been reinventing itself every year since we launched in 2006. EBS introduced the first sun on the cloud late last year, and continues to reinvent how customers think about block storage. We would not be able to look at a product in a different way and think to ourselves, not just what is the legacy system do in a data center today but how do we want to build this new distributed system in a way that helps customers achieve not just what they're doing today, but what they want to do in five and 10 years. You can't get that innovative mindset without bringing different perspectives to the table. And so we strongly believe in hiring people who are from under represented groups and whether that's gender or it's related to racial equality or if it's geographic diversity and bringing them in to have the conversation because those diverse viewpoints inform how we can innovate at all levels in AWS. >> Right, and so I really appreciate their perspectives on that. And we've had, as you probably know the cube has been, you know a very big advocate of diversity, you know, generally but women in tech specifically, we participated a lot. And I often ask this question is, you know, as a smaller company, I, and some of my other colleagues in small business, sometimes we struggle. And so my question is how do you go beyond what's your advice for going beyond, you know the good old boys network? I think it's large companies like AWS and, you know, the big players, you've got responsibility too that you can put somebody in charge and make it their full-time job. How should smaller companies that are largely white male dominated, how should they become more diverse? What should they do to increase that diversity? >> I think the place to start is voice. A lot of what we try to do is make sure that the under represented voice is heard. And so Dave, any small business owner of any industry can encourage voice for your under represented or your unheard populations. And honestly, it is as simple as being in a meeting and looking around that table or on your screen, as it were and asking yourself, who hasn't talked? Who hasn't weighed in? Particularly if the debate is contentious or even animated. And you will see, particularly if you note this over time you will see that there may be somebody and whether it's an under represented group or it's a woman who's early career, or it's not it's just a member of your team who happens to be a white male too, who's not being heard. And you can ask that person for their perspective. And that is a step that every one of us can and should do which is ask to have everyone's voice at the table to listen and to weigh in on it. So I think that is something everyone should do. I think if you are a member of an under represented group as for example, I'm Vietnamese American and I'm a female in tech, I think, it's something to think about how you can make sure that you're always taking that bold step forward. And it's one of the topics that we covered at re-invent. We had a great discussion with a group of women CEOs and a lot of it we talked about is being bold taking the challenge of being bold in tough situations. And that is an important thing, I think for anybody to keep in mind, but especially for members of under represented groups, because sometimes Dave that bold step that you kind of think of as like, "Oh I don't know if I should ask for that promotion." or "I don't know if I should volunteer for that project." It's not a big ask, but it's big in your head. And so if you can internalize as a member of some, you know, a group that maybe isn't heard as or seen as much how you can take those bold challenges and step forward and learn, maybe fail also cause that's how you learn. Then that is a way to also have people learn and develop and become leaders in whatever industry it is. >> That's great advice. It reminds me of, I think most of us can relate to that Mai-Lan, because when we started in the industry, we may be timid. You didn't want to necessarily speak up. And I think it's incumbent upon those in a position of power. And by the way power might just be running a meeting agenda to maybe call on those folks that are, maybe it's not diversity of gender or, you know, or race. Maybe it's just the under represented. Maybe that's a good way to start building muscle memory. So that's unique advice that I hadn't heard before. So thank you very much for that. I appreciate it. And Hey, listen. Thanks so much for coming on the Cube On Cloud. We're out of time and really always appreciate your perspectives and you're doing a great job. And thank you. >> Great, thank you Dave. Thanks for having me and have a great day. >> All right, and Keep it right there buddy. You're watching the Cube On Cloud. Right back. (gentle upbeat music)

>> Hi, my name is Andy Clemenko. I'm a Senior Solutions Engineer at StackRox. Thanks for joining us today for my talk on labels, labels, labels. Obviously, you can reach me at all the socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, and it'll take you to my GitHub page where I've got all of this documentation, socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, (upbeat music) >> Hi, my name is Andy Clemenko. I'm a Senior Solutions Engineer at StackRox. Thanks for joining us today for my talk on labels, labels, labels. Obviously, you can reach me at all the socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, and it'll take you to my GitHub page where I've got all of this documentation, I've got the Keynote file there. YAMLs, I've got Dockerfiles, Compose files, all that good stuff. If you want to follow along, great, if not go back and review later, kind of fun. So let me tell you a little bit about myself. I am a former DOD contractor. This is my seventh DockerCon. I've spoken, I had the pleasure to speak at a few of them, one even in Europe. I was even a Docker employee for quite a number of years, providing solutions to the federal government and customers around containers and all things Docker. So I've been doing this a little while. One of the things that I always found interesting was the lack of understanding around labels. So why labels, right? Well, as a former DOD contractor, I had built out a large registry. And the question I constantly got was, where did this image come from? How did you get it? What's in it? Where did it come from? How did it get here? And one of the things we did to kind of alleviate some of those questions was we established a baseline set of labels. Labels really are designed to provide as much metadata around the image as possible. I ask everyone in attendance, when was the last time you pulled an image and had 100% confidence, you knew what was inside it, where it was built, how it was built, when it was built, you probably didn't, right? The last thing we obviously want is a container fire, like our image on the screen. And one kind of interesting way we can kind of prevent that is through the use of labels. We can use labels to address security, address some of the simplicity on how to run these images. So think of it, kind of like self documenting, Think of it also as an audit trail, image provenance, things like that. These are some interesting concepts that we can definitely mandate as we move forward. What is a label, right? Specifically what is the Schema? It's just a key-value. All right? It's any key and pretty much any value. What if we could dump in all kinds of information? What if we could encode things and store it in there? And I've got a fun little demo to show you about that. Let's start off with some of the simple keys, right? Author, date, description, version. Some of the basic information around the image. That would be pretty useful, right? What about specific labels for CI? What about a, where's the version control? Where's the source, right? Whether it's Git, whether it's GitLab, whether it's GitHub, whether it's Gitosis, right? Even SPN, who cares? Where are the source files that built, where's the Docker file that built this image? What's the commit number? That might be interesting in terms of tracking the resulting image to a person or to a commit, hopefully then to a person. How is it built? What if you wanted to play with it and do a git clone of the repo and then build the Docker file on your own? Having a label specifically dedicated on how to build this image might be interesting for development work. Where it was built, and obviously what build number, right? These kind of all, not only talk about continuous integration, CI but also start to talk about security. Specifically what server built it. The version control number, the version number, the commit number, again, how it was built. What's the specific build number? What was that job number in, say, Jenkins or GitLab? What if we could take it a step further? What if we could actually apply policy enforcement in the build pipeline, looking specifically for some of these specific labels? I've got a good example of, in my demo of a policy enforcement. So let's look at some sample labels. Now originally, this idea came out of label-schema.org. And then it was a modified to opencontainers, org.opencontainers.image. There is a link in my GitHub page that links to the full reference. But these are some of the labels that I like to use, just as kind of like a standardization. So obviously, Author's, an email address, so now the image is attributable to a person, that's always kind of good for security and reliability. Where's the source? Where's the version control that has the source, the Docker file and all the assets? How it was built, build number, build server the commit, we talked about, when it was created, a simple description. A fun one I like adding in is the healthZendpoint. Now obviously, the health check directive should be in the Docker file. But if you've got other systems that want to ping your applications, why not declare it and make it queryable? Image version, obviously, that's simple declarative And then a title. And then I've got the two fun ones. Remember, I talked about what if we could encode some fun things? Hypothetically, what if we could encode the Compose file of how to build the stack in the first image itself? And conversely the Kubernetes? Well, actually, you can and I have a demo to show you how to kind of take advantage of that. So how do we create labels? And really creating labels as a function of build time okay? You can't really add labels to an image after the fact. The way you do add labels is either through the Docker file, which I'm a big fan of, because it's declarative. It's in version control. It's kind of irrefutable, especially if you're tracking that commit number in a label. You can extend it from being a static kind of declaration to more a dynamic with build arguments. And I can show you, I'll show you in a little while how you can use a build argument at build time to pass in that variable. And then obviously, if you did it by hand, you could do a docker build--label key equals value. I'm not a big fan of the third one, I love the first one and obviously the second one. Being dynamic we can take advantage of some of the variables coming out of version control. Or I should say, some of the variables coming out of our CI system. And that way, it self documents effectively at build time, which is kind of cool. How do we view labels? Well, there's two major ways to view labels. The first one is obviously a docker pull and docker inspect. You can pull the image locally, you can inspect it, you can obviously, it's going to output as JSON. So you going to use something like JQ to crack it open and look at the individual labels. Another one which I found recently was Skopeo from Red Hat. This allows you to actually query the registry server. So you don't even have to pull the image initially. This can be really useful if you're on a really small development workstation, and you're trying to talk to a Kubernetes cluster and wanting to deploy apps kind of in a very simple manner. Okay? And this was that use case, right? Using Kubernetes, the Kubernetes demo. One of the interesting things about this is that you can base64 encode almost anything, push it in as text into a label and then base64 decode it, and then use it. So in this case, in my demo, I'll show you how we can actually use a kubectl apply piped from the base64 decode from the label itself from skopeo talking to the registry. And what's interesting about this kind of technique is you don't need to store Helm charts. You don't need to learn another language for your declarative automation, right? You don't need all this extra levels of abstraction inherently, if you use it as a label with a kubectl apply, It's just built in. It's kind of like the kiss approach to a certain extent. It does require some encoding when you actually build the image, but to me, it doesn't seem that hard. Okay, let's take a look at a demo. And what I'm going to do for my demo, before we actually get started is here's my repo. Here's a, let me actually go to the actual full repo. So here's the repo, right? And I've got my Jenkins pipeline 'cause I'm using Jenkins for this demo. And in my demo flask, I've got the Docker file. I've got my compose and my Kubernetes YAML. So let's take a look at the Docker file, right? So it's a simple Alpine image. The org statements are the build time arguments that are passed in. Label, so again, I'm using the org.opencontainers.image.blank, for most of them. There's a typo there. Let's see if you can find it, I'll show you it later. My source, build date, build number, commit. Build number and get commit are derived from the Jenkins itself, which is nice. I can just take advantage of existing URLs. I don't have to create anything crazy. And again, I've got my actual Docker build command. Now this is just a label on how to build it. And then here's my simple Python, APK upgrade, remove the package manager, kind of some security stuff, health check getting Python through, okay? Let's take a look at the Jenkins pipeline real quick. So here is my Jenkins pipeline and I have four major stages, four stages, I have built. And here in build, what I do is I actually do the Git clone. And then I do my docker build. From there, I actually tell the Jenkins StackRox plugin. So that's what I'm using for my security scanning. So go ahead and scan, basically, I'm staging it to scan the image. I'm pushing it to Hub, okay? Where I can see the, basically I'm pushing the image up to Hub so such that my StackRox security scanner can go ahead and scan the image. I'm kicking off the scan itself. And then if everything's successful, I'm pushing it to prod. Now what I'm doing is I'm just using the same image with two tags, pre-prod and prod. This is not exactly ideal, in your environment, you probably want to use separate registries and non-prod and a production registry, but for demonstration purposes, I think this is okay. So let's go over to my Jenkins and I've got a deliberate failure. And I'll show you why there's a reason for that. And let's go down. Let's look at my, so I have a StackRox report. Let's look at my report. And it says image required, required image label alert, right? Request that the maintainer, add the required label to the image, so we're missing a label, okay? One of the things we can do is let's flip over, and let's look at Skopeo. Right? I'm going to do this just the easy way. So instead of looking at org.zdocker, opencontainers.image.authors. Okay, see here it says build signature? That was the typo, we didn't actually pass in. So if we go back to our repo, we didn't pass in the the build time argument, we just passed in the word. So let's fix that real quick. That's the Docker file. Let's go ahead and put our dollar sign in their. First day with the fingers you going to love it. And let's go ahead and commit that. Okay? So now that that's committed, we can go back to Jenkins, and we can actually do another build. And there's number 12. And as you can see, I've been playing with this for a little bit today. And while that's running, come on, we can go ahead and look at the Console output. Okay, so there's our image. And again, look at all the build arguments that we're passing into the build statement. So we're passing in the date and the date gets derived on the command line. With the build arguments, there's the base64 encoded of the Compose file. Here's the base64 encoding of the Kubernetes YAML. We do the build. And then let's go down to the bottom layer exists and successful. So here's where we can see no system policy violations profound marking stack regimes security plugin, build step as successful, okay? So we're actually able to do policy enforcement that that image exists, that that label sorry, exists in the image. And again, we can look at the security report and there's no policy violations and no vulnerabilities. So that's pretty good for security, right? We can now enforce and mandate use of certain labels within our images. And let's flip back over to Skopeo, and let's go ahead and look at it. So we're looking at the prod version again. And there's it is in my email address. And that validated that that was valid for that policy. So that's kind of cool. Now, let's take it a step further. What if, let's go ahead and take a look at all of the image, all the labels for a second, let me remove the dash org, make it pretty. Okay? So we have all of our image labels. Again, author's build, commit number, look at the commit number. It was built today build number 12. We saw that right? Delete, build 12. So that's kind of cool dynamic labels. Name, healthz, right? But what we're looking for is we're going to look at the org.zdockerketers label. So let's go look at the label real quick. Okay, well that doesn't really help us because it's encoded but let's base64 dash D, let's decode it. And I need to put the dash r in there 'cause it doesn't like, there we go. So there's my Kubernetes YAML. So why can't we simply kubectl apply dash f? Let's just apply it from standard end. So now we've actually used that label. From the image that we've queried with skopeo, from a remote registry to deploy locally to our Kubernetes cluster. So let's go ahead and look everything's up and running, perfect. So what does that look like, right? So luckily, I'm using traefik for Ingress 'cause I love it. And I've got an object in my Kubernetes YAML called flask.doctor.life. That's my Ingress object for traefik. I can go to flask.docker.life. And I can hit refresh. Obviously, I'm not a very good web designer 'cause the background image in the text. We can go ahead and refresh it a couple times we've got Redis storing a hit counter. We can see that our server name is roundrobing. Okay? That's kind of cool. So let's kind of recap a little bit about my demo environment. So my demo environment, I'm using DigitalOcean, Ubuntu 19.10 Vms. I'm using K3s instead of full Kubernetes either full Rancher, full Open Shift or Docker Enterprise. I think K3s has some really interesting advantages on the development side and it's kind of intended for IoT but it works really well and it deploys super easy. I'm using traefik for Ingress. I love traefik. I may or may not be a traefik ambassador. I'm using Jenkins for CI. And I'm using StackRox for image scanning and policy enforcement. One of the things to think about though, especially in terms of labels is none of this demo stack is required. You can be in any cloud, you can be in CentOs, you can be in any Kubernetes. You can even be in swarm, if you wanted to, or Docker compose. Any Ingress, any CI system, Jenkins, circle, GitLab, it doesn't matter. And pretty much any scanning. One of the things that I think is kind of nice about at least StackRox is that we do a lot more than just image scanning, right? With the policy enforcement things like that. I guess that's kind of a shameless plug. But again, any of this stack is completely replaceable, with any comparative product in that category. So I'd like to, again, point you guys to the andyc.infodc20, that's take you right to the GitHub repo. You can reach out to me at any of the socials @clemenko or andy@stackrox.com. And thank you for attending. I hope you learned something fun about labels. And hopefully you guys can standardize labels in your organization and really kind of take your images and the image provenance to a new level. Thanks for watching. (upbeat music) >> Narrator: Live from Las Vegas It's theCUBE. Covering AWS re:Invent 2019. Brought to you by Amazon Web Services and Intel along with it's ecosystem partners. >> Okay, welcome back everyone theCUBE's live coverage of AWS re:Invent 2019. This is theCUBE's 7th year covering Amazon re:Invent. It's their 8th year of the conference. I want to just shout out to Intel for their sponsorship for these two amazing sets. Without their support we wouldn't be able to bring our mission of great content to you. I'm John Furrier. Stu Miniman. We're here with the chief of AWS, the chief executive officer Andy Jassy. Tech athlete in and of himself three hour Keynotes. Welcome to theCUBE again, great to see you. >> Great to be here, thanks for having me guys. >> Congratulations on a great show a lot of great buzz. >> Andy: Thank you. >> A lot of good stuff. Your Keynote was phenomenal. You get right into it, you giddy up right into it as you say, three hours, thirty announcements. You guys do a lot, but what I liked, the new addition, the last year and this year is the band; house band. They're pretty good. >> Andy: They're good right? >> They hit the queen notes, so that keeps it balanced. So we're going to work on getting a band for theCUBE. >> Awesome. >> So if I have to ask you, what's your walk up song, what would it be? >> There's so many choices, it depends on what kind of mood I'm in. But, uh, maybe Times Like These by the Foo Fighters. >> John: Alright. >> These are unusual times right now. >> Foo Fighters playing at the Amazon Intersect Show. >> Yes they are. >> Good plug Andy. >> Headlining. >> Very clever >> Always getting a good plug in there. >> My very favorite band. Well congratulations on the Intersect you got a lot going on. Intersect is a music festival, I'll get to that in a second But, I think the big news for me is two things, obviously we had a one-on-one exclusive interview and you laid out, essentially what looks like was going to be your Keynote, and it was. Transformation- >> Andy: Thank you for the practice. (Laughter) >> John: I'm glad to practice, use me anytime. >> Yeah. >> And I like to appreciate the comments on Jedi on the record, that was great. But I think the transformation story's a very real one, but the NFL news you guys just announced, to me, was so much fun and relevant. You had the Commissioner of NFL on stage with you talking about a strategic partnership. That is as top down, aggressive goal as you could get to have Rodger Goodell fly to a tech conference to sit with you and then bring his team talk about the deal. >> Well, ya know, we've been partners with the NFL for a while with the Next Gen Stats that they use on all their telecasts and one of the things I really like about Roger is that he's very curious and very interested in technology and the first couple times I spoke with him he asked me so many questions about ways the NFL might be able to use the Cloud and digital transformation to transform their various experiences and he's always said if you have a creative idea or something you think that could change the world for us, just call me he said or text me or email me and I'll call you back within 24 hours. And so, we've spent the better part of the last year talking about a lot of really interesting, strategic ways that they can evolve their experience both for fans, as well as their players and the Player Health and Safety Initiative, it's so important in sports and particularly important with the NFL given the nature of the sport and they've always had a focus on it, but what you can do with computer vision and machine learning algorithms and then building a digital athlete which is really like a digital twin of each athlete so you understand, what does it look like when they're healthy and compare that when it looks like they may not be healthy and be able to simulate all kinds of different combinations of player hits and angles and different plays so that you could try to predict injuries and predict the right equipment you need before there's a problem can be really transformational so we're super excited about it. >> Did you guys come up with the idea or was it a collaboration between them? >> It was really a collaboration. I mean they, look, they are very focused on players safety and health and it's a big deal for their- you know, they have two main constituents the players and fans and they care deeply about the players and it's a-it's a hard problem in a sport like Football, I mean, you watch it. >> Yeah, and I got to say it does point out the use cases of what you guys are promoting heavily at the show here of the SageMaker Studio, which was a big part of your Keynote, where they have all this data. >> Andy: Right. >> And they're data hoarders, they hoard data but the manual process of going through the data was a killer problem. This is consistent with a lot of the enterprises that are out there, they have more data than they even know. So this seems to be a big part of the strategy. How do you get the customers to actually wake up to the fact that they got all this data and how do you tie that together? >> I think in almost every company they know they have a lot of data. And there are always pockets of people who want to do something with it. But, when you're going to make these really big leaps forward; these transformations, the things like Volkswagen is doing where they're reinventing their factories and their manufacturing process or the NFL where they're going to radically transform how they do players uh, health and safety. It starts top down and if the senior leader isn't convicted about wanting to take that leap forward and trying something different and organizing the data differently and organizing the team differently and using machine learning and getting help from us and building algorithms and building some muscle inside the company it just doesn't happen because it's not in the normal machinery of what most companies do. And so it always, almost always, starts top down. Sometimes it can be the Commissioner or CEO sometimes it can be the CIO but it has to be senior level conviction or it doesn't get off the ground. >> And the business model impact has to be real. For NFL, they know concussions, hurting their youth pipe-lining, this is a huge issue for them. This is their business model. >> They lose even more players to lower extremity injuries. And so just the notion of trying to be able to predict injuries and, you know, the impact it can have on rules and the impact it can have on the equipment they use, it's a huge game changer when they look at the next 10 to 20 years. >> Alright, love geeking out on the NFL but Andy, you know- >> No more NFL talk? >> Off camera how about we talk? >> Nobody talks about the Giants being 2 and 10. >> Stu: We're both Patriots fans here. >> People bring up the undefeated season. >> So Andy- >> Everybody's a Patriot's fan now. (Laughter) >> It's fascinating to watch uh, you and your three hour uh, Keynote, uh Werner in his you know, architectural discussion, really showed how AWS is really extending its reach, you know, it's not just a place. For a few years people have been talking about you know, Cloud is an operational model its not a destination or a location but, I felt it really was laid out is you talked about Breadth and Depth and Werner really talked about you know, Architectural differentiation. People talk about Cloud, but there are very-there are a lot of differences between the vision for where things are going. Help us understand why, I mean, Amazon's vision is still a bit different from what other people talk about where this whole Cloud expansion, journey, put ever what tag or label you want on it but you know, the control plane and the technology that you're building and where you see that going. >> Well I think that, we've talked about this a couple times we have two macro types of customers. We have those that really want to get at the low level building blocks and stitch them together creatively however they see fit to create whatever's in their-in their heads. And then we have the second segment of customers that say look, I'm willing to give up some of that flexibility in exchange for getting 80% of the way there much faster. In an abstraction that's different from those low level building blocks. And both segments of builders we want to serve and serve well and so we've built very significant offerings in both areas. I think when you look at microservices um, you know, some of it has to do with the fact that we have this very strongly held belief born out of several years of Amazon where you know, the first 7 or 8 years of Amazon's consumer business we basically jumbled together all of the parts of our technology in moving really quickly and when we wanted to move quickly where you had to impact multiple internal development teams it was so long because it was this big ball, this big monolithic piece. And we got religion about that in trying to move faster in the consumer business and having to tease those pieces apart. And it really was a lot of impetus behind conceiving AWS where it was these low level, very flexible building blocks that6 don't try and make all the decisions for customers they get to make them themselves. And some of the microservices that you saw Werner talking about just, you know, for instance, what we-what we did with Nitro or even what we did with Firecracker those are very much about us relentlessly working to continue to uh, tease apart the different components. And even things that look like low level building blocks over time, you build more and more features and all of the sudden you realize they have a lot of things that are combined together that you wished weren't that slow you down and so, Nitro was a completely re imagining of our Hypervisor and Virtualization layer to allow us, both to let customers have better performance but also to let us move faster and have a better security story for our customers. >> I got to ask you the question around transformation because I think that all points, all the data points, you got all the references, Goldman Sachs on stage at the Keynote, Cerner, I mean healthcare just is an amazing example because I mean, that's demonstrating real value there there's no excuse. I talked to someone who wouldn't be named last night, in and around the area said, the CIA has a cost bar like this a cost-a budget like this but the demand for mission based apps is going up exponentially, so there's need for the Cloud. And so, you see more and more of that. What is your top down, aggressive goals to fill that solution base because you're also a very transformational thinker; what is your-what is your aggressive top down goals for your organization because you're serving a market with trillions of dollars of spend that's shifting, that's on the table. >> Yeah. >> A lot of competition now sees it too, they're going to go after it. But at the end of the day you have customers that have a demand for things, apps. >> Andy: Yeah. >> And not a lot of budget increase at the same time. This is a huge dynamic. >> Yeah. >> John: What's your goals? >> You know I think that at a high level our top down aggressive goals are that we want every single customer who uses our platform to have an outstanding customer experience. And we want that outstanding customer experience in part is that their operational performance and their security are outstanding, but also that it allows them to build, uh, build projects and initiatives that change their customer experience and allow them to be a sustainable successful business over a long period of time. And then, we also really want to be the technology infrastructure platform under all the applications that people build. And we're realistic, we know that you know, the market segments we address with infrastructure, software, hardware, and data center services globally are trillions of dollars in the long term and it won't only be us, but we have that goal of wanting to serve every application and that requires not just the security operational premise but also a lot of functionality and a lot of capability. We have by far the most amount of capability out there and yet I would tell you, we have 3 to 5 years of items on our roadmap that customers want us to add. And that's just what we know today. >> And Andy, underneath the covers you've been going through some transformation. When we talked a couple of years ago, about how serverless is impacting things I've heard that that's actually, in many ways, glue behind the two pizza teams to work between organizations. Talk about how the internal transformations are happening. How that impacts your discussions with customers that are going through that transformation. >> Well, I mean, there's a lot of- a lot of the technology we build comes from things that we're doing ourselves you know? And that we're learning ourselves. It's kind of how we started thinking about microservices, serverless too, we saw the need, you know, we would have we would build all these functions that when some kind of object came into an object store we would spin up, compute, all those tasks would take like, 3 or 4 hundred milliseconds then we'd spin it back down and yet, we'd have to keep a cluster up in multiple availability zones because we needed that fault tolerance and it was- we just said this is wasteful and, that's part of how we came up with Lambda and you know, when we were thinking about Lambda people understandably said, well if we build Lambda and we build this serverless adventure in computing a lot of people were keeping clusters of instances aren't going to use them anymore it's going to lead to less absolute revenue for us. But we, we have learned this lesson over the last 20 years at Amazon which is, if it's something that's good for customers you're much better off cannibalizing yourself and doing the right thing for customers and being part of shaping something. And I think if you look at the history of technology you always build things and people say well, that's going to cannibalize this and people are going to spend less money, what really ends up happening is they spend less money per unit of compute but it allows them to do so much more that they ultimately, long term, end up being more significant customers. >> I mean, you are like beating the drum all the time. Customers, what they say, we encompass the roadmap, I got that you guys have that playbook down, that's been really successful for you. >> Andy: Yeah. >> Two years ago you told me machine learning was really important to you because your customers told you. What's the next traunch of importance for customers? What's on top of mind now, as you, look at- >> Andy: Yeah. >> This re:Invent kind of coming to a close, Replay's tonight, you had conversations, you're a tech athlete, you're running around, doing speeches, talking to customers. What's that next hill from if it's machine learning today- >> There's so much I mean, (weird background noise) >> It's not a soup question (Laughter) And I think we're still in the very early days of machine learning it's not like most companies have mastered it yet even though they're using it much more then they did in the past. But, you know, I think machine learning for sure I think the Edge for sure, I think that um, we're optimistic about Quantum Computing even though I think it'll be a few years before it's really broadly useful. We're very um, enthusiastic about robotics. I think the amount of functions that are going to be done by these- >> Yeah. >> robotic applications are much more expansive than people realize. It doesn't mean humans won't have jobs, they're just going to work on things that are more value added. We're believers in augmented virtual reality, we're big believers in what's going to happen with Voice. And I'm also uh, I think sometimes people get bored you know, I think you're even bored with machine learning already >> Not yet. >> People get bored with the things you've heard about but, I think just what we've done with the Chips you know, in terms of giving people 40% better price performance in the latest generation of X86 processors. It's pretty unbelievable in the difference in what people are going to be able to do. Or just look at big data I mean, big data, we haven't gotten through big data where people have totally solved it. The amount of data that companies want to store, process, analyze, is exponentially larger than it was a few years ago and it will, I think, exponentially increase again in the next few years. You need different tools and services. >> Well I think we're not bored with machine learning we're excited to get started because we have all this data from the video and you guys got SageMaker. >> Andy: Yeah. >> We call it the stairway to machine learning heaven. >> Andy: Yeah. >> You start with the data, move up, knock- >> You guys are very sophisticated with what you do with technology and machine learning and there's so much I mean, we're just kind of, again, in such early innings. And I think that, it was so- before SageMaker, it was so hard for everyday developers and data scientists to build models but the combination of SageMaker and what's happened with thousands of companies standardizing on it the last two years, plus now SageMaker studio, giant leap forward. >> Well, we hope to use the data to transform our experience with our audience. And we're on Amazon Cloud so we really appreciate that. >> Andy: Yeah. >> And appreciate your support- >> Andy: Yeah, of course. >> John: With Amazon and get that machine learning going a little faster for us, that would be better. >> If you have requests I'm interested, yeah. >> So Andy, you talked about that you've got the customers that are builders and the customers that need simplification. Traditionally when you get into the, you know, the heart of the majority of adoption of something you really need to simplify that environment. But when I think about the successful enterprise of the future, they need to be builders. how'l I normally would've said enterprise want to pay for solutions because they don't have the skill set but, if they're going to succeed in this new economy they need to go through that transformation >> Andy: Yeah. >> That you talk to, so, I mean, are we in just a total new era when we look back will this be different than some of these previous waves? >> It's a really good question Stu, and I don't think there's a simple answer to it. I think that a lot of enterprises in some ways, I think wish that they could just skip the low level building blocks and only operate at that higher level abstraction. That's why people were so excited by things like, SageMaker, or CodeGuru, or Kendra, or Contact Lens, these are all services that allow them to just send us data and then run it on our models and get back the answers. But I think one of the big trends that we see with enterprises is that they are taking more and more of their development in house and they are wanting to operate more and more like startups. I think that they admire what companies like AirBnB and Pintrest and Slack and Robinhood and a whole bunch of those companies, Stripe, have done and so when, you know, I think you go through these phases and eras where there are waves of success at different companies and then others want to follow that success and replicate it. And so, we see more and more enterprises saying we need to take back a lot of that development in house. And as they do that, and as they add more developers those developers in most cases like to deal with the building blocks. And they have a lot of ideas on how they can creatively stich them together. >> Yeah, on that point, I want to just quickly ask you on Amazon versus other Clouds because you made a comment to me in our interview about how hard it is to provide a service to other people. And it's hard to have a service that you're using yourself and turn that around and the most quoted line of my story was, the compression algorithm- there's no compression algorithm for experience. Which to me, is the diseconomies of scale for taking shortcuts. >> Andy: Yeah. And so I think this is a really interesting point, just add some color commentary because I think this is a fundamental difference between AWS and others because you guys have a trajectory over the years of serving, at scale, customers wherever they are, whatever they want to do, now you got microservices. >> Yeah. >> John: It's even more complex. That's hard. >> Yeah. >> John: Talk about that. >> I think there are a few elements to that notion of there's no compression algorithm for experience and I think the first thing to know about AWS which is different is, we just come from a different heritage and a different background. We ran a business for a long time that was our sole business that was a consumer retail business that was very low margin. And so, we had to operate at very large scale given how many people were using us but also, we had to run infrastructure services deep in the stack, compute storage and database, and reliable scalable data centers at very low cost and margins. And so, when you look at our business it actually, today, I mean its, its a higher margin business in our retail business, its a lower margin business in software companies but at real scale, it's a high volume, relatively low margin business. And the way that you have to operate to be successful with those businesses and the things you have to think about and that DNA come from the type of operators we have to be in our consumer retail business. And there's nobody else in our space that does that. So, you know, the way that we think about costs, the way we think about innovation in the data center, um, and I also think the way that we operate services and how long we've been operating services as a company its a very different mindset than operating package software. Then you look at when uh, you think about some of the uh, issues in very large scale Cloud, you can't learn some of those lessons until you get to different elbows of the curve and scale. And so what I was telling you is, its really different to run your own platform for your own users where you get to tell them exactly how its going to be done. But that's not the way the real world works. I mean, we have millions of external customers who use us from every imaginable country and location whenever they want, without any warning, for lots of different use cases, and they have lots of design patterns and we don't get to tell them what to do. And so operating a Cloud like that, at a scale that's several times larger than the next few providers combined is a very different endeavor and a very different operating rigor. >> Well you got to keep raising the bar you guys do a great job, really impressed again. Another tsunami of announcements. In fact, you had to spill the beans earlier with Quantum the day before the event. Tight schedule. I got to ask you about the musical festival because, I think this is a very cool innovation. It's the inaugural Intersect conference. >> Yes. >> John: Which is not part of Replay, >> Yes. >> John: Which is the concert tonight. Its a whole new thing, big music act, you're a big music buff, your daughter's an artist. Why did you do this? What's the purpose? What's your goal? >> Yeah, it's an experiment. I think that what's happened is that re:Invent has gotten so big, we have 65 thousand people here, that to do the party, which we do every year, its like a 35-40 thousand person concert now. Which means you have to have a location that has multiple stages and, you know, we thought about it last year and when we were watching it and we said, we're kind of throwing, like, a 4 hour music festival right now. There's multiple stages, and its quite expensive to set up that set for a party and we said well, maybe we don't have to spend all that money for 4 hours and then rip it apart because actually the rent to keep those locations for another two days is much smaller than the cost of actually building multiple stages and so we thought we would try it this year. We're very passionate about music as a business and I think we-I think our customers feel like we've thrown a pretty good music party the last few years and we thought we would try it at a larger scale as an experiment. And if you look at the economics- >> At the headliners real quick. >> The Foo Fighters are headlining on Saturday night, Anderson Paak and the Free Nationals, Brandi Carlile, Shawn Mullins, um, Willy Porter, its a good set. Friday night its Beck and Kacey Musgraves so it's a really great set of um, about thirty artists and we're hopeful that if we can build a great experience that people will want to attend that we can do it at scale and it might be something that both pays for itself and maybe, helps pay for re:Invent too overtime and you know, I think that we're also thinking about it as not just a music concert and festival the reason we named it Intersect is that we want an intersection of music genres and people and ethnicities and age groups and art and technology all there together and this will be the first year we try it, its an experiment and we're really excited about it. >> Well I'm gone, congratulations on all your success and I want to thank you we've been 7 years here at re:Invent we've been documenting the history. You got two sets now, one set upstairs. So appreciate you. >> theCUBE is part of re:Invent, you know, you guys really are apart of the event and we really appreciate your coming here and I know people appreciate the content you create as well. >> And we just launched CUBE365 on Amazon Marketplace built on AWS so thanks for letting us- >> Very cool >> John: Build on the platform. appreciate it. >> Thanks for having me guys, I appreciate it. >> Andy Jassy the CEO of AWS here inside theCUBE, it's our 7th year covering and documenting the thunderous innovation that Amazon's doing they're really doing amazing work building out the new technologies here in the Cloud computing world. I'm John Furrier, Stu Miniman, be right back with more after this short break. (Outro music)

>> Announcer: From around the globe, it's theCUBE, with digital coverage at Mirantis Launchpad 2020, brought to you by Mirantis. >> Welcome back. And I'm Stu Miniman, and this is theCUBE's coverage of Mirantis Launchpad 2020. Of course we're spending a lot of time talking about Kubernetes. We're going to be digging in talking about some of the important developer tooling that Mirantis is helping to proliferate in the market, solve some real important challenges in the space. So happy to welcome to the program Miska Kaipiainen. He is the senior director of engineering with Mirantis. Miska, thanks so much for joining us. Welcome to theCUBE. >> Thank you so much. >> All right, so Miska, I notice you've got on the Kontena sweatshirt. You were the founder of the company, did some tools. One of the tools that you and your team helped create was Lens. You and your team joined Mirantis, and recently Lens was pulled in. So maybe if you could just give us a little bit about your background. You do some coding yourself, the team that you have there, and let's tee up the conversation, 'cause it's that Lens piece that we're going to spend a bunch of time talking about. >> Yeah, so the background of what we did, basically Kontena, we started back in 2015, and we a the focus on creating technologies around the container orchestration technologies to basically to make developer tooling that are very easy to use for the developers. So during the years at Kontena, we did many different types of products, and maybe the most interesting product that we created was Lens. And now really when we joined Mirantis in January this year, so we have been able to work on Lens, and actually, since the Lens was made open source, fully open source in March this year, so it's been really kind of picking up, and now Mirantis acquired the whole technology, so we can really start investing even more in the development. >> All right, so let's talk specifically about Lens. As I teed up at the beginning, we're talking about managing multiple clusters. Gosh, and I think back to 2015. It was early on. Most people were still learning about Docker, Docker swarms, Kubernetes, Mesos. There were a lot of fights over how orchestration would be done. A little bit different discussion about what developers were doing, how they scaled out configurations, how they manage those. So help us understand kind of that core, what Lens does, and how the product has matured and expanded over those last five years. >> Yeah, so over the last five years, so originally Lens was developed for our internal product. So like Mesosphere and Docker, and they all have their own orchestration technologies even before Kubernetes. And we also started working on our own orchestration technology. And I'm a huge believer in when we are dealing with very complex technologies, so if you can visualize it and make it kind of more interesting to look at, so it will kind of help with the adoption, and it's kind of more acceptable to the market. And that's why we started doing Lens. And over the years, we turned Lens to work with Kubernetes environments, and nowadays really Lens is very much loved by the Kubernetes developers, who are those people who need to deal with the Kubernetes clusters on a daily basis. So they are not necessarily those ops people who are creating those clusters , but they are the people who actually use those clusters. >> Well, of course that that general adoption is something that, you know, super important. You have some stats you can share on, you talk about the love of developers. You said it's open source, it's available on GitHub, but how many people are using it? What are some of those usage stats? >> Yeah, so it was interesting. So when we released Lens open source under MIT license in March, so since then we have been getting, in half a year, we have been getting 8,000 stargazers on GitHub. That is kind of mind-blowing because we try to create projects and trying to create anything that would get a lot of traction in the past, but truly, it totally happened just now after years of trying. So it has been since the last six months, it's been just amazing the adopts and we have more than 50,000 users using Lens and the retention is great. People keep on coming back. So yeah, the numbers look very, very good for Lens, and we are just getting started. >> Yeah, well, it's something that this community definitely is huge growth, and anybody in this space remembers just the huge adoption of Docker, which of course the enterprise piece of Docker is now part of Mirantis. Inside those developers, help us understand a little bit more, what is it that has them really not only looking at the GitHubs, starring it, as you said, they're the stargazers. It's like a favorite, for those that aren't in the system. I've had a chance to look at some of the demos, and it seems rather straightforward. But if you could, just in your words, explain what it is that it solves for developers that otherwise they either had to do themselves or they had to cobble together a lot of different tools. We know developers out there. The wonderful thing is there's no shortage of tools to choose from. It's about the right tool that can do the right thing. >> Absolutely, absolutely. So Lens, we are calling it IDE for a reason. So we are talking about IDE for Kubernetes developers. And what does it mean actually is that we are taking all those necessary tools and technologies and packaging them, integrating them seamlessly together for the purpose of making it more easy for developers to deploy, operate, observe, inspect their workloads that are running on Kubernetes clusters. And I think the main benefits that Lens will provide for these developers is that if you're a newcomer in the Kubernetes ecosystem, so Lens gives you a very easy way to learn Kubernetes because it's so visual. And for more experienced users, it just radically improves the, let's say the speed of business and the way how you can perform things with your clusters. >> So one of the pieces that that Lens does is that multi-cluster management. So first of all, I believe, as you said, it's open source and can work with, is it any certified Kubernetes out there, whether it be from the public cloud, companies like VMware and Red Hat that have Kubernetes, of course, Mirantis has Kubernetes, too. And secondly, I think you teased out a little bit, but help help us understand a little bit. Multi-cluster management is something that the big players, you hear Azure and Google Cloud talking about how they look at managing not only other environments, but oh yeah, we can have other clusters and we can help you manage it. I think that's more on the ops side of things, as opposed to, as you said, this is really a developer tool set. >> Yeah, so of course, all the organizations, they want to most likely have some sort of centralized system where they can manage multiple clusters, and some companies provide systems for on-premises, and some public cloud vendors, they provide systems for provisioning those clusters on their own own systems. And then we have also the kind of multicloud management systems. Most of these technologies, they are really designed for the operations side, so how the IT administrations can manage these multiple clusters. So now if you look at the situation from the developer's perspective, they are now given access to certain number of clusters from different environments. And by the way, some of these clusters are also running on their local development environments on their laptops. So what Lens is doing is basically provides a unified user experience across all these clusters no matter what is the flavor of the Kubernetes. It can be the Minikube. It can be from AKS. It can be Mirantis Enterprise, Docker Enterprise offering, or whatever. So it kind of brings them all together and makes it very easy to navigate and go around and do your work. >> Yeah, well, that's, the promise of Kubernetes isn't that it just levels the playing field amongst everything. As I've talked to the founders of Kubernetes, people like Joe Beda said it's not a silver bullet. It's a thin layer. But that skillset is what's so important because there is a lot of difference between every platform they deal with. So as a developer, it's nice to have some tools that I can work across those environments. From a developer standpoint, I think it's on Windows, Linux, Mac, works across those environment. What do you hear from your customers? How are they using it? Is this something that they're like, oh hey, I can go make an adjustment on my mobile when I'm not necessarily in the office? Are we not quite there yet? >> Actually, it's kind of funny, because sometimes we hear these type of requests that we would like to have a mobile app version of Lens. I don't know how that would actually work in practice. So we haven't been doing anything on that front yet. I think still the most common use case is that developers, they are given access to clusters from somewhere and they are just desperately trying to find a kind of convenient way how to navigate around these different clusters and how to manage their workloads. And I think Lens is hitting the sweet spot in there with the ease of use. >> All right, so let me understand. It's been open sourced, yet Mirantis owns it. Is there a service or support? Does this tie into other products in the Mirantis portfolio? How do people get it? What do they need to, if anything, pay for it? And help us understand how this fits into the broader Mirantis story. >> Yes, so it's still kind of early days, so we just kind of announced that Lens is now part of Mirantis, let's say portfolio. So I must say that still the kind of main focus for us is around improving Lens and making it better for developers. So that's much more important than trying to think about the ways how potentially we could monetize this. So, but there are plans going ahead, going around for different ways how we can better support bigger enterprises who want to start using Lens in a big scale. >> Well, yeah, that's so important. Of course, developers, we need to lower the friction, help them adopt things fast. Miska, just get your general viewpoint, though. One of the big value propositions that Mirantis has is of course allowing enterprises to take advantage of these new types of solutions, especially today around Kubernetes. So help us understand from your standpoint the philosophy of what your team's helping to build and the customer engagements that you're having. >> Yes, so Mirantis, of course, has a broad portfolio of products, and many of those products, of course, are related to Kubernetes. And so we have many products which I'm also one of the leading development efforts around those. So some of the products are related to how to manage image repositories and registries. Some of them are related to how to handle the helm charts, which has basically become the defacto packaging format for Kubernetes applications. And we are kind of trying to bring all these different products and technologies together in a way that make it even more easy for developers then to access through Lens. So it's still a little bit work in progress, of course, since the Lens ecosystem is quite new, but we are on track there trying to make a beautiful one kind of experience for our customers. >> All right, well, final question I have for you. As you said, it's new there, but it gives a little taste as to feedback you're getting from the community. Anything we should be looking at on kind of the near to mid-term road map when it comes to Lens. >> Oh yeah, so we are just barely scratching the surface of the potential on what we can do with Lens. So one of the big features that we will be releasing still during this year in a couple of months time is going to be the extension API, which will allow all these cloud-native technology ecosystem vendors to bring their own technologies easily available and accessible through Lens. So it is possible for third parties to extend the user interface with their own kind of unique features and visualizations. And we are already actively working with certain partners to integrate their technologies through this extension API. So that's going to be huge. It's going to be game-changer. >> Well, the great thing about an open source project is people can go out, they can grab it now, they can give feedback, participate in the community. Miska, thank you so much for joining us and great to chat. >> Thank you for having me. Thank you. >> All right, stay with us for more coverage of Mirantis Launchpad 2020. I'm Stu Miniman and thank you for watching theCUBE. (bright music)

>> Narrator: From around the globe it's the CUBE with digital coverage of Mirantis Launchpad 2020, brought to you by Mirantis. >> Welcome back, I'm Stu Miniman, and this is the CUBE's coverage of Mirantis Launchpad 2020. And always love when we get to be able to talk to the practitioners that are using some of the technologies here. One of the interesting things we've been digging into is lens, the IDE in this space, as it's being referred to. So, happy to welcome to the program Matti Paksula. He is the founder and chief technology officer at supervisor.com. Matti, thanks so much for joining us. >> Thank you, thank you thank you for having me. >> So, if you could just, you help us understand, you know, your company as supervisor.com. What's the background as the founder? What was kind of the impetus to creating that business too? >> Sure, so, supervisor was this like super simple because we believe, and we know, that the only way to tests websites, if they can handle load, for example, eCommerce sites on black Friday, or when you, or, just about to make a product launch or that kind of stuff. Is just by sending real web browsers to the site. That's actually click and scroll and do it all the same things as a real users will do. But, and unlike, our secret thing is that we can do it, like before Black Friday. So, if somebody wants to simulate if they can handle like 2000 users or 5000 users, then they can use supervisor.com to make it happen like today. >> So, I'm just curious, you know, the concern always is about the DDoS attacks and the like. Do you help companies along that line too? Or is it more the, the testing for proper traffic and we leave the security aspect to somebody else? >> Yeah, well, like with any load testing tool, you have to verify yourself somehow. And with us, it's super easy because we integrated with Google analytics. And if you authorize us to read your Google Analytics Data, then we know that you are allowed to test your site. >> Wonderful, well, as I said in the lead, you're using lens, my understanding you've been using it since the early day, of course, a technology that closed source Mirantis has, has acquired that and the team, it's now also open source. So if you could bring us back to, you know, how did you get involved with lens? What was the, you know, the problem statement that it helped you resolve? >> Yeah, sure. So the (inaudible) super briefly is that Lens was developed by this startup called Condena, it's a finish startup, and they made a couple of attempts in container orchestration, like before Kubernetes and then Coobernetti's game. And they just felt like Kubernetes is super hard to kind of visualize or like, understand what's going on because you have these containers flying around, you have nodes going in going out. So they built this lens and then since I'd be working with those guys from 2015 or so, I was like one of the first outside users, or probably the first user outside of the company. >> So, that, pretty neat that you had that, you know, that project that they were doing. As an early user, you know, give us a little bit of that journey. What does it enable for your company? You know, how has it expanded from kind of the early use cases to where it is today. >> Yeah. So, if you're using Kubernetes traditionally, or like how most of the people who haven't yet heard about Lens use it is by or from the command line. So that's where you use keep CTL or cube control. You say cube CTL pod, and then you get the listing pod. But the problem is that, all that data is stale on the screen. So if you trend try to, for example, delete a port and you issue cutesy delete pod, blah, blah, blah, blah. And then you enter on the pod all ready, it might be gone. So Lens makes like everything real time. And like, if you try to delete something with lens, you move your mouse on top of the pod. And if it's getting deleted, you know, this, it, because it just disappears from your screen and like, it's not there anymore. And I think that's a huge a productivity boost in a way, that's how you can like get more and more stuff done every day as these kind of like, when you are a developer or CSI admin or whatever you need to kind of like, see what's happening in your cluster and house that note and pods are doing. And that. So back to your question, when you asked, like, how has the evolved lens it's like nowadays it's super stable. It handles big workloads very well. In the very, very early on, they had some performance issues with like, like large clusters, for example, when supervisor, when we run a load test with, for example, 10,000 concurrent web browsers. So basically what we have in Kubernetes is we have 10,000 pods. And then when you connect something like lens to it, it's just like started to spin up my fans until on the laptop, still about eating all the Ram. So I helped them a lot with my special use case of running like super big Ephemeral workloads there. >> Yeah. It's an interesting discussion. And in the whole, you know, container space, there's all that discussion of scale(chuckling). You know, of course everybody thinks back to Google and how they use it. So we know it can go really big, but, you know, environments, I needed to be able to work really small or youth cases like yours. I needed to be able to, you know, burst use that usage when you need it and go back on that a less density that we hope for in, in cloud. So I'm curious any, what's your expectation with it, you know, going open source, coming into Mirantis as a, as a longtime user of it, you know, what do you expect to see? >> Well, I think like Mirantis offers the right kind of home for the product, because they really get what's happening in the space. And I think they're like commercial offering on top of the open source will be around authentication. That's why, like, I kind of understood from the press release. And I think it makes sense because like, developers don't want to pay for these kinds of tools. And there are other tools that are commercial. And even if it's like just 100 bucks per year, I think that's still not going to work out with most of the developers and you kind of need this kind of long tail developer adoption for these kinds of products to succeed. And I think that, like, that's kind of like authentication, like centralized, like who can see what, and that kind of stuff. It doesn't like affect most of the startups or Indie Devs, but like for any company who was doing it like a real business, those are the features that are needed. And when you use that, the products for business, then I think it makes sense to pay also. >> Yeah, absolutely. There's always that, challenge developers of course love open source tools if they can use them. And, you know, the packaging, the monetization, isn't a question for you it's(chuckling), you know, for the Miranda's team. What would you say to your peers out there, people that are in this space, you know, what are the areas that they say, Oh, you know, if I have this type of environment, or if I have type, if I have this team, this is what lens will really be awesome for me. What are some of the things that you would recommend to your peers out there from, from all the usage that you've done? >> Yeah. So let's say three things. The first thing is what I already mentioned the real timeness that everything updates live, the second thing is the integrated metrics. So you cannot, for example, follow how much memory or CPU something is consuming. It's super helpful when you want to like, understand what's really going on and how much resources something is taken. And then the third thing is that Landis is great for debugging because once you have deployed something and something is off, and it's kind of hard to reproduce locally, especially with this kind of a microservice architecture, whatever, what you might have is that you can just like go inside at any part or note instantly from the UI. You don't have to, like, again, you don't have to use cubes sheets, the L blah, blah, blah, blah, blah. And, and you have just like in there also, because you are already in the. But its the fourth thing is that if you manage multiple Kubernetes clusters, it's super easy to accidentally connect to the wrong cluster. But like, if you have, some visual tool where you can see in I'm in this. I mean, my production cluster are I'm in my staging cluster and you make the selection like visually there, then all the cube sees and everything works against that's a cluster. So I think that's like very helpful so that you don't actually accidentally delete something from production, for example. >> Wonderful. Last question I have for you either blend specifically, or kind of the eco-system around it, what, would be on your wishlist for, as I said, either lance specifically, or to, you know, manage your environments surrounding that, you know, what, what would you be asking kind of Miranda and, the broader eco-system for? >> I know that, well, let me think. Yeah. Okay. First of all, I have like maybe 50, 60 issues still open a GitHub that I have opened there. So that's like my wish list, but like, if you, they got like longer term, I think it would just be great, if you could actually like start deployments from Lance, there are a bunch of deployment tools, like customize and help. But again, if you just wanted to get something running quickly, I think integrating that to Lance would be like, super good. Just you it's just like click like I want to deploy this app. That's, that's something I'm looking forward to. >> Yeah, absolutely. Everybody wants that simplicity. All right. Well, Hey, thank you so much. Great to hear the feedback. We always talk about the people that developed code, as well as, you know, the people that do the beta testing and the feedback. So critically important to the maturation development of everything that's based though. Thanks so much for joining us. >> Thank you. >> Stay tuned for more coverage from Mirantis Launchpad 2020 I'm Stu Miniman. And thank you for watching the cube. (upbeat music)

>>Hello, everyone. My name is Rick Pew. I'm a senior product manager at Mirant. This and I have been working on the Doctor Enterprise Container Cloud for the last eight months. Today we're gonna be talking about multi cloud kubernetes. So the first thing to kind of look at is, you know, is multi cloud rial. You know, the terms thrown around a lot and by the way, I should mention that in this presentation, we use the term multi cloud to mean both multi cloud, which you know in the technical sense, really means multiple public clouds and hybrid cloud means public clouds. And on Prem, uh, we use in this presentation will use the term multi cloud to refer to all different types of multiple clouds, whether it's all public cloud or a mixture of on Prem and Public Cloud or, for that matter, multiple on Prem clouds as doctor and price container. Cloud supports all of those scenarios. So it really well, let's look at some research that came out of flex era in their 2020 State of the cloud report. You'll notice that ah, 33% state that they've got multiple public and one private cloud. 53% say they've got multiple public and multiple private cloud. So if you have those two up, you get 86% of the people say that they're in multiple public clowns and at least one private cloud. So I think at this stage we could say that multi cloud is a reality. According to 4 51 research, you know, a number of CEO stated that the strong driver their desire was to optimize cost savings across their private and public clouds. Um, they also wanted to avoid vendor lock in by operating in multiple clouds and try to dissuade their teams from taking too much advantage of a given providers proprietary infrastructure. But they also indicated that there the complexity of using multiple clouds hindered the rate of adoption of doing it doesn't mean they're not doing it. It just means that they don't go assed fast as they would like to go in many cases because of the complexity. And here it Miranda's. We surveyed our customers as well, and they're telling us similar things, you know. Risk management, through the diversification of providers, is key on their list cost optimization and the democratization of allowing their development teams, uh, to create kubernetes clusters without having to file a nightie ticket. But to give them a self service, uh, cloud like environment, even if it's on prem or multi cloud to give them the ability to create their own clusters, resize their own clusters and delete their own clusters without needing to have I t. Or of their operations teams involved at all. But there are some challenges with this, with the different clouds you know require different automation. Thio provisioned the underlying infrastructure or deploy and operating system or deployed kubernetes, for that matter, in a given cloud. You could say that they're not that complicated. They all have, you know, very powerful consoles and a P I s to do that. But did you get across three or four or five different clouds? Then you have to learn three or four or five different AP ice and Web consoles in order to make that happen on in. That scenario is difficult to provide self service for developers across all the cloud options, which is what you want to really accelerate your application innovation. So what's in it for me? You know We've got a number of roles and their prizes developers, operators and business leaders, and they have somewhat different needs. So when the developer side the need is flexibility to meet their development schedules, Number one you know they're under constant pressure to produce, and in order to do that, they need flexibility and in this case, the flexibility to create kubernetes clusters and use them across multiple clouds. Now they also have C I C D tools, and they want them to be able to be normalized on automated across all of the the on prim and public clouds that they're using. You know, in many cases they'll have a test and deployment scenario where they'll want to create a cluster, deploy their software, run their test, score the tests and then delete that cluster because the only point of that cluster, perhaps, was to test ah pipeline of delivery. So they need that kind of flexibility. From the operator's perspective, you know, they always want to be able to customize the control of their infrastructure and deployment. Uh, they certainly have the desire to optimize their optics and Capex fans. They also want to support their develops teams who many times their their customers through a p I access for on Prem and public clouds burst. Scaling is something operators are interested in, and something public clouds can provide eso the ability to scale out into public clouds, perhaps from there on prem infrastructure in a seamless manner. And many times they need to support geographic distribution of applications either for compliance or performance reasons. So having you know, data centers all across the world and be able to specifically target a given region, uh, is high on their list. Business leaders want flexibility and confidence to know that you know, they're on prim and public cloud uh, deployments. Air fully supported. They want to be able, like the operator, optimize their cloud, spends business leaders, think about disaster recovery. So having the applications running and living in different data centers gives them the opportunity to have disaster recovery. And they really want the flexibility of keeping private data under their control. On on Prem In certain applications may access that on Prem. Other applications may be able to fully run in the cloud. So what should I look for in a container cloud? So you really want something that fully automates these cluster deployments for virtual machine or bare metal. The operating system, uh, and kubernetes eso It's not just deploying kubernetes. It's, you know, how do I create my underlying infrastructure of a VM or bare metal? How do I deploy the operating system? And then, on top of all that, I want to be able to deploy kubernetes. Uh, you also want one that gives a unified cluster lifecycle management across all the clouds. So these clusters air running software gets updated. Cooper Netease has a new release cycle. Uh, they come out with something new. It's available, you know, How do you get that across all of your clusters? That air running in multiple clouds. We also need a container cloud that can provide you the visibility through logging, monitoring and alerting again across all the clouds. You know, many offerings have these for a particular cloud, but getting that across multiple clouds, uh, becomes a little more difficult. The Doctor Enterprise Container cloud, you know, is a very strong solution and really meets many of these, uh, dimensions along the left or kind of the dimensions we went through in the last slide we've got on Prem and public clouds as of RG A Today we're supporting open stack and bare metal for the on Prem Solutions and AWS in the public cloud. We'll be adding VM ware very soon for another on Prem uh, solution as well as azure and G C P. So thank you very much. Uh, look forward, Thio answering any questions you might have and we'll call that a rap. Thank you. >>Hi, Rick. Thanks very much for that. For that talk, I I am John James. You've probably seen me in other sessions. I do marketing here in Miran Tous on. I wanted to to take this opportunity while we had Rick to ask some more questions about about multi cloud. It's ah, potentially a pretty big topic, isn't it, Rick? >>Yeah. I mean, you know, the devil's in the details and there's, uh, lots of details that we could go through if you'd like, be happy to answer any questions that you have. >>Well, we've been talking about hybrid cloud for literally years. Um, this is something that I think you know, several generations of folks in the in the I. A s space doing on premise. I s, for example, with open stack the way Miran Tous Uh does, um, found, um, you know, thought that that it had a lot of potential. A lot of enterprises believed that, but there were There were things stopping people from from making it. Really, In many cases, um, it required a very, ah, very high degree of willingness to create homogeneous platforms in the cloud and on the premise. Um, and that was often very challenging. Um, but it seems like with things like kubernetes and with the isolation provided by containers, that this is beginning to shift, that that people are actually looking for some degree of application portability between their own Prem and there and their cloud environments. And that this is opening up, Uh, you know, investment on interest in pursuing this stuff. Is that the right perception? >>Yeah. So let's let's break that down a little bit. So what's nice about kubernetes is through the a. P. I s are the same. Regardless of whether it's something that Google or or a W s is offering as a platform as a service or whether you've taken the upstream open source project and deploy it yourself on parameter in a public cloud or whatever the scenario might be or could be a competitor of Frances's product, the Kubernetes A. P I is the same, which is the thing that really gives you that application portability. So you know, the container itself is contained arising, obviously your application and minimizing any kind of dependency issues that you might have And then the ability to deploy that to any of the coup bernetti clusters you know, is the same regardless of where it's running, the complexity comes and how doe I actually spend up a cluster in AWS and open stack and D M Where and gp An azure. How do I build that infrastructure and and spin that up and then, you know, used the ubiquitous kubernetes a p I toe actually deploy my application and get it to run. So you know what we've done is we've we've unified and created A I use the word normalized. But a lot of times people think that normalization means that you're kind of going to a lowest common denominator, which really isn't the case and how we've attacked the the enabling of multi cloud. Uh, you know, what we've done is that we've looked at each one of the providers and are basically providing an AP that allows you to utilize. You know, whatever the best of you know, that particular breed of provider has and not, uh, you know, going to at least common denominator. But, you know, still giving you a ah single ap by which you can, you know, create the infrastructure and the infrastructure could be on Prem is a bare metal infrastructure. It could be on preeminent open stack or VM ware infrastructure. Any of the public clouds, you know, used to have a a napi I that works for all of them. And we've implemented that a p i as an extension to kubernetes itself. So all of the developers, Dev ops and operators that air already familiar operating within the, uh, within the aapi of kubernetes. It's very, very natural. Extension toe actually be able to spend up these clusters and deploy them >>Now that's interesting. Without giving away, obviously what? Maybe special sauce. Um, are you actually using operators to do this in the Cooper 90? Sense of the word? >>Yes. Yeah, we've extended it with with C R D s, uh, and and operators and controllers, you know in the way that it was meant to be extended. So Kubernetes has a recipe on how you extend their A P I on that. That's what we used as our model. >>That, at least to me, makes enormous sense. Nick Chase, My colleague and I were digging into operators a couple of weeks ago, and that's a very elegant technology. Obviously, it's a it's evolving very fast, but it's remarkably unintimidating once you start trying to write them. We were able toe to compose operators around Cron and other simple processes and just, >>you know, >>a couple of minutes on day worked, which I found pretty astonishing. >>Yeah, I mean, you know, Kubernetes does a lot of things and they spent a lot of effort, um, in being able, you know, knowing that their a p I was gonna be ubiquitous and knowing that people wanted to extend it, uh, they spent a lot of effort in the early development days of being able to define that a p I to find what an operator was, what a controller was, how they interact. How a third party who doesn't know anything about the internals of kubernetes could add whatever it is that they wanted, you know, and follow the model that makes it work. Exactly. Aziz, the native kubernetes ap CSTO >>What's also fascinating to me? And, you know, I've I've had a little perspective on this over the past, uh, several weeks or a month or so working with various stakeholders inside the company around sessions related to this event that the understanding of how things work is by no means evenly distributed, even in a company as sort of tightly knit as Moran Tous. Um, some people who shall remain nameless have represented to me that Dr Underprice Container Cloud basically works. Uh, if you handed some of the EMS, it will make things for you, you know, and this is clearly not what's going on that that what's going on is a lot more nuanced that you are using, um, optimal resource is from each provider to provide, uh, you know, really coherent architected solutions. Um, the load balancing the d. N s. The storage that this that that right? Um all of which would ultimately be. And, you know, you've probably tried this. I certainly have hard to script by yourself in answerable or cloud formation or whatever. Um, this is, you know, this is not easy work. I I wrote a about the middle of last year for my prior employer. I wrote a dip lawyer in no Js against the raw aws a piece for deployment and configuration of virtual networks and servers. Um, and that was not a trivial project. Um, it took a long time to get thio. Uh, you know, a dependable result. And to do it in parallel and do other things that you need to do in order to maintain speed. One of the things, in fact, that I've noticed in working with Dr Enterprise Container Cloud recently, is how much parallelism it's capable of within single platforms. It's It's pretty powerful. I mean, if you want to clusters to be deployed simultaneously, that's not hard for Doc. Aerated price container cloud to dio on. I found it pretty remarkable because I have sat in front of a single laptop trying to churn out of cluster under answerable, for example, and just on >>you get into that serial nature, your >>poor little devil, every you know, it's it's going out and it's ssh, Indian Terminals and it's pretending it's a person and it's doing all that stuff. This is much more magical. Um, so So that's all built into the system to, isn't it? >>Yeah. Interesting, Really Interesting point on that. Is that you know, the complexity isn't not necessarily and just creating a virtual machine because all of these companies have, you know, spend a lot of effort to try to make that as easy as possible. But when you get into networking, load balancing, routing, storage and hooking those up, you know, two containers automating that if you were to do that in terror form or answerable or something like that is many, many, many lines of code, you know, people have to experiment. Could you never get it right the first or second or the third time? Uh, you know, and then you have to maintain that. So one of the things that we've heard from customers that have looked a container cloud was that they just can't wait to throw away their answerable or their terror form that they've been maintaining for a couple of years. The kind of enables them to do this. It's very brittle. If if the clouds change something, you know on the network side, let's say that's really buried. And it's not something that's kind of top of mind. Uh, you know, your your thing fails or maybe worse, you think that it works. And it's not until you actually go to use it that you notice that you can't get any of your containers. So you know, it's really great the way that we've simplified that for the users and again democratizing it. So the developers and Dev ops people can create these clusters, you know, with ease and not worry about all the complexities of networking and storage. >>Another thing that amazed me as I was digging into my first, uh, Dr Price container Cloud Management cluster deployment was how, uh, I want I don't want to use the word nuanced again, but I can't think of a better word. Nuanced. The the security thinking is in how things air set up. How, um, really delicate the thinking about about how much credential power you give to the deploy. Er the to the seed server that deploys your management cluster as opposed thio Um uh or rather the how much how much administrative access you give to the to the administrator who owns the entire implementation around a given provider versus how much power the seed server gets because that gets its own user right? It gets a bootstrap user specifically created so that it's not your administrator, you know, more limited visibility and permissions. And this whole hierarchy of permissions is then extended down into the child clusters that this management cluster will ultimately create. So that Dev's who request clusters will get appropriate permissions granted within. Ah, you know, a corporate schema of permissions. But they don't get the keys to the kingdom. They don't have access to anything they don't you know they're not supposed to have access to, but within their own scope, they're safe. They could do anything they want, so it's like a It's a It's a really neat kind of elegant way of protecting organizations against, for example, resource over use. Um, you know, give people the power to deploy clusters, and basically you're giving them the power toe. Make sure that a big bill hits you know, your corporate accounting office at the end of the billing cycle, um so there have to be controls and those controls exist in this, you know, in this. >>Yeah, And there's kind of two flavors of that. One is kind of the day one that you're doing the deployment you mentioned the seed servers, you know, And then it creates a bastion server, and then it creates, you know, the management cluster and so forth, you know, and how all those permissions air handled. And then once the system is running, you know, then you have full access to going into key cloak, which is a very powerful open source identity management tool on you have dozens of, you know, granular permissions that you can give to an individual user that gives them permission to do certain things and not others within the context of kubernetes eso. It's really well thought out. And the defaults, you know, our 80% right. You know, there's very few people are gonna have to go in and sort of change those defaults. You mentioned the corporate directory. You know, hooks right upto l bap or active directory can suck everybody down. So there's no kind of work from a day. One perspective of having to go add. You know everybody that you can think of different teams and groupings of of people. Uh, you know, that's kind of all given from the three interface to the corporate directory. And so it just makes kind of managing the users and and controlling who can do what? Uh, really easy. And, you know, you know, day one day two it's really almost like our one hour to write because it's just all the defaults were really well thought out. You can deploy, you know, very powerful doctor and price container cloud, you know, within an hour, and then you could just start using it. And you know, you can create users if you want. You can use the default users. That air set up a time goes on, you can fine tune that, and it's a really, really nice model again for the whole frictionless democratization of giving developers the ability to go in and get it out of, you know, kind of their way and doing what they want to do. And I t is happy to do that because they don't like dozens of tickets and saying, you know, create a cluster for this team created cluster for that team. You know, here's the size of these guys. Want to resize when you know let's move all that into a self service model and really fulfill the prophecy of, you know, speeding up application development. >>It strikes me is extremely ironic that one of the things that public cloud providers bless them, uh, have always claimed, is that their products provide this democratization when in the experience, I think my own experience and the experience of most of the AWS developers, for example, not toe you know, name names, um, that I've encountered is that an initial experience of trying to start start a virtual machine and figuring out how to log into it? A. W s could take the better part of an afternoon. It's just it's not familiar once you have it in your fingers. Boom. Two seconds, right. But, wow, that learning curve is steep and precipitous, and you slip back and you make stupid mistakes your first couple 1000 times through the loop. Um, by letting people skip that and letting them skip it potentially on multiple providers, in a sense, I would think products like this are actually doing the public cloud industry is, you know, a real surface Hide as much of that as you can without without taking the power away. Because ultimately people want, you know, to control their destiny. They want choice for a reason. Um, and and they want access to the infinite services And, uh, and, uh, innovation that AWS and Azure and Google are all doing on their platforms. >>Yeah, you know, and they're solving, uh, very broad problems in the public clouds, you know, here were saying, you know, this is a world of containers, right? This is a world of orchestration of these containers. And why should I have to worry about the underlying infrastructure, whether it's a virtual machine or bare metal? You know, I shouldn't care if I'm an application developer developing some database application. You know, the last thing I wanna worry about is how do I go in and create a virtual machine? Oh, this is running. And Google. It's totally different than the one I was creating. An AWS I can't find. You know where I get the I P address in Google. It's not like it was an eight of us, you know, and you have to relearn the whole thing. And that's really not what your job is. Anyways, your job is to write data base coat, for example. And what you really want to do is just push a button, deploy a nor kiss traitor, get your app on it and start debugging it and getting it >>to work. Yep. Yeah, it's It's powerful. I've been really excited to work with the product the past week or so, and, uh, I hope that folks will look at the links at the bottoms of our thank you slides and, uh, and, uh, avail themselves of of free trial downloads of both Dr Enterprise Container, Cloud and Lens. Thank you very much for spending this extra time with me. Rick. I I think we've produced some added value here for for attendees. >>Well, thank you, John. I appreciate your help. >>Have a great rest of your session by bike. >>Okay, Thanks. Bye.

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

>>Welcome everyone. Good morning. Good evening to all of you around the world. I am so excited to welcome you to launch bad our annual conference for customers, for partners, for our own colleagues here at Mirandes. This is meant to be a forum for learning, for sharing for discovery. One of openness. We're incredibly excited. Do you have you here with us? I want to take a few minutes this morning and opened the conference and share with you first and foremost where we're going as a company. What is our vision then? I also want to share with you on update on what we have been up to you for the past year. Especially with two important acquisitions, Doc Enterprise and then container and lens. And what are some of the latest developments at Mirandes? And then I'll close also with an exciting announcement that we have today, which we hope is going to be interesting and valuable for all of you. But let me start with our mission. What are we here to Dio? It's very simple. We want to help you the ship code faster. This is something that we're very excited about, something that we have achieved for many of you around the world. And we just want thio double down on. We feel this is a mission that's very much worthwhile and relevant and important to you. Now, how do we do that? How do we help you ship code faster? There are three things we believe in. We believe in this world of cloud. Um, choice is incredibly important. We all know that developers want to use the latest tools. We all know that cloud technology is evolving very quickly and new innovations appear, um, very, very quickly, and we want to make them available to you. So choice is very important. At the same time, consuming choice can be difficult. So our mission is to make choice simple for you to give developers and operators simplicity and then finally underpinning everything that we dio is security. These are the three big things that we invest in and that we believe that choice, simplicity and security and the foundation technology that we're betting on to make that happen for you is kubernetes many of you, many of our customers use kubernetes from your aunties today and they use it at scale. And this is something we want to double down on the fundamental benefit. The our key promise we want to deliver for you is Speed. And we feel this is very relevant and important and and valuable in the world that we are in today. So you might also be interested in what have been our priorities since we acquired Doc Enterprise. What has happened for the past year at Miranda's And there are three very important things we focused on as a company. The first one is customer success. Um, when we acquired Doc Enterprise, the first thing we did is listen to you connect with the most important customers and find out what was your sentiment. What did you like? What were you concerned about? What needed to improve? How can we create more value and a better experience for you? So, customers success has been a top of our list of priorities ever since. And here is what we've heard here is what you've told us. You've told us that you very much appreciated the technology that you got a lot of value out of the technology, but that at the same time, there are some things that we can do better. Specifically, you wanted better. Sele's better support experience. You also wanted more clarity on the road map. You also wanted to have a deeper alignment and a deeper relationship between your needs and your requirements and our our technical development that keep people in our development organization are most important engineers. So those three things are were very, very important to you and they were very important to us here. So we've taken that to heart and over the past 12 months, we believe, as a team, we have dramatically improved the customer support experience. We introduced new SLS with prod care. We've rolled out a roadmap to many many of our customers. We've taken your requirements of the consideration and we've built better and deeper relationships with so many of you. And the evidence for that that we've actually made some progress is in a significant increase off the work clothes and in usage of all platforms. I was so fortunate that we were able to build better and stronger relationships and take you to the next level of growth for companies like Visa like soc T general, like nationwide, like Bosch, like Axa X l like GlaxoSmithKline, like standard and Poor's, like Apple A TNT. So many, many off you, Many of all customers around the world, I believe over the past 12 months have experienced better, better, better support strong s L. A s a deeper relationship and a lot more clarity on our roadmap and our vision forward. The second very big priority for us over the last year has been product innovation. This is something that we are very excited about that we've invested. Most of our resource is in, and we've delivered some strong proof points. Doc Enterprise 3.1 has been the first release that we have shipped. Um, as Mirant is as the unified company, Um, it's had some big innovative features or Windows support or a I and machine learning use cases and a significant number off improvements in stability and scalability earlier this year. We're very excited to have a quiet lens and container team, which is by far the most popular kubernetes. I'd, um, in the world today and every day, 600 new users are starting to use lens to manage the community's clusters to deploy applications on top of communities and to dramatically simplify the experience for communities for operators and developers alike. That is a very big step forward for us as a company. And then finally, this week at this conference, we announcing our latest product, which we believe is a huge step forward for Doc Enterprise and which we call Doc Enterprise, Container Cloud, and you will hear a lot more about that during this conference. The third vector of development, the third priority for us as a company over the past year was to become mawr and Mawr developer centric. As we've seen over the past 10 years, developers really move the world forward. They create innovation, they create new software. And while our platform is often managed and run and maybe even purchased by RT architects and operators and I T departments, the actual end users are developers. And we made it our mission a za company, to become closer and closer to developers to better understand their needs and to make our technology as easy and fast to consume as possible for developers. So as a company, we're becoming more and more developers centric, really. The two core products which fit together extremely well to make that happen, or lens, which is targeted squarely at a new breed off kubernetes developers sitting on the desktop and managing communities, environments and the applications on top on any cloud platform anywhere and then DACA enterprise contain a cloud which is a new and radically innovative, contain a platform which we're bringing to market this week. So with this a za background, what is the fundamental problem which we solve for you, for our customers? What is it that we feel are are your pain points that can help you resolve? We see too very, very big trends in the world today, which you are experiencing. On one side, we see the power of cloud emerging with more features mawr innovation, more capabilities coming to market every day. But with those new features and new innovations, there is also an exponential growth in cloud complexity and that cloud complexity is becoming increasingly difficult to navigate for developers and operators alike. And at the same time, we see the pace of change in the economy continuing to accelerate on bits in the economy and in the technology as well. So when you put these two things together on one hand, you have MAWR and Mawr complexity. On the other hand, you have fast and faster change. This makes for a very, very daunting task for enterprises, developers and operators to actually keep up and move with speed. And this is exactly the central problem that we want to solve for you. We want to empower you to move with speed in the middle off rising complexity and change and do it successfully and with confidence. So with that in mind, we are announcing this week at LAUNCHPAD a big and new concept to take the company forward and take you with us to create value for you. And we call this your cloud everywhere, which empowers you to ship code faster. Dr. Enterprise Container Cloud is a lynch bit off your cloud everywhere. It's a radical and new container platform, which gives you our customers a consistent experience on public clouds and private clouds alike, which enables you to ship code faster on any infrastructure, anywhere with a cohesive cloud fabric that meets your security standards that offers a choice or private and public clouds and offer you a offers you a simple, an extremely easy and powerful to use experience. for developers. All of this is, um, underpinned by kubernetes as the foundation technology we're betting on forward to help you achieve your goals at the same time. Lens kubernetes e. It's also very, very well into the real cloud. Every concept, and it's a second very strong linchpin to take us forward because it creates the developing experience. It supports developers directly on their desktop, enabling them Thio manage communities workloads to test, develop and run communities applications on any infrastructure anywhere. So Doc, Enterprise, Container, Cloud and Lens complement each other perfectly. So I'm very, very excited to share this with you today and opened the conference for you. And with this I want to turn it over to my colleague Adam Parker, who runs product development at Mirandes to share a lot more detail about Doc Enterprise Container Cloud. Why we're excited about it. Why we feel is a radical step forward to you and why we feel it can add so much value to your developers and operators who want to embrace the latest kubernetes technology and the latest container technology on any platform anywhere. I look forward to connecting with you during the conference and we should all the best. Bye bye. >>Thanks, Adrian. My name is Adam Parco, and I am vice president of engineering and product development at Mirant ISS. I'm extremely excited to be here today And to present to you Dr Enterprise Container Cloud Doc Enterprise Container Cloud is a major leap forward. It Turpal charges are platform. It is your cloud everywhere. It has been completely designed and built around helping you to ship code faster. The world is moving incredibly quick. We have seen unpredictable and rapid changes. It is the goal of Docker Enterprise Container Cloud to help navigate this insanity by focusing on speed and efficiency. To do this requires three major pillars choice, simplicity and security. The less time between a line of code being written and that line of code running in production the better. When you decrease that cycle, time developers are more productive, efficient and happy. The code is higher, quality contains less defects, and when bugs are found are fixed quicker and more easily. And in turn, your customers get more value sooner and more often. Increasing speed and improving developer efficiency is paramount. To do this, you need to be able to cycle through coding, running, testing, releasing and monitoring all without friction. We enabled us by offering containers as a service through a consistent, cloudlike experience. Developers can log into Dr Enterprise Container Cloud and, through self service, create a cluster No I T. Tickets. No industry specific experience required. Need a place to run. A workload simply created nothing quicker than that. The clusters air presented consistently no matter where they're created, integrate your pipelines and start deploying secure images everywhere. Instantly. You can't have cloud speed if you start to get bogged down by managing, so we offer fully automated lifecycle management. Let's jump into the details of how we achieve cloud speed. The first is cloud choice developers. Operators add mons users they all want. In fact, mandate choice choice is extremely important in efficiency, speed and ultimately the value created. You have cloud choice throughout the full stack. Choice allows developers and operators to use the tooling and services their most familiar with most efficient with or perhaps simply allows them to integrate with any existing tools and services already in use, allowing them to integrate and move on. Doc Enterprise Container Cloud isn't constructive. It's open and flexible. The next important choice we offer is an orchestration. We hear time and time again from our customers that they love swarm. That's simply enough for the majority of their applications. And that just works that they have skills and knowledge to effectively use it. They don't need to be or find coop experts to get immediate value, so we will absolutely continue to offer this choice and orchestration. Our existing customers could rest assure their workloads will continue to run. Great as always. On the other hand, we can't ignore the popularity that growth, the enthusiasm and community ecosystem that has exploded with communities. So we will also be including a fully conforming, tested and certified kubernetes going down the stock. You can't have choice or speed without your choice and operating system. This ties back to developer efficiency. We want developers to be able to leverage their operating system of choice, were initially supporting full stack lifecycle management for a bun, too, with other operating systems like red hat to follow shortly. Lastly, all the way down at the bottom of stack is your choice in infrastructure choice and infrastructure is in our DNA. We have always promoted no locking and flexibility to run where needed initially were supporting open stock AWS and full life cycle management of bare metal. We also have a road map for VM Ware and other public cloud providers. We know there's no single solution for the unique and complex requirements our customers have. This is why we're doubling down on being the most open platform. We want you to truly make this your cloud. If done wrong, all this choice at speed could have been extremely complex. This is where cloud simplification comes in. We offer a simple and consistent as a service cloud experience, from installation to day to ops clusters Air created using a single pane of glass no matter where they're created, giving a simple and consistent interface. Clusters can be created on bare metal and private data centers and, of course, on public cloud applications will always have specific operating requirements. For example, data protection, security, cost efficiency edge or leveraging specific services on public infrastructure. Being able to create a cluster on the infrastructure that makes the most sense while maintaining a consistent experience is incredibly powerful to developers and operators. This helps developers move quick by being able to leverage the infra and services of their choice and operators by leveraging, available, compute with the most efficient and for available. Now that we have users self creating clusters, we need centralized management to support this increase in scale. Doc Enterprise Container cloud use is the single pane of glass for observe ability and management of all your clusters. We have day to ops covered to keep things simple and new. Moving fast from this single pane of glass, you can manage the full stack lifecycle of your clusters from the infra up, including Dr Enterprise, as well as the fully automated deployment and management of all components deployed through it. What I'm most excited about is Doc Enterprise Container Cloud as a service. What do I mean by as a service doctor? Enterprise continue. Cloud is fully self managed and continuously delivered. It is always up to date, always security patched, always available new features and capabilities pushed often and directly to you truly as a service experience anywhere you want, it run. Security is of utmost importance to Miranda's and our customers. Security can't be an afterthought, and it can't be added later with Doctor and a price continued cloud, we're maintaining our leadership and security. We're doing this by leveraging the proven security and Dr Enterprise. Dr. Enterprise has the best and the most complete security certifications and compliance, such as Stig Oscar, How and Phipps 1 $40 to thes security certifications allows us to run in the world's most secure locations. We are proud and honored to have some of the most security conscious customers in the world from all industries into. She's like insurance, finance, health care as well as public, federal and government agencies. With Dr Enterprise Container Cloud. We put security as our top concern, but importantly, we do it with speed. You can't move fast with security in the way so they solve this. We've added what we're calling invisible security security enabled by default and configured for you as part of the platform. Dr Price Container Cloud is multi tenant with granular are back throughout. In conjunction with Doc Enterprise, Docker Trusted Registry and Dr Content Trust. We have a complete end to end secured software supply chain Onley run the images that have gone through the appropriate channels that you have authorized to run on the most secure container engine in the >>industry. >>Lastly, I want to quickly touch on scale. Today. Cluster sprawl is a very real thing. There are test clusters, staging clusters and, of course, production clusters. There's also different availability zones, different business units and so on. There's clusters everywhere. These clusters are also running all over the place. We have customers running Doc Enterprise on premise there, embracing public cloud and not just one cloud that might also have some bare metal. So cloud sprawl is also a very real thing. All these clusters on all these clouds is a maintenance and observe ability. Nightmare. This is a huge friction point to scaling Dr Price. Container Cloud solves these issues, lets you scale quicker and more easily. Little recap. What's new. We've added multi cluster management. Deploy and attach all your clusters wherever they are. Multi cloud, including public private and bare metal. Deploy your clusters to any infra self service cluster creation. No more I T. Tickets to get resources. Incredible speed. Automated Full stack Lifecycle management, including Dr Enterprise Container, cloud itself as a service from the in for up centralized observe ability with a single pane of glass for your clusters, their health, your APs and most importantly to our existing doc enterprise customers. You can, of course, add your existing D clusters to Dr Enterprise Container Cloud and start leveraging the many benefits it offers immediately. So that's it. Thank you so much for attending today's keynote. This was very much just a high level introduction to our exciting release. There is so much more to learn about and try out. I hope you are as excited as I am to get started today with Doc Enterprise. Continue, Cloud, please attend the tutorial tracks up Next is Miska, with the world's most popular Kubernetes E Lens. Thanks again, and I hope you enjoy the rest of our conference.

>>Hello. I miss Caribbean, the principal Off Lens Open Source project and senior director off Engineering at Mirandes. I'm excited to be here today at launch back 2020 Virtual conference. I will be your guide, helping you to navigate the rough waters off opportunities and containers and show you the way how to take full advantage off this great new technology with help off lens. The Coburn Edie's idea. It's happening all around us. Containers and Coburn ET is everywhere. Every day, hundreds of thousands off people create new clusters. Develop containerized application on they deploy those applications on top of Cuban Edie's. It has become the golden standard for container orchestration. How did we get here? The industry has been very creative and innovative in ways how to burn it is has been marketed with the help off develops movement, empowering individual development teams leveraging 12 factor model on infrastructure. As a code principles, we have created the need for a system that is able to obstruct everything. That's one a single system to rule them all. Cooper needs has become this system. It has become the operating system for cloud. But hey, people say Coburn Ages is difficult and complex. Absolutely many people on organizations are struggling to adopt kubernetes at scale terrorist complexity on complexity on top of complexity. On top off this, you might need to unlearn some of the things you have used to do in the past. Having had chance to speak with hundreds off, Cooper needs users on operators, from beginners to ninja level hackers. I feel Coburn Edie's is not too difficult or complex. People will get this perception on Lee when they are using primitive or were limited tools for job, or if they have failed to address the needs off all different stakeholders. By using proper quality tools and products, we can truly harness the power of communities on radically improved the speed of business To get there. In my mind, we have deserved at least two important stakeholders. First, mhm. We have hopes and idea means who want to use system for centralized kubernetes cluster creation operations and management in a listen take care a lot about underlying infrastructure, security and conformance. The industry has been serving teas people very well. He has an amazing products for this segment. Dr Enterprise Container Cloud. It's a great example off such a product. Secondly, we have developers who are, in fact the consumers off. The clusters provided by the ops and I T at means they are the people who actually access the clusters on daily basis. Take deploy, run, managed, debug, inspect on observed the workloads running on top of communities. The availability and quality off tools and products for this segment has been lacking. See, very luckily, that's not the case anymore. And that's the focus off my talk today to take away. I want you to have from this simple unless we have quality tools and products for both off these important stakeholders, we might not get all the benefits we were looking for. Docker Enterprise Container Cloud. We'll get you on top and when combined with the product, I'm about to talk. Next. We'll take you where you wanna be. I'm so excited about this lens. The Cooper needs I D. I. D stands for integrated development environment. We could call it in the credit operations environment as well, but let's stick with I D for a little bit longer. No, If you would be doing non virtual conference, I would be as asking how many off you have heard or actually tried using less >>before. It's okay, Let's make make it interactive. We can still do it all right. I'm probably I would see something to 20% of people raising their hands. To be honest, I'm amazed how many people have started using lens already. It's been out on Lee for just six months or so. Lens combines all a sense of tools and technologies >>required for streamlining cloud native applicants and development on Day two operations. It's all you need to take control off Coburn. Edie's clusters on workloads running on top, for example, you might have find hard time trying to understand what is really going on in your clusters with lens. You will have complete situational awareness off all your clusters on work clothes, and you will understand what's going on on quickly. Take actions if needed. Lenses designed for developers who need to work with Cooper needs on a daily basis. If you have somebody who is just getting started, lens will lower the barrier of entry because it will let you explore your clusters on workloads very easy. Take action to try out different things on diesel eyes, everything in a way that makes sense on provides full context. If you are very experienced ninja level heavy user, you will get things done fast. In essence, by using lens, you will become more productive on the quality off life is improved a lot lenses. A stand alone desktop application for Mac OS Windows and Linux operating systems. It's free and fully open. Source under Emmett license. If you want to get started, simply download the lens application from Lens website and start adding your clusters. Now you might wonder. How does lend play together with Mirandes >>offering sheep code faster at Mirandes, we want to convert open source innovation in the customer value. We want to be best in the world. At this. We want to increase developer velocity to continuously deliver code faster for public and private clouds. And in order to do that, we want to put capable person in the center. We want to invest in products and technologies that will improve the developer productivity that speed sheep gold faster. To have speed, we got to get right amount off simplicity. Choice on security simplicity does not mean less features. It means amazing usability on developer experience for using complex on feature rich systems Under the hood. Security means invisible security, something that is built into the system from >>beginning on its part of its DNA, something that is automatically applied to the underlying infrastructure and software running on top without need for developers to worry about too much choice. It's include chance. You should be able to choose the parts you want to use, for example, choice of the infrastructure, cloud providers or even host operating system running on your machines. Everything in here comes to life with talker in the price container cloud. Combined with lens, it's the end to end solution for harnessing the power of kubernetes and radically improving the speed of business. >>All right, I hope you got the idea how lens will play together with Mirandes offering on a highly law. Now I'd like to talk more about lens features in detail. Let's kick off with multi cluster management. Unlike multi cluster management systems designed for hopes and ideas, New people peace is the Monte Cluster management from the developers point of view, take a nap. Any number >>of cabernet, these clusters to provide quick and easy way to switch cluster context on access workloads Running on top thes clusters may be the ones provide provided by their hopes and ideas mean people, but they might be clusters running locally, used in some other projects or use for hobby purposes. As an example, the clusters are added simply simply by importing the cube conflict file and selecting the cluster context. Once added, it's fast and easy to switch between clusters. Since the requirement for acting a cluster is just a cube. Conflict file lens works with any any certified Cooper needs distributions where user might have obtained to keep conflict. Five. For example, Documented price Container Cloud. You see T e. K s G. K. A. K s rancher opens it. Minnick YouTube many, many other flavors off uber Nitties They all work straight out off the box. The creating above lens is that you will get one unified I e across all your clusters. >>No matter what's the flavor on. There is absolutely nothing that you need to install in. Cluster is in itself is great because most off the developers we're talking about in here do not have sufficient right to install anything like this in their clusters. Since we're now talking about access control, let's discuss how the role based access control is taken in account with lens. It's all about uber needs built in role based access control. As you know, clusters may be configured to use any supported identity providers, since lens will authenticate uses the Cooper needs with Cuba conflict file Cooper needs are back is automatically enforced. This is also reflected on the user interface user. Will Onley see those resources they are allowed to access? Lens do not need admin level privileges, service accounts or any other solution that would by bus. The Cooper needs are back. Next. We have a smart terminal less has a built in smart terminal. It comes with bundled common line tools such as cube cattle on help. It's different from your native terminal because the smart terminal will always have cube cattle command available on bond. It will automatically >>switch the version off cube cattle to match the currently selected Cooper Needs Cluster a P I. If FBI compatible version is not found, it will be downloaded automatically in the background. In addition to making sure you are always using the right version off cube kuttel the Smart Terminal will automatically assigned the Cube conflict context to match your currently selected co Bernie. This cluster as a summary. When you use lens with building Smart Terminal, you are always using the right version off cube cattle and context. I feel there is still something more I want to share with you. Visualizations lenses Very diesel on There is a lot of detail in the user experience. One of the great features in Lens is that building in the creation with Prometheus to visualize everything. As you might know, people working on the ups and i d at me inside of things have learned to write complex Primedia Square ease. Most likely, they have created beautiful death sport to look at data. Looking at the cluster's from the bird's eye perspective. If you are a developer, you are interested in your own stuff. Bird side perspective might be nice, but it doesn't help you to debug and trouble. Suit your own application. You don't necessarily have access to or want to learn Prometheus to write your own queries on out of context that sports. That is why lens will provide automatically civilization for all supportive resource types including the aggregated Use it, >>David Little person. Or, to be honest, ops on Idea Means to will get all the data they need, always in the right context. The basic metrics include CPU memory on disk with total capacity actual use. It requests on limits. The unrest metrics include bytes sent success, failure on request and response to race. Both statistics also include network bytes sent and received. Persistent pulling. Unclaimed metrics include disk usage and capacity. Wow, that was a lot on. To be honest, we are just barely scratching the surface off the available features. Let's move on and talk about lens from the community on open source project perspective. We'll start with statistic, not because I like statistics in particular, but because this project has some mind blowing stats to share. Let's remind ourselves that lens was made open source just a half a year ago. Since then, over 600,000 downloads over 50,000 users over >>8000 star gazers on get top. The users come from all around the world. It's one off the fastest training open source projects on git hub and definitely in Cuba needs ecosystem. It's the number one e or u I or whatever you wanna call it for Cuban, it is on. If you are not using it yet, you're probably missing out some something great. What's coming on next? We are working hard every day to make lens better. Our focus as a leader in this open source project is to remain vendor Notre Look Ways for collaboration with other vendors in the cloud Native technology ecosystem on focus on making features that directing most value for our users. Against this background, the near future roadmap includes exciting features like extensive a P I. While the building features off, lens might feel great. It's just the beginning. Lens extensive a p I that is going to be a new feature released as part off Lens 4.0, we'll let you at custom visualizations on functionality to support your preferred development. Work flaws. The Extensions AP I will provide options for extensive creators to but directly into the lens You I we are already working with the number off cloud Native technology ecosystem vendors to get their technology is deeply integrated on therefore more accessible true lens, for example, on extension for a container >>image scanning technology vendor, I might add a warning icon next to a port or a deployment where vulnerable image is detected in a decent. This extension might provide more details about this vulnerability when the port or deployment is clicked. This is just a simple example, but I hope you get the idea on Really, this is just beginning. We want to >>bring entire Coburn Edie's ecosystem together in a listen to extensions. A p I. We will work on features to enhance Cooper needs Developer were close, both locally on remote, enable teamwork and naturally improve the usability on fixed box reported by our users. There are so many great things coming. It's impossible to list everything in here. If you are interested, please take a look at the epics listed on our guitar free ball. Once again, if you're not using lens already, you're probably missing out on something great. Download and get started today. For the most amazing entrant experience, check out the Docker Enterprise Container Cloud as well. I wish you all a great time with Coburn. Edie's I'm looking forward to meet you all in person someday. Take care. Bye bye

>> 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.

>>this session will be reviewing the power benefits of implementing a secure software supply chain and how we can gain a cloud like experience with flexibility, speed and security off modern software delivery. Hi, I'm Matt Bentley, and I run our technical pre sales team here. Um Iran. Tous I spent the last six years working with customers on their container ization journey. One thing almost every one of my customers is focused on how they can leverage the speed and agility benefits of contain arising 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 could provide flexibility all layers of the stack from the infrastructure on up to the application layer. When building a secure supply chain for container focus platforms, I generally see two different mindsets in terms of where the 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 the organization's goals around how modern applications are built and delivered. Yeah. First, let's take a look at the developer or application team approach. This approach follows Mawr of the Dev ops 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 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 were 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 and other organizations. There's a strong separation between responsibilities for developers and I T operations. This is often do the complex nature of controlled processes related to the compliance and regulatory needs. Developers are responsible for their application development. This can either include doctorate the development layer or b'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 I T organization. This is fairly prescriptive, in the manner of which application teams would consume it. When examining the two approaches, there are pros and cons to each process. Controls and appliance are often seen as inhibitors to speak. 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 the true infrastructure is a code. Experience requires Dev ops 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 Doc Enterprise Container Cloud provides the foundation for the cloud like experience on any infrastructure without all of the out of the box security and controls that are professional services Team and your operations team spend their time designing and implementing. This removes much of the additional work and worry Run, 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 I T operations. We're also bringing the most natural kubernetes experience today with winds to allow for multi cluster visibility that is both developer and operator friendly. Let's provides immediate feedback for the health of your applications. Observe ability for your clusters. Fast context, switching between environments and allowing you to choose the best in tool for the task at hand. Whether is three graphical 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 Dave off speed with all the security 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 were able to tie these processes back to real cost savings, riel efficiency and faster adoption. This all adds up to delivering business value to end users in the overall perceived value. Now let's look at see how we're able to actually build a secure supply chain. Help deliver these sorts of initiatives in our example. Secure Supply chain. We're utilizing doctor desktop to help with consistency of developer experience. Get hub for our source Control Jenkins for a C A C D. Tooling the doctor trusted registry for our secure container registry in the universal control playing to provide us with our secure container run time with kubernetes and swarm. Providing a consistent experience no matter where are 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 micro service on boarding teams could be simplified with integrations into enterprise authentication services. Calls to get help repositories. Jenkins Access and Jobs, Universal Control Plan and Dr Trusted registry teams and organizations. Cooper down his name space with access control, creating doctor trusted registry named spaces with access control, image scanning and promotion policies. So now let's take a look and see what it looks like from the C I c D process, including Jenkins. So let's start with Dr Desktop from the doctor desktop standpoint, what should be utilizing visual studio code and Dr Desktop to provide a consistent developer experience. So no matter if we have one developer or 100 we're gonna be able to walk through the consistent process through docker container utilization at the development layer. Once we've made our changes to our code will be able to check those into our source code repository in this case, abusing Get up. Then, when Jenkins picks up, it will check out that code from our source code repository, build our doctor containers, test the application that will build the image, and then it will take the image and push it toward doctor trusted registry. From there, we can scan the image and then make sure it doesn't have any vulnerabilities. Then we consign them. So once we signed our images, we've deployed our application to Dev. We can actually test their application deployed in our real environment. Jenkins will then test the deployed application, and if all tests show that is good, will promote the r R Dr and Mr 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 is deployed today. Here, we can see that we have a change that we want to make on our application. So marketing Team says we need to change containerized injure next to something more Miranda's branded. So let's take a look at visual studio coat, which will be using for I D to change our application. So here's our application. We have our code loaded, and we're gonna be able to use Dr Desktop on our local environment with our doctor desktop plug in for visual studio code to be able to build our application inside of doctor without needing to run any command line. Specific tools here is our code will be able to interact with docker, make our changes, see it >>live and be able to quickly see if our changes actually made the impact that we're expecting our application. Let's find our updated tiles for application and let's go and change that to our Miranda sized into next. Instead of containerized in genetics, so will change in the title and on the front page of the application, so that we save. That changed our application. We can actually take a look at our code here in V s 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 V s 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 the image tag that we just created and do run this winter, actively run the container for us and then what's our containers running? We could 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, weaken, 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 Mantis branding. We will commit that change and then we'll push it to our source code repository again. In this case we're using get Hub to be able to use our source code repository. So here in V s code will have that pushed here to our source code repository. And then we'll move on to our next environment, which is Jenkins. Jenkins is gonna be picking up those changes for our application, and it checked it out from our source code repository. So get Hub Notifies Jenkins. That there is a change checks out. The code builds our doctor image using the doctor file. So we're getting a consistent experience between the local development environment on our desktop and then and Jenkins or actually building our application, doing our tests, pushing in toward doctor trusted registry, scanning it and signing our image. And our doctor trusted registry, then 2.4 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 looks good and development. If we jump back here to Jenkins, will see that Jenkins go >>ahead and runs our integration tests for a development environment. Everything worked as expected, so it promoted that image for production repository and our doctor trusted registry. Where then we're going to also sign that image. So we're signing that. Yes, we have signed off that has made it through our integration tests, and it's deployed to production. So here in Jenkins, we could 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 doctor trusted registry where we can see our game Space for application are simple in genetics repository. From here we will be able to see information about our application image that we've pushed into the registry, such as Thean Midge signature when it was pushed by who and then we'll also be able to see the scan 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. Dr 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 and secure supply chain. So let's take a look at that and 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 of our image, we need to actually find the source of that and updated. One of the ways that we can help secure that is a part of the supply chain is to actually take a look at where we get our base layers of our images. Dr. Help really >>provides a great source of content to start from, but opening up docker help 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, However, 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 doctor. How we could 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 Dr trusted registry using our rearing feature. Once the images have been mirrored into a staging area of our DACA trusted registry, we can then scan them to ensure that the images meet our security requirements and then, based off the scan result, promote the image toe a public repository where we 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 a secure and controlled within our environment. So from here we confined our updated doctor image in our doctor trust registry, where we can see that the vulnerabilities have been resolved from a developers point of view, that's about a smooth process gets. Now let's take a look at how we could provide that secure content for developers and our own Dr Trusted registry. So in this case, we're taking a look at our Alpine image that we've mirrored into our doctor 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 nearing and we can quickly turn it on by making active. Then we can see that our image mirroring will pull our content from Dr Hub and then make it available in our doctor 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 are actually 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. We could see that we have our content that has been made available, so we've pulled in all sorts of content from Dr Hub. In this case, we have even pulled in the multi architectural images, which we can scan due to the binary level nature of our scanning solution. Now let's take a look at Len's. 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 to point to a Cooper Days cluster. Lindsay integrates natively out of the box with universal control playing clam bundles so you're automatically generated. Tell certificates from UCP. Just work inside our organization. We want to give our developers the ability to see their applications and a very easy to view manner. So in this case, let's actually filter down to the application that we just deployed to our development environment. Here we can see the pot for application and we click on that. We get instant, detailed feedback about the components and information that this pot is utilizing. We can also see here in Linz that it gives us the ability to quickly switch context 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 of applications, especially those that may be more complex to make it much simpler to be able to consume inversion our applications. In this case, let's take a look at the application that we just built and deployed. This case are simple in genetics. Application has been bundled up as a helm chart and has 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 home charts. So before we install it, we can actually look at those individual components. So in this case, we could see that's created ingress rule. And then it's well, tell kubernetes how to create the specific components of our application. We just have to pick a name space to to employ it, too. 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 Dr Hub in our universal Control plane. We've turned on Dr Content Trust Policy Enforcement. So this is actually gonna fail to deploy because we're trying to deploy application from Dr Hub. The image hasn't been properly signed in our environment. So the doctor can to trust policy enforcement prevents us from deploying our doctor image from Dr 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 our image came from, and that meets our quality standards. So if we comment out the doctor Hub repository and comment in our doctor trusted registry repository and click install, it will then install the helm chart with our doctor image being pulled from our GTR, which then 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 in genetics application, and in this case we'll get details around the actual deploy and help chart. The nice thing is that Linds provides us this capability here with home. To be able to see all the components that make up our application from this view is giving us that single pane of glass into that specific application so that we know all the components that is created inside of kubernetes. There are specific details that can help us access the applications, such as that ingress world that we just talked about gives us the details of that. But it also gives us the resource is such as the service, the deployment in 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 dev ups and operations controlled processes through the use of a secure supply chain, allowing our developers to spend more time developing and our operators mawr time designing systems that meet our security and compliance concerns

>> Narrator: From theCUBE Studios in Palo Alto in Boston, connecting with thought leaders around the globe, these are Cloud Native Insights. >> Hi, I'm Stu Miniman the host of cloud native insights. And when we started this weekly program, we look at Cloud Native and you know, what does that mean? And of course, one of the most important topics in IT coming into 2020 was security. And once the global pandemic hit, security went from the top issue to oh my gosh, it's even more important. I've said a few times on the program while most people are working from home, it did not mean that the bad actors went home, we've actually seen an increase in the need for security. So really happy to be able to dig in and talk about what is Cloud Native security, and what should that mean to users? And to help me dig into this important topic, happy to welcome back to the program one of our CUBE alumni Dan Hubbard, he is the CEO of Lacework. Dan thanks so much for joining us. >> Thanks Stu. Happy to be here. >> Alright, so we don't want to argue too much on the Cloud Native term, I agree with you and your team. It's a term that like cloud before, it doesn't necessarily have a lot of meaning. But when we talk about modernization, we talked about customers leveraging the opportunity in innovation and cloud security of course is super important. You know most of us probably remember back, you go back a few years and it's like, "Oh well I adopt cloud. "It's secure, right? "I mean, it should just be built into my platform. "And I should have to think about that." Well, I don't think there's anybody out there at least hopefully there's not anybody out there that thinks that anything that I go to will just be inherently fully secure. So give us a little bit if you would, you know where you see us here in 2020 security's a complex landscape. What are you seeing? >> Yeah, so you know a lot of people as you said, used to talk about what's called the shared responsibility model, which was the cloud provider is responsible for a bunch of things. Like the physical access to the data center, the network, the hypervisor and you know that the core file system and operating system and then you're responsible for everything else that you could configure. But there's something that's not talked about as much. And that's kind of the shared irresponsibility model that's happening within companies where developers are saying they're not responsible for security saying that they're moving too fast. And so what we are seeing is that you know, as people migrate to the cloud or of course are born in the cloud, this notion of DevSecOps, or you know SecDevOps whatever you want to call it, is really about the architecture and the organization. It's not just about technology, and it's not just about people. And it's more about layer seven and eight, than it is about layer one to three. And so there's a bunch of trends that we're seeing in successful companies and customers and prospects will be seeing the market around how do they get to that level of cooperation between the security and the developers in the operation teams? >> Yeah Dan, first of all fully agree with what you're saying. I know when I go to like serverless.com they've got everybody chanting that security is everyone's responsibility. You know I think back to DevOps as a trend, when I read the Phoenix project it was, oh hey, the security is not something that you do bolt on, we're looking at after it's something that you need to shift into everyone thinking about it. Security is just going to be baked in along the process all the way. So the DevOps fail us when it comes to security, why do we need DevSecOps? You know why are you know as you say seven and eight the you know, political and organizational challenges still so much of an issue you know, decades into this discussion? >> Yeah. You know I think there's a few moving parts here and kind of post COVID is even more interesting is that companies have incredibly strategic initiatives to build applications that are core to their business. And in post COVID it's almost existential to their business. If you think of you know, markets like retail and hospitality and restaurants you know, they have to figure out how to digitize and how to deliver their business without potentially physical you know, access to two locations. So as that speed has happened, some of the safety has been left behind. And it's easy to say you have to kind of you know, one of our mantras is to run with speed and safety. But it's kind of hard to run with scissors you know, and be safe at the same time. So some of it is just speed. And the other is that unfortunately, the security people in many ways and the security products and a lot of the security solutions that are out there, the incumbents if you will, are trying to deliver their current solution in a cloud way. So they're doing sometimes it's called Cloud built or you know what I call Cloud washing and they're delivering a system that's not applicable to the modern infrastructure in the modern way that developers are building. So then you have a clash between the teams of like, "Hey I want to do this." And then I'd be like, "No you can't do that get out of our way. "This is strategic to the business." So a lot of it has just been you know, kind of combination of all those factors. >> Alright so Dan, we'll go back to Cloud Native security, you talked about sometimes people are Cloud washing, or they're just taking what they had putting it in the cloud. Sometimes it's just, oh hey we've got a SaaS model on this. Other times I hear cloud native security, and it just means hey I've got some hooks into Containers or Kubernetes. What does modern security look like? Help us understand a little bit. You mentioned some of the you know, legacy vendors what they're doing. I see lots of new security startups, some in you know specifically in that, you know, Kubernetes space. There's already been some acquisitions there. So you know, what do you see out there? You know what's good, what's bad in the trends that you're seeing? >> Yeah so I think the one thing that we really believe is that this is such a large problem that you have to be 100% focused on it. You know if you're doing this, you know, securing your infrastructure and securing your modern applications, and doing other parts of the business whether it's you know securing the endpoints of the laptops of the company and the firewall and authentication and all kinds of other things you have competing interests. So focus is pretty key. And it's obviously a very large addressable problem. What the market is telling us is a few things. The first one is that automation is critical. They may not have as many people to solve the problem. And the problem set is moving at such a scale that it's very, very hard to keep up. So a lot of people ask me you know, what do I worry about? You know, how do I stay awake at night? Or how do I get to sleep? And really the things I'm worried most about in the way where I spend most of my time on the product side is about how fast are builders building? Not necessarily about the bad guys. Now the bad guys are coming and they're doing all kinds of innovative and interesting things. But usually it starts off with the good guys and how they're deploying and how they're building. And you know, the cloud providers literally are releasing API's and new acronyms almost weekly it seems. So like new technology is being created such a scale. So automation the ability to adapt to that is one key message that we hear from the customers. The other is that it has to solve or go across multiple categories. So although things like Kubernetes and Containers are very popular today. The cloud security tackle and challenges is much more complex than that. You've got infrastructure as code, you've got server lists, you've got kind of fragmented workloads, whether some are Containers, some are VMs, maybe some are armies and then some are Kubernetes. So you've got a very fragmented world out there, and all of it needs to be secured. And then the last one is probably the most consistent theme we're hearing is that as DevOps becomes involved, because they know the application and the stack much better than security, it has to fit into your modern workflow of DevOps. So that means you know, deep integrations into Jira and Slack and PagerDuty and New Relic and Datadog are a lot more important in integrating to your you know, Palo Alto firewall and your Cisco IDs system and your endpoint you know antivirus. So those are the real key trends that we're seeing from the customers. >> Yeah Dan, you bring up a really important point, leveraging automation. I'm wondering what you're hearing from customers, because there definitely is a little bit of concern, especially if you take something like security and say, okay well, automation. Is that something that I'm just going to let the system do it? Or is it giving me to getting me to a certain point that then a human makes the final decision and enacts what's going to happen there? Where are we along that journey? >> Yeah, so I think of automation in two lenses. The first lens is efficacy, which is you know do I have to write rules? And do I have to tune train and alter the system over time? Or can it do that on my behalf? Or is there a combination of both? So the notion of people writing rules and building rules is very, very hard in this world because things are moving so quickly. You know, what is the KMS you know threat surface? The threat attacks are just changing. And typically what happens when you write rules is they're either too narrow and you messed up or they're too broad you just get way too much noise. So there's automating the efficacy of the system. That's one that's really critical. The other one that is becoming more important is in the past it was called enforcement. And this is how do I automate a response to your efficacy. And in this scenario it were very, very early days. Some vendors have come out and said you know, we can do full remediation and blocking. And typically what happens is the DevOps team kind of gives the Heisman to the security team it says, "No, you're not doing that." You know this is my production servers, and my infrastructure that's you know running our business, you can't block anything without us knowing about it. So I think we're really early. I believe that you know we're going to move to a world that's more about orchestration and automation, where there's a set of parameters where you can orchestrate certain things or maybe an ops assist mode. You know for example, we have some customers that will send our alerts to Slack, then they have a Slack bot and they say, "Okay, is it okay that Bob just opened "an S3 bucket in this region, yes or no?" No, and then it runs a serverless function and closes it. So there's kind of a what we call driver assist mode versus you know full you know, no one behind the steering wheel today. But I think it's going to mature over time. >> Yeah, Dan one of the other big challenges customer has is that their environments are even more fragmented than they would in the past. So often they're leveraging multiple cloud providers, multiple SaaS providers then they have their hosting providers. And security is something that I need to have holistically across these environments but not have to worry about okay, do I have the skill set and understanding between those environments? Hopefully you know that's something you see out there and want to understand, you know how the security industry in general and maybe Lacework specifically is helping customers, get their arms a little bit more around that multi cloud challenge if you will? >> Yeah. So I totally agree things are you know, I think we have this Silicon Valley, West Coast bias that the world is all you know, great. And it says to utopia Kubernetes, modern infrastructure, everything runs up and down, and it's all you know super easy. The reality is much different. Even in the most sophisticated sets of infrastructure in the most sophisticated customers are very fragmented and diverse. The other challenge that security runs into is security in the past a lot of traditional security mindsets are all about point in time. And they're really all about inventory. So you know, I know used to be able to ask, you know a security person, how many servers do you have? Where are they? What are they doing this? They say, "Oh, you know we have 10 racks with 42 servers in each rack. "And here's our IP addresses." Nowadays, the answer is kind of like, "I don't know what time is it you know, "how busy is a service?" It's very ephemeral. So you have to have a system which can adapt with the ephemeral nature of everything. So you know in the past it was really difficult to spin up, say 10,000 servers in a Asia data center for four hours to do research you know. Security probably know if that's happening, you know they would know through a number of different ways could make big change control window would be really hard they have to ship the units, they bake them in you know, et cetera. Nowadays that's like three lines of code. So the security people have to know and get visibility into the changes and have an engine which can determine those changes and what the risk profile of those in near real time. >> Yeah it's the what we've seen is the monitoring companies out there now talking all about observability. Its real time, it's streamings. You know it reminds me of you know my physics. So you know Heisenberg's uncertainty principle when you try to measure something, you already can't because it's already changed. So what does that mean-- >> Dan: Yeah. >> You know what does security look like in my you know, real time serverless ever changing world? You know, how is it that we are going to be able to stay secure? >> Yeah, so I think there are some really positive trends. The first one is that this is kind of a reboot. So this is kind of a restart. You know there are things we've learned in the past that we can bring forward but it's also an opportunity to kind of clean the slate and think about how we can rebuild the infrastructure. The first kind of key one is that over time security in the traditional data center started understanding less and less about the application over time, what they did was they built this big fortress around it, some called it defense in depth you know, the Security Onion whatever you want to call it you know, the M&M'S. But they were really lacking in the understanding of the application. So now security really has to understand the application because that's the core of what's important. And that allows them to be smarter about what are the changes in their environment, and if those are good, bad or indifferent. The other thing that I think is interesting is that compliance was kind of a dirty word that no one really wanted to talk about. It was kind of this boring thing or auditors would show up once every six months go through a very complex checklist and say you're okay. Now compliance is actually very sophisticated. And the ability to look at your configuration in near real time and understand if you are compliant or following best practices is real. And we do that for our customers all the time. You know we can tell them how they're doing against the compliance standard within a you know, a minute timeframe. And we can tell that they're drifting in and out of that. And the last one and the one that I think most are excited about is really the journey towards least privileges and minimizing the scope of your attack surface within your developers and their access in your infrastructure. Now it's... We're pretty far from there, it's an easy thing to say it's a pretty hard thing to do. But getting towards and driving towards that journey of least privilege I think is where most people are looking to go. >> Alright Dan, I want to go back to something that we talked about early in the conversation, that relationship with the cloud providers themselves, so you know talking AWS, Azure, Google Cloud and the like. How should customers be thinking about how they manage security, dealing with them dealing with companies like Lacework and the ecosystem you mentioned in companies like Datadog and the New Relic? You know how do they sort through and manage how they can maintain those relationships? >> So there's kind of the layer eight relationships, of course which are starting you know in particular with the cloud providers, it's a lot more about bottoms up relationships and very technical understanding of product and features, than it is about being on the golf course, and you know eating steak dinners. And that's very different you know, security and buying IT infrastructure was very relationship driven in the past. Now you really especially with SaaS and subscriptions, you're really proving out your technology every day. You know I say kind of trust is built on consistent positive results over time. So you really have to have trust within your solution and within that service and that trust is built on obviously a lot of that go to market business side. But more often than not it's now being built on the ability for that solution to get better over time because it's a subscription. You know how do you deliver more features and increase value to the customer as you do more things over time? So that's really, really important. The other one is like, how do I integrate the technology together? And I believe it's more important for us to integrate our stack with the cloud provider with the adjacent spaces like APM and metrics and monitoring and with open source, because open source really is a core component to this. So how do we have the API's and integrations and the hooks and the visibility into all of those is really, really important for our customers in the market? >> Well Dan as I said at the beginning, security is such an important topic to everyone out there. You know we've seen from practitioners we talked to for the last few years not only is it a top issue it's a board level discussion for pretty much every company out there. So I want to give you the final word as to in today's you know modern era, what advice do you give to users out there to make sure that they are staying as secure as possible? >> Yeah so you know first and foremost, people often say, "Hey you know, when we build our business, "you know, it'd be a good problem to start have to worry "about customers and you know, "all kinds of people using the service. "And you know, we'll worry about security then." And it's easy lip service to say start it as early as possible. The reality is sometimes it's hard to do that. You've got all kinds of competing interests, you're trying to build a business and an application and everything else depending obviously, the maturity of your organization. I would say that this is a great time to kind of crawl, walk, run. And you don't have to think about it. If you're building in the cloud you don't have to think of the end game you know right away, you can kind of stair step into that. So you know my suggestion to people that are moving into the cloud is really think about compliance and configuration best practices first and visibility, and then start thinking of the more complex things like triage alerts and how does that fit into my workflow? How do I look at breaches down the line? Now for the more mature orgs that are taking, you know an application or a new application or Stack and just dropping it in, those are the ones that should really think about how do I fit security into this new world order? And how do I make it as part of the design process? And it's not about how do I take my existing security stack and move it over? That's like taking, you know a centralized application moving to the cloud and calling it cloud. You know if you're going to build in the cloud, you have to secure it the same way that you're building it in a modern way. So really think about you know, modern, you know new generation vendors and solutions and a combination of kind of your provider, maybe some open source and then a service, of course like Lacework. >> Alright well Dan Hubbard, thank you so much for helping us dig into this important topic Cloud Native security, pleasure talking with you. >> Thank you. Have a great day. >> And I'm Stu Miniman your hosts for Cloud Native Insights and looking forward to hearing more of your Cloud Native Insights in the future. (upbeat music)