(soft music) >> Welcome back everyone, is Supercloud 22 live in the Palo Alto office. Our stage performance we're streaming virtually it's our pilot event, our inaugural event, Supercloud 22. I'm John fury, with my coach Dave Vellante. Got a featured Keynote conversation with Kit Colbert. Who's the CTO of VMware, got to delay it all out. Break it down, Kit, great to see you. Thanks for joining us for Supercloud 22 our inaugural event. >> Yeah, I'm excited to be here. Thanks for having me. >> So we had great distinguished panels coming up through. We heard Victoria earlier to the Keynote. There's a shift happening. The shift has happened that's called cloud. You just published a white paper that kind of brings out these new challenges around the complexity of how companies want to run their business. >> Yep. >> It's not born in the cloud, it's cloud everywhere. Seems to be the theme. What's your take on Supercloud? what's the roadmap for multicloud? >> Yeah, well, the reason that we got interested in this was just talking to our customers and the reality is everybody is using multiple clouds today, multiple public clouds, they got things on-prem, they got stuff at the edge. And so their applications are essentially distributed everywhere. And the challenges they start running into there is that there's just a lot of heterogeneity there. There's like different APIs, different capabilities, inconsistencies, incompatibility, in terms of workload, placement, data, migration, security, as we just heard about, et cetera. And so I think everyone's struggling with trying to figure out how do I drive consistency across all that diversity and what sort of consistency do I want? And one of the things that became really interesting in our conversations with customers is that there is no one size fits all that different folks are in different places. And the types of consistency that they want to prioritize will be different based on their individual business requirements. And so this started forming a picture for us saying, okay, what we need are a set of capabilities of multi-cloud cross cloud services that deliver that consistency across all the different environments where applications may be running. And that is what formed the early thinking and sort of the paper that we wrote on it, as well as some of the work and that I think eventually leads to this vision of Supercloud, right? 'Cause I think you guys have the right idea, which is, hey, how does all this stuff come together? And what does that bigger picture look like? And so I think between the sort of the native services that are there individually for each cloud that offer great value by the way, and people definitely should be taking advantage of in addition to another set of services, which are multi-cloud that go across clouds and provide that consistency, looking at that together. That's my picture where super cloud is. >> So the paper's called, the era of multi-cloud services arrive, VMware executive outlook for IT, leaders and decision makers, I'm sure you can get on your website. >> Yep. >> And in there, you talked about, well, first of all, I think you would agree that multicloud has fundamentally been a symptom of multi-vendor or M&A, I mean, you talked about that in the paper, right? >> Yeah. >> It was never really a strategy. It was just like, hey, we woke up in the 2020s and here we are with multiple clouds, right? >> Yeah, it was one of those situations where most folks that we talked to didn't plan to be multi-cloud now that's changed a little bit in the past year or two. >> Sure. >> But certainly in the earlier days of cloud, people would go all in saying, hey, I'm going to go all in on one, one of the major hyperscalers and go for it there. And that's great and offers a lot of advantages, right? There is internal consistency there. There's usually pretty good integration between their services so on and so forth. The problem though that you start facing is that to your point, acquisitions, you acquire companies using a different cloud. Okay, now I got two different clouds or sometimes you have the phenomenon of shadow IT, still happening where some random line of business is going to go off and use a different cloud for whatever reason. The other thing that we've seen is that over time that you may have standardized on one, but then over time technology changes, another cloud makes major advancements in the state of the art, or let's say in machine learning and you say, hey, I want to go to this other cloud for that. So what we start to see is that people now are choosing public clouds based on best of breed service capabilities, and that they're going to make those decisions that fairly fine grained manner, right? Sometimes down to the team, the line of business, et cetera. And so this is where customers and companies find themselves. Now it's like, oh boy, now have all these clouds. And what's happened is that they kind of dealt with it in an ad hoc manner. They would spin up individual operations teams, security teams, et cetera, that specialized in each of the clouds. They had knowledge about how to do that. But now people found that, okay, I'm duplicating all this. There's not really consistency in my approach here. Is there a better way? And I think this is, again, the advent of a lot of the thinking of multi-cloud services and Supercloud. >> And I think one of the things too, in listening to you talk is that the old model used to be, solve complexity with more complexity. Okay, and customers don't want that from what we're observing. And what you're saying is they've seen the benefits of DevOps, DevSecOps. So they know the value. >> Yep. >> 'Cause they've been on, say one native cloud. Now they say, okay, I'm on premise and we heard from Victoria said, there's a lot of private cloud going on, but essentially makes that another cloud, out by default as well. So hybrid is multicloud. >> Hybrid is a subset, yeah. Hybrid is like, we kind of had this evolution of thinking, right? Where you kind of had all the sort of different locations. And then I think hybrid was attempt to say, okay, let's try to connect one location or a set of locations on premises with a public cloud and have some level of consistency there. But really what we look at here with multicloud or Supercloud is that that's really a generalization of that. And we're not talking about one or two locations on prem in one cloud. We're talking about everything now. And moreover, I think hybrid cloud tended to focus a lot on sort of core infrastructure and management. This looks across the board, we're talking about security, we're talking about application development, talking about end user experience. Things like Zero Trust. We're talking about infrastructure, data. So it goes much, much broader, I think than when we talked about hybrid cloud a few years ago. >> So in your paper you've essentially, Kit, laid out an early framework. >> Yep. >> Let's call it for what we call Supercloud, what you call cross cloud services. So what do you see as the technical enablers that are, the salient aspects of again multi-cloud or Supercloud? >> Yep. Well, so for me it comes down to, so, okay, taking a step back. So we have this problem, right? Where you have a lot of diversity across different clouds and customers are looking for some levels of consistency. But as I said, rarely do I see two customers that want exactly the same types of consistency. And so what we're trying to do is step back. And first of all, establish a taxonomy and by that I mean, one of the different types of consistency that you might want. And so there's things around infrastructure consistency, security consistency, software supply chain security is probably the top of mind one that I hear from customers. Application and application services of things like databases, messaging streaming services, AIML services, et cetera, and user capabilities and then of course, data as well. And so in the paper we say, okay, here's these kind of five areas of consistency. And that's the first piece, the second one then turns more to an architectural question of what exactly is a multi-cloud service. What does that mean for a cloud service to be multi-cloud and what are the properties there? So essentially we said, okay, we see three different types of those. There's one where that service could run on a single cloud, but could support multiple clouds. So think about for instance, a service that does cost analysis. Now it may have maybe executing on AWS let's say, but it could do cost analysis for Azure or Google or AWS or anybody, right? So that's the first type. The second type is a bit more advanced where now you're saying, I can actually instantiate that same service into multiple clouds. And we see that oftentimes with things like databases that have a lot of performance latency, et cetera, requirements, and that you can't be accessing that database remotely, that doesn't, from a different cloud, that's going to be too slow. You have it on the same cloud that you're in. And so again, you see various vendors out there, implementing that, where that database can be instantiated wherever you'd like. And then the third one would be going even further. And this is where we really get into some of the much more difficult use cases where customers want a workload to be on prem. And sometimes, especially for those that are very regulatory compliant, they may need even in an air gap or disconnected environment. So there, can you take that same service, but now run it without your operators, being able to manage it 24/7. So those are the three categories. So are a single cloud supporting, single cloud instance supporting multiple clouds, multi-cloud instance, multi-cloud instance disconnected. >> So you're abstracting you as the the R&D arm you're abstracting that complexity. How do you handle this problem where you've got one cloud maybe has a better service than the other clouds? Do you have to devolve to the lowest common denominator or? How do you mask that? >> Well, so that's a really good question and we've debated it and there's been a lot of thought on it. Our current point of view is that we really want to leave it, up to the company themselves to make that decision. Again, cause we see different use cases. So for instance, I talk to customers in the defense sector and they are like, hey, if a foreign adversary is attacking one of these public cloud that we're in, we got to be able to evacuate our applications from there, sometimes in minutes, right? In order to maintain our operational capabilities. And so there, there does need to be at least common denominator approach just because of that requirement. I see other folks, you look at the financial banking industries they're also regulated. I think for them, it's oftentimes 90 days to get out of the cloud, so they can do a little bit of re-architecture. You got times rolled the sleeves and change some things. So maybe it's not quite as strict. Whereas other companies say, you know what? I want to take advantage of these best of breed services native to the clouds. So we don't try to prescribe a certain approach there, but we say, you got to align it with what your business requirements are. >> How about the APIs layer? So one of the things we've said is that we felt like a super pass was a requirement of the Supercloud because it's a purpose built pass that helps you with that objective, whatever that is. And you say in the paper for developers each cloud provider has unique infrastructure interfaces and APIs that add work and slow the pace of their releases for operators. Each additional cloud increases the complexity of their architecture, fragmenting security, performance optimization and cost management. So are you building a super pass? What's your philosophy? Victoria said, we want to have our cake, we want to eat at two and we want to lose weight. So how do you do that? >> Yeah, so I think it's, so first things first, what the paper is trying to present in the end is really sort of an architectural point of view on how to approach this, right? And then, yeah, we at VMware, we've got a lot of solutions, towards some of those things, but we also realize we can't do everything ourselves, right? The space is too large. So it's very much a partner strategy there. Now that being said, on things like on the past side, we are doing a lot for instance around Tanzu, which is our modern apps portfolio products. And the focus there really is to, yes, provide some of that consistency across different clouds, enabling customers to take advantage of either cross cloud paths type services or cloud native or native cloud services, I should say. And so we really give customers that choice. And I think that's for us where it's at, because again, we don't see it as a one size fits for all. >> So there's your cake at edit to too. So you're saying the developer experience can be identical across clouds. >> Yep. >> Unless the developers don't want it to be. >> Yeah, and maybe the team makes that decision. Look there's a lot of reasons why you may want to make that or may not. The reality is that these native cloud services do add a lot of value and oftentimes are very easy to consume, to get started with, to get going. And so trade off you got to think about, and I don't think there's a right answer. >> So Kit, I got to ask on you. You said you can't do it alone. >> Yeah. >> VMware, I know for a fact, you guys have been working on this for many, many years. >> Yep. >> (indistinct) remember, I interviewed him in 2016 when he did the deal with AWS with Andy Jassy that really moved the needle. Things got really great from there with VMware. So would you be open to a consortium to oversee cause you guys have a lot of investment in this as a company, but I also don't hear you trying to do the lock in thing. So yeah, would you guys be open to a consortium to kind of try to figure out what these buildings blocks look like? Or is it a bag of Legos what people want? >> Absolutely, and you know what we offer in the paper is really just a starting point. It's pretty simple, we're trying to define a few basic of the taxonomy and some outlines sketches if you will, of what that architectural picture might look like. But it's very much that like just a starting point, and this is not something we can do alone. This is something that we really need the entire industry to rally around. Cause again, I think what's important here are standards. >> Yeah. >> That there's got to be, this sort of decomposition of functionality, breakdown in the different, sort of logical layers of functionality. What do those APIs or interfaces look like? How do we ensure interoperability? Because we do want people to be able to get the best of breed, to be able to bring together different vendor solutions to enable that. >> And I was watching, it was had a Silicon a day just last week, talking about their advances in Silicon. What's you guys position on that because you're seeing the (indistinct) as players, almost getting more niche and more better at the hardware matters more, Silicon speed, latency GPUs, So that seems to me be an enabler opportunity for the ecosystem to innovate at the past and SAS relationship. Where do you guys see? Where are you guys strong and where do you need work to do on? If you had to say there was some white space at VMware like say, hey, we own this area. We we're solid here. Here's some white spaces that VMware could use some help with. >> Yeah, well I think the infrastructure space, you just mentioned is clearly one that we've been focused on for a long time. We're expanding into the modern app space, expanding into security. We've been strong and end user for a while. So a lot of the different multi-cloud capabilities we've actually been to your point developing for a while. And I think that's exactly, again, what went into this like what we started noticing was all of our different product teams were reacting to the same thing and we weren't necessarily talking about it together yet. >> Like what? >> Well, this whole challenge of multiple clouds of dealing with that heterogeneity of wanting choice and flexibility into where to place a workload or where to place a virtual desktop or whatever it might be. And so each of the teams was responding individually to that customer feedback. And so I think what we recognized was like, hey, let's up level this, and what's the bigger picture. And what's the sort of common architecture across all of it, right? So I think that's what the really interesting aspect here was is that this is very much driven by what we're hearing directly from customers. >> You kind of implied just recently that the paper was pretty straightforward, pretty basic, early days, but it's well thought out. And one of the things you talked about was the type of multi-cloud services. >> Yep. >> You had data plan and user services, security infrastructure, which is your wheelhouse and application services. >> Yep. >> And you sort of went to detail defining those where is management and all that. So these are the ones you're going after. What about management? What are your thoughts on that? >> Yeah, so it's a really good question we debated this for a long time. Does management actually get a separate sort of layer that we could add a six one perhaps, or is it sort of baked in to the different ones? And we kind of went with the ladder where it sort of baked in there's infrastructure management, there's modern app management, there's management and users. It's kind of management for each security obviously. So we see a lot of different management plans, control plans across each of those different layers. Now does there need to be a separate one that has its own layer? Arguably yes, I mean, I think there are good arguments for that, and this is exactly why we put this out there though, is to like get people to read it, people to give give us feedback. And going back to the consortium idea, let's come together as a group of practitioners across the industry to really figure out an industry viewpoint on this. >> So what are the trade offs there? So what would be the benefit of having that separate layer? I presume it's simpler to do it the way you've done it, but what would be the benefit of having a separate. >> Yeah, I think it was probably more about simplicity to start with, like you could imagine like 20 different layers. and maybe that's where it's going to go, but also I think it's how do you define the layer? And for us it was more around sort of some of these functional aspects as an infrastructure versus application level versus end user and management is more of a commonality across those. But again, I could see our arguments be made. >> Logical place to start. >> Yeah. >> The other thing you said in here multi-cloud application services can route request for a particular service such as a database and deploy the service on the correct individual cloud, using the most appropriate technology for the use case, et cetera, et cetera. >> Yep. >> That to me, sounds like a metadata problem. And so can you talk about how you you've approach that? You mentioned AWS RDS, great examples as your sequel on Oracle Database, et cetera, et cetera and multiple endpoint. How do you approach that? >> Yeah, well, I think there's a bunch of different approaches there. And so again, so the idea is that, and I know there's been reference to sort of like the operating system for Supercloud. What does that look like, right? But I think it totally, we don't actually use that term, but I do like the concept of an operating system. 'Cause a lot of things you just talk about there, these are things operating systems. Do you got to have a scheduler? And so you look across many different clouds and you got to figure out, okay, where do I actually want in this case, let's say a database instance to go and be provisioned. And then really it's up to, I think the vendor or in this case, the multi-cloud service creator to define how they want to want to do that. They could leverage the native cloud services or they could build their own technology. Which a lot of the vendors are doing. And so the point though, is that really you get this night from a end user standpoint, it goes back to your complexity, simplicity question, you get the simplicity of a single API that the implementation you don't really need to deal with. 'Cause you're like, I'm getting a service and I need the database and has certain properties and I want it here versus there versus wherever. But it's up to that multi-cloud service to figure out a lot of those implementation specifics. >> So are you the Supercloud OS? >> I think it is VMware's goal to become the Supercloud OS for sure. But like any good operating system, as we said, like it's all about applications, right? So you have a platform point of view, but you got to partner widely. >> And you got to get the hardware relationship. >> Yes. >> The Silicon chips. >> Yep. >> Right. >> Yeah, and actually that was a good point. I want to go back to that one. 'Cause you mentioned that earlier, the innovation that we're seeing, things like arm processors and like graviton and a lot of these things happening. And so I think that's another really interesting area where you're seeing tremendous innovation there in the public cloud. One of the challenges though for public cloud is actually at scale and that it takes longer to release newer hardware at that scale. So in some cases, if you want bleeding edge stuff, you can't go with public cloud 'cause it's just not there yet, right? So that's again, another interesting thing where you... >> Well, some will say that they launch 5,000 new services, every year at AWS. >> No, but I'm talking, >> They have some bleeding edge stuff. >> Well, no, no, no, sorry, sorry, let me clarify, let me clarify. I'm not talking about the software, I'm talking about the hardware side. >> Okay, got it, okay. >> Like the Silicon? >> Yeah, like the latest and greatest GPU, FBGA. >> Why can't they? >> 'Cause cause they do like tens of thousands of them, hundreds of thousands of them. >> Oh just because it's just so many. >> It's a scale. Yeah, that's the point, right? >> Right. >> And it's fundamental to the model in terms of how big they are. And so that's why we do see some customers who need, who have very specialized hardware requirements, need to do it in the private cloud, right on prem or possibly a colo. >> Or edge. >> Or edge. >> Edge is a great example of... >> But we often see, again, people like the latest bleeding edge GPUs, whatever they are, even something a bit more experimental that they're going to go on on prem for that. >> Yeah. >> And so look, do not want to disparage the public cloud, please don't take that away. It's just an artifact when it gets to heart, like software they can scale and they do (indistinct). >> Well it's context of the OS conversation, OS has to right to hardware and enable applications. >> Where I was getting caught up in that is Kit, is they're all developing their own Silicon and they're developing it, most of it's arm based and they're developing at a much, much faster cycle. They can go from design to tape out much faster than Intel historically has. And you're seeing it. >> Intel just posted along. >> Yeah, I think if you look at the overall system, you're absolutely right. >> Yeah, but it's the deployment because of the scale 'cause at one availability zone and another and another region and that's. >> Well, yeah, but so counter point to what I just said would be, hey, like they have very well controlled environments, very well controled system. So they don't need to support a million different configuration settings or whatever they've got theirs that they use, right? So from a system standpoint and so forth. Yeah, I agree that there's a lot they can do there. I was speaking specifically, to different types of hardware accelerators being a bit of a (indistinct). >> If it's not in the 5,000 services that they offer, you can't get it, whereas on-prem you can say, I want that, here it is. >> I'm not saying that on-prem is necessarily fundamentally better in any way. I'm just saying for this particular area >> It's use case driven. >> It is use, and that's the whole point of all this, right? Like and I know a lot of people in their heads associate VMware with on-prem, but we are not dogmatic at all. And you know, as you guys know, but many people may not like we partner with all the public cloud hyperscalers. And so our point of view is very much, much more nuance saying, look, we're happy to run workloads wherever you want to. In fact, that's what we hear from customers. They want to run them everywhere, but it's about finding the right tool for the right job. And that's what really what this multi-cloud approach. >> Yeah, and I think the structural change of the virtualization hypervisor this new shift to V2 Supercloud, this something happening fundamentally that's use case driven, it's not about dogma, whatever. I mean, cloud's great. But native clouds have the pros and cons. >> And I would say that Supercloud, prerequisite for Supercloud has got to be running in a public cloud. But I'd say it also has to be inclusive of on-prem data. >> Yes, absolutely. >> And you're not going to just move all that data into prem, maybe in the fullness of time, but I don't personally believe that, but you look at what Goldman Sachs has done with AWS they've got their on-prem data and they're connecting to the AWS cloud. >> Yep. >> What Walmart's doing with Azure and that's going to happen in a lot of different industries. >> Yeah. >> Well I think security will drive that too. We had that conversation because no one wants to increase the surface area. Number one, they want complexity to be reduced and they want economic benefits. That's the super cloud kind of (indistinct). >> It's a security but it's also differentiatable advantage that you actually have on prem that you don't necessarily. >> Right, well, we're going to debate this now, Kit, thank you for coming on and giving that Keynote, we're going to have a panel to debate and discuss the blockers that enablers to Supercloud. And there are some enablers and potentially blockers. >> Yep, absolutely. >> So we'll get, into that, okay, up next, the panel to discuss, blockers and enablers are Supercloud after this quick break. (soft music)

>> Narrator: theCUBE's live coverage is made possible by funding from Dell Technologies. Creating technologies that drive human progress. (upbeat music) >> Hey, welcome back to the Fira in Barcelona. My name is Dave Vellante. I'm here with David Nicholson, day four of MWC '23. Show's winding down a little bit, but it's still pretty packed here. Lot of innovation, planes, trains, automobiles, and we're talking 5G all week, private networks, connected breweries. It's super exciting. Really happy to have Warren Jackson here as the Edge Gateway Product Technologist at Dell Technologies, and Scott Waller, the CTO of the 5G Open Innovation Lab. Folks, welcome to theCUBE. >> Good to be here. >> Really interesting stories that we're going to talk about. Let's start, Scott, with you, what is the Open Innovation Lab? >> So it was hatched three years ago. Ideated about a bunch of guys from Microsoft who ran startup ventures program, started the developers program over at Microsoft, if you're familiar with MSDN. And they came three years ago and said, how does CSPs working with someone like T-Mobile who's in our backyard, I'm from Seattle. How do they monetize the edge? You need a developer ecosystem of applications and use cases. That's always been the thing. The carriers are building the networks, but where's the ecosystem of startups? So we built a startup ecosystem that is sponsored by partners, Dell being one sponsor, Intel, Microsoft, VMware, Aspirant, you name it. The enterprise folks who are also in the connectivity business. And with that, we're not like a Y Combinator or a Techstars where it's investment first and it's all about funding. It's all about getting introductions from a startup who might have a VR or AI type of application or observability for 5G slicing, and bring that in front of the Microsoft's of the world, or the Intel's and the Dell's of the world that they might not have the capabilities to do it because they're still a small little startup with an MVP. So we really incubate. We're the connectors and build a network. We've had 101 startups over the last three years. They've raised over a billion dollars. And it's really valuable to our partners like T-Mobile and Dell, et cetera, where we're bringing in folks like Expedo and GenXComm and Firecell. Start up private companies that are around here they were cohorts from our program in the past. >> That's awesome because I've often, I mean, I've seen Dell get into this business and I'm like, wow, they've done a really good job of finding these guys. I wonder what the pipeline is. >> We're trying to create the pipeline for the entire industry, whether it's 5G on the edge for the CSPs, or it's for private enterprise networks. >> Warren, what's this cool little thing you got here? >> Yeah, so this is very unique in the Dell portfolio. So when people think of Dell, they think of servers laptops, et cetera. But what this does is it's designed to be deployed at the edge in harsh environments and it allows customers to do analytics, data collection at the edge. And what's unique about it is it's got an extended temperature range. There's no fan in this and there's lots of ports on it for data ingestion. So this is a smaller box Edge Gateway 3200. This is the product that we're using in the brewery. And then we have a bigger brother of this, the Edge Gateway 5200. So the value of it, you can scale depending on what your edge compute requirements are at the edge. >> So tell us about the brewery story. And you covered it, I know you were in the Dell booth, but it's basically an analog brewery. They're taking measurements and temperatures and then writing it down and then entering it in and somebody from your company saw it and said, "We can help you with this problem." Explain the story. >> Yeah, so Scott and I did a walkthrough of the brewery back in November timeframe. >> It's in Framingham, Mass. >> Framingham, Mass, correct. And basically, we talked to him, and we said, what keeps you guys up at night? What's a problem that we can solve? Very simple, a kind of a lower budget, didn't have a lot money to spend on it, but what problem can we solve that will realize great benefit for you? So we looked at their fermentation process, which was completely analog. Somebody was walking around with a clipboard looking at analog gauges. And what we did is we digitized that process. So what this did for them rather than being completely reactive, and by the time they realized there was something going wrong with the fermentation process, it's too late. A batch of scrap. This allowed them to be proactive. So anytime, anywhere on the tablet or a phone, they can see if that fermentation process is going out of range and do something about it before the batch gets scrapped. >> Okay. Amazing. And Scott, you got a picture of this workflow here? >> Yeah, actually this is the final product. >> Explain that. >> As Warren mentioned, the data is actually residing in the industrial side of the network So we wanted to keep the IT/OT separation, which is critical on the factory floor. And so all the data is brought in from the sensors via digital connection once it's converted and into the edge gateway. Then there's a snapshot of it using Telit deviceWISE, their dashboarding application, that is decoding all the digital readings, putting them in a nice dashboard. And then when we gave them, we realized another problem was they're using cheap little Chromebooks that they spill beer on once a week and throw them out. That's why they bought the cheap ones 'cause they go through them so fast. So we got a Dell Latitude Rugged notebook. This is a brand new tablet, but they have the dashboarding software. So no matter if they're out there on the floor, but because the data resides there on the factory they have access to be able to change the parameters. This one's in the maturation cycle. This one's in the crashing cycle where they're bringing the temperature back down, stopping the fermentation process, getting it ready to go to the canning side of the house. >> And they're doing all that from this dashboard. >> They're doing all from the dashboard. They also have a giant screen that we put up there that in the floor instead of walking a hundred yards back behind a whole bunch of machinery equipment from a safety perspective, now they just look up on the screen and go, "Oh, that's red. That's out of range." They're actually doing a bunch of cleaning and a bunch of other things right now, too. So this is real time from Boston. >> Dave: Oh okay. >> Scott: This is actually real time from Boston. >> I'm no hop master, but I'm looking at these things flashing at me and I'm thinking something's wrong with my beer. >> We literally just lit this up last week. So we're still tweaking a few things, but they're also learning around. This is a new capability they never had. Oh, we have the ability to alert and monitor at different processes with different batches, different brews, different yeast types. Then now they're also training and learning. And we're going to turn that into eventually a product that other breweries might be able to use. >> So back to the kind of nuts and bolts of the system. The device that you have here has essentially wifi antennas on the back. >> Warren: Correct. >> Pull that up again if you would, please. >> Now I've seen this, just so people are clear, there are also paddle 5G antennas that go on the other side. >> Correct. >> That's sort of the connection from the 5G network that then gets transmogrified, technical term guys, into wifi so the devices that are physically connected to the brew vats, don't know what they're called. >> Fermentation tanks. >> Fermentation tanks, thank you. Those are wifi. That's a wifi signal that's going into this. Is that correct? >> Scott: No. >> No, it's not. >> It's a hard wire. >> Okay, okay. >> But, you're right. This particular gateway. >> It could be wifi if it's hard wire. >> It could be, yes. Could be any technology really. >> This particular gateway is not outfitted with 5G, but something that was very important in this application was to isolate the IT network, which is on wifi and physically connected from the OT network, which is the 5G connection. So we're sending the data directly from the gateway up to the cloud. The two partners that we worked with on this project were ifm, big sensor manufacturer that actually did the wired sensors into an industrial network called IO-Link. So they're physically wired into the gateway and then in the gateway we have a solution from our partner Telit that has deviceWISE software that actually takes the data in, runs the analytics on it, the logic, and then visualizes that data locally on those panels and also up to their cloud, which is what we're looking at. So they can look at it locally, they're in the plant and then up in the cloud on a phone or a tablet, whatever, when they're at home. >> We're talking about a small business here. I don't know how many employees they have, but it's not thousands. And I love that you're talking about an IT network and an OT network. And so they wanted, it is very common when we talk about industrial internet of things use cases, but we're talking about a tiny business here. >> Warren: Correct. >> They wanted to separate those networks because of cost, because of contention. Explain why. >> Yeah, just because, I mean, they're running their ERP system, their payroll, all of their kind of the way they run their business on their IT network and you don't want to have the same traffic out on the factory floor on that network, so it was pretty important. And the other thing is we really, one of the things that we didn't want to do in this project is interrupt their production process at all. So we installed this entire system in two days. They didn't have to shut down, they didn't have to stop. We didn't have to interrupt their process at all. It was like we were invisible there and we spun the thing up and within two days, very simple, easy, but tremendous value for their business. >> Talk about new markets here. I mean, it's like any company that's analog that needs to go digital. It's like 99% of the companies on the planet. What are you guys seeing out there in terms of the types of examples beyond breweries? >> Yeah, I could talk to that. So I spent a lot of time over the last couple years running my own little IoT company and a lot of it being in agriculture. So like in Washington state, 70% of the world's hops is actually grown in Washington state. It's my hometown. But in the Ag producing regions, there's lack of connectivity. So there's interest in private networks because the carriers aren't necessarily deploying it. But because we have the vast amount of hops there's a lot of IPAs, a lot of hoppy IPAs that come out of Seattle. And with that, there's a ton of craft breweries that are about the same size, some are a little larger. Anheuser-Busch and InBev and Heineken they've got great IoT platforms. They've done it. They're mass scale, they have to digitize. But the smaller shops, they don't, when we talk about IT/OT separation, they're not aware of that. They think it's just, I get local broadband and I get wifi and one hotspot inside my facility and it works. So a little bit of it was the education. I have got years in IT/OT security in my background so that education and we come forward with a solution that actually does that for them. And now they're aware of it. So now when they're asking questions of other vendors that are trying to sell them some type of solution, they're inherently aware of what should be done so they're not vulnerable to ransomware attacks, et cetera. So it's known as the Purdue Model. >> Well, what should they do? >> We came in and keep it completely separated and educated them because in the end too we'll build a design guide and a starter kit out of this that other brewers can use. Because I've toured dozens of breweries in Washington, the exact same scenario, analog gauges, analog process, very manual. And in the end, when you ask the brewer, what do they want out of this? It keeps them up at night because if the temperature goes out of range, because the chiller fails, >> They ruined. >> That's $30,000 lost in beer. That's a lot to a small business. However, it's also once they start digitizing the data and to Warren's point, it's read-only. We're not changing any of the process. We augmented on top of their existing systems. We didn't change their process. But now they have the ability to look at the data and see batch to batch consistency. Quality doesn't always mean best, it means consistency from batch to batch. Every beer from exhibit A from yesterday to two months from now of the same style of beer should be the same taste, flavor, boldness, et cetera. This is giving them the insights on it. >> It's like St. Louis Buds, when we were kids. We would buy the St. Louis Buds 'cause they tasted better than the Merrimack Buds. And then Budweiser made them all the same. >> Must be an East coast thing. >> It's an old guy thing, Dave. You weren't born yet. >> I was in high school. Yeah, I was in high school. >> We like the hops. >> We weren't 21. Do me a favor, clarify OT versus IT. It's something we talk about all the time, but not everyone's familiar with that separation. Define OT for me. >> It's really the factory floor. You got IT systems that are ERP systems, billing, you're getting your emails, stuff like that. Where the ransomware usually gets infected in. The OT side is the industrial control network. >> David: What's the 'O' stand for? >> Operation. >> David: Operation? >> Yeah, the operations side. >> 'Cause some people will think objects 'cause we think internet of things. >> The industrial operations, think of it that way. >> But in a sense those are things that are connected. >> And you think of that as they are the safety systems as well. So a machine, if someone doesn't push the stop button, you'd think if there's a lot of traffic on that network, it isn't guaranteed that that stop button actually stops that blade from coming down, someone's going to lose their arm. So it's very tied to safety, reliability, low latency. It is crafted in design that it never touches the internet inherently without having to go through a security gateway which is what we did. >> You mentioned the large companies like InBev, et cetera. You're saying they're already there. Are they not part of your target market? Or are there ways that you can help them? Is this really more of a small to mid-size company? >> For this particular solution, I think so, yeah. Because the cost to entry is low. I mean, you talk about InBev, they have millions of dollars of budgets to spend on OT. So they're completely automated from top to bottom. But these little craft brewers, which they're everywhere in the US. Vermont, Washington state, they're completely manual. A lot of these guys just started in their garage. And they just scaled up and they got a cult kind of following around their beers. One thing that we found here this week, when you talk around edge and 5G and beer, those things get people excited. In our booth we're serving beer, and all these kind of topics, it brings people together. >> And it lets the little guy compete more effectively with the big giants. >> Correct. >> And how do you do more with less as the little guy is kind of the big thing and to Warren's point, we have folks come up and say, "Great, this is for beer, but what about wine? What about the fermentation process of wine?" Same materials in the end. A vessel of some sort, maybe it's stainless steel. The clamps are the same, the sensors are the same. The parameters like temperature are key in any type of fermentation. We had someone talking about olive oil and using that. It's the same sanitary beverage style equipment. We grabbed sensors that were off the shelf and then we integrated them in and used the set of platforms that we could. How do we rapidly enable these guys at the lowest possible cost with stuff that's at the shelf. And there's four different companies in the solution. >> We were having a conversation with T-Mobile a little earlier and she mentioned the idea of this sounding scary. And this is a great example of showing that in fact, at a relatively small scale, this technology makes a lot of sense. So from that perspective, of course you can implement private 5G networks at an industrial scale with tens of millions of dollars of investment. But what about all of the other things below? And that seems to be a perfect example. >> Yeah, correct. And it's one of the things with the gateway and having flexibility the way Dell did a great job of putting really good modems in it. It had a wide spectrum range of what bands they support. So being able to say, at a larger facility, I mean, if Heineken wants to deploy something like this, oh, heck yeah, they probably could do it. And they might have a private 5G network, but let's say T-Mobile offers a private offering on their public via a slice. It's easy to connect that radio to it. You just change the sims. >> Is that how the CSPs fit here? How are they monetized? >> Yeah, correct. So one of our partners is T-Mobile and so we're working with them. We've got other telco partners that are coming on board in our lab. And so we'll do the same thing. We're going to take this back and put it in the lab and offer it up as others because the baseline building blocks or Lego blocks per se can be used in a bunch of different industries. It's really that starter point of giving folks the idea of what's possible. >> So small manufacturing, agriculture you mentioned, any other sort of use cases we should tune into? >> I think it's environmental monitoring, all of that stuff, I see it in IoT deployments all over the world. Just the simple starter kits 'cause a farmer doesn't want to get sold a solution, a platform, where he's got to hire a bunch of coders and partner with the big carriers. He just wants something that works. >> Another use case that we see a lot, a high cost in a lot of these places is the cost of energy. And a lot of companies don't know what they're spending on electricity. So a very simple energy monitoring system like that, it's a really good ROI. I'm going to spend five or $10,000 on a system like this, but I'm going to save $20,000 over a year 'cause I'm able to see, have visibility into that data. That's a lot of what this story's about, just giving visibility into the process. >> It's very cool, and like you said, it gets people excited. Is it a big market? How do you size it? Is it a big TAM? >> Yeah, so one thing that Dell brings to the table in this space is people are buying their laptops, their servers and whatnot from Dell and companies are comfortable in doing business with Dell because of our model direct to customer and whatnot. So our ability to bring a device like this to the OT space and have them have that same user experience they have with laptops and our client products in a ruggedized solution like this and bring a lot of partners to the table makes it easy for our customers to implement this across all kinds of industries. >> So we're talking to billions, tens of billions. Do we know how big this market is? What's the TAM? I mean, come on, you work for Dell. You have to do a TAM analysis. >> Yes, no, yeah. I mean, it really is in the billions. The market is huge for this one. I think we just tapped into it. We're kind of focused in on the brewery piece of it and the liquor piece of it, but the possibilities are endless. >> Yeah, that's tip of the spear. Guys, great story. >> It's scalable. I think the biggest thing, just my final feedback is working and partnering with Dell is we got something as small as this edge gateway that I can run a Packet Core on and run a 5G standalone node and then have one of the small little 5G radios out there. And I've got these deployed in a farm. Give the farmer an idea of what's possible, give him a unit on his tractor, and now he can do something that, we're providing connectivity he had never had before. But as we scale up, we've got the big brother to this. When we scale up from that, we got the telco size units that we can put. So it's very scalable. It's just a great suite of offerings. >> Yeah, outstanding. Guys, thanks for sharing the story. Great to have you on theCUBE. >> Good to be with you today. >> Stop by for beer later. >> You know it. All right, Dave Vellante for Dave Nicholson and the entire CUBE team, we're here live at the Fira in Barcelona MWC '23 day four. Keep it right there. (upbeat music)

(suspenseful music) >> Welcome back everyone, this is the SiliconANGLE news report, news flash, news update. I'm John Furrier, host of theCUBE, SiliconANGLE founder and editor. Got our team in Mobile World Congress, MWC. But here's some news flash: the GSMA debuted API toolkit as AWS and Microsoft roll out their offerings to make the cloud part of the telco world. The GSMA association, which runs this program and is the most important organization in telecommunications, unveiled the GSMA Open Gateway. This is a toolkit designed for creating applications that integrate with multiple carrier networks. The technology debuted at MWC23. This is the largest trade show opened in the telco area. This Open Gateway allows carriers to support APIs created with the technology that'll interoperate with each other. That means interoperability and cloud is coming to the telecommunication carriers. That's your cell phone, that's wireless. This allows developers to move applications from one carrier to another without needing to port their code. This is a huge game-changer. This is big news, and, of course, Microsoft and AWS are pounding stories out there as well. They got 21 carriers worldwide adopted and it's created using an open-source API toolkit called CAMARA. And Amazon and AWS are jumping on the cloud bandwagon with this and driving it hard into telco. And that's the big story, and, of course, more actions happening, theCUBE is onsite for four days in Barcelona for MWC23 and keep the news flowing. Check out SiliconANGLE.com, you'll see all the news there, and, of course, theCUBE.net for the livestream. I'm John Furrier, that's the news brief. (atmospheric music)

>>Welcome back to the Cube, as a continued coverage here from AWS Reinvent 22. It's day three of our coverage here at the Venetian in Las Vegas, and we're part of the AWS Global Startup Showcase. With me to talk about what Kong's to in that regard is Marco Palladino, who's the, the CTO and the co-founder of Con Marco. Good >>To see you. Well, thanks for having me >>Here. Yeah, I was gonna say, by the way, I, I, you've got a beautiful exhibit down on the show floor. How's the week been for you so far as an exhibitor here? >>It's been very busy. You know, to this year we made a big investment at the WS reinvent. You know, I think this is one of the best conferences in the industry. There is technology developers, but it's also business oriented. So you can learn about all the business outcomes that our, you know, customers or, you know, people are trying to make when, when adopting these new technologies. So it's very good so far. >>Good, good, good to hear. Alright, so in your world, the API world, you know, it used to be we had this, you know, giant elephant. Now we're cutting down the little pieces, right? That's right. We're all going micro now these days. That's right. Talk about that trend a little bit, what you're seeing, and we'll jump in a little deeper as to how you're addressing that. >>Well, I think the industry learned a long time ago that running large code bases is actually quite problematic when it comes to scaling the organization and capturing new opportunities. And so, you know, we're transitioning to microservices because we want to get more opportunities in our business. We want to be able to create new products, fasters, we want to be able to leverage existing services or data that we have built, like an assembly line of software, you know, picking up APIs that other developers are building, and then assemble them together to create new experiences or new products, enter new markets. And so microservices are fantastic for that, except microservices. They also introduce significant concerns on the networking layer, on the API layer. And so this is where Kong specializes by providing API infrastructure to our customers. >>Right. So more about the problems, more about the challenges there, because you're right, it, opportunities always create, you know, big upside and, and I, I don't wanna say downside, but they do introduce new complexities. >>That's right. And introducing new complexity. It's a little bit the biggest enemy of any large organization, right? We want to reduce complexity, we want to move faster, we want to be more agile, and, and we need an API vision to be able to do that. Our teams, you know, I'm speaking with customers here at Reinvent, they're telling me that in the next five years, the organization is going to be creating more APIs than all the APIs they've created up until now. Right? So how do you >>Support, that's a mind boggling number, right? >>It's mind boggling. Yeah, exactly. How do you support that type of growth? And things have been moving so fast. I feel like there is a big dilemma in, you know, with certain organizations where, you know, we have not taught a long term strategy for APIs, whereas we do have a long term strategy for our business, but APIs are running the business. We must have a long term strategy for our APIs, otherwise we're not gonna be able to execute. And that's a big dilemma right now. Yeah. >>So, so how do we get the horse back in front of the cart then? Because it's like you said, it's almost as if we've, we're, we're reprioritizing, you know, incorrectly or inaccurately, right? You're, you're getting a little bit ahead of ourselves. >>Well, so, you know, whenever we have a long-term strategy for pretty much anything in the organization, right? We know what we want to do. We know the outcome that we want to achieve. We work backwards to, you know, determine what are the steps that are gonna bring us there. And, and the responsibility for thinking long term in, in every organization, including for APIs at the end of the day, always falls on the leaders and the should on the shoulders of the leadership and, and to see executives of the organization, right? And so we're seeing, you know, look at aws by the way. Look at Amazon. This conference would not have been possible without a very strong API vision from Amazon. And the CEO himself, Jeff Bezos, everybody talks about wanting to become an API first organization. And Amazon did that with the famous Jeff Bezos mandate today, aws, it's a hundred billion revenue for Amazon. You see, Amazon was not the first organization with, with an e-commerce, but if it was the first one that married a very strong e-commerce business execution with a very strong API vision, and here we are. >>So yeah, here we are putting you squarely in, in, in a pretty good position, right? In terms of what you're offering to the marketplace who has this high demand, you see this trend starting to explode. The hockey sticks headed up a little bit, right? You know, how are you answering that call specifically at how, how are you looking at your client's needs and, and trying to address what they need and when they need it, and how they need it. Because everybody's in a kind of a different place right now. >>Right? That's exactly right. And so you have multiple teams at different stages of their journey, right? With technology, some of them are still working on legacy, some of them are moving to the cloud. Yep. Some of them are working in containers and in microservices and Kubernetes. And so how do you, how do we provide an API vision that can fulfill the needs of the entire organization in such a way that we reduce that type of fragmentation and we don't introduce too much complexity? Well, so at con, we do it by essentially splitting the API platform in three different components. Okay. One is API management. When, whenever we want to expose APIs internally or to an ecosystem of partners, right? Or to mobile, DRA is a service mesh. You know, as we're splitting these microservices into smaller parts, we have a lot of connectivity, all, you know, across all the services that the teams are building that we need to, to manage. >>You know, the network is unreliable. It's by default, not secure, not observable. There is nothing that that works in there. And so how do we make that network reliable without asking our teams to go and build these cross-cut concerns whenever they create a new service. And so we need a service match for that, right? And then finally, we could have the best AP infrastructure in the world, millions of APIs and millions of microservices. Everything is working great. And with no API consumption, all of that would be useless. The value of our APIs and the value of our infrastructure is being driven by the consumption that we're able to drive to all of these APIs. And so there is a whole area of API productivity and discovery and design and testing and mocking that enables the application teams to be successful with APIs, even when they do have a, the proper API infrastructure in place that's made of meshes and management products and so on and so forth. Right. >>Can you gimme some examples? I mean, at least with people that you've been working with in terms of addressing maybe unique needs. Cuz again, as you've addressed, journeys are in different stages now. Some people are on level one, some people are on level five. So maybe just a couple of examples Yeah. Of clients with whom you've been working. Yeah, >>So listen, I I was talking with many organizations here at AWS Reinvent that are of course trying to migrate to the cloud. That's a very common common transformation that pretty much everybody's doing in the world. And, and how do you transition to the cloud by de-risking the migration while at the same time being able to get all the benefits of, of running in the cloud? Well, we think that, you know, we can do that in two, two ways. One, by containerizing our workloads so that we can make them portable. But then we also need to lift and shift the API connectivity in such a way that we can determine how much traffic goes to the legacy and how much traffic goes to the new cloud infrastructure. And by doing that, we're able to deal with some of these transformations that can be quite complex. And then finally, API infrastructure must support every team in the organization. >>And so being able to run on a single cloud, multi-cloud, single cluster, multi cluster VMs containers, that's important and essential because we want the entire organization to be on board. Because whenever we do not do that, then the developers will make short term decisions that are not going to be fitting into the organizational outcomes that we want to achieve. And we look at any outcome that your organization wants to achieve the cloud transformation, improving customer retention, creating new products, being more agile. At the end of the day, there is an API that's powering that outcome. >>Right? Right. Well, and, and there's always a security component, right? That you have to be concerned about. So how are you raising that specter with your clients to make them aware? Because sometimes it, I wouldn't say it's an afterthought, but sometimes it's not the first thought. And, and obviously with APIs and with their integral place, you know, in, in the system now security's gotta be included in that, right? >>API security is perhaps the biggest, biggest request that we're hearing from customers. You know, 83% of the world's internet traffic at the end of the day runs on APIs, right? That's a lot of traffic. As a matter of fact, APIs are the first attack vector for any, you know, malicious store party. Whenever there is a breach, APIs must be secured. And we can secure APIs on different layers of our infrastructure. We can secure APIs at the L four mesh layer by implementing zero trust security, for example, encrypting all the traffic, assigning an identity to every service, removing the concept of trust from our systems because trust is exploitable, right? And so we need to remove the cut zero trust, remove the concept of trust, and then once we have that underlying networking that's being secure and encrypted, we want to secure access to our APIs. >>And so this is the typical authentication, authorization concerns. You know, we can use patterns like op, op or opa open policy agent to create a security layer that does not rely on the team's writing code every time they're creating a new service. But the infrastructure is enforcing the type of layer. So for example, last week I was in Sweden, as a matter of fact speaking with the largest bank in Sweden while our customers, and they were telling us that they are implementing GDPR validation in the service mesh on the OPPA layer across every service that anybody's building. Why? Well, because you can embed the GDPR settings of the consumer into a claim in a gel token, and then you can use OPPA to validate in a blanket way that Jo Token across every service in the mesh, developers don't have to do that. It just comes out of the box like that. And then finally, so networking, security, API security for access and, and management of those APIs. And then finally we have deep inspection of our API traffic. And here you will see more exotic solutions for API security, where we essentially take a subset of our API traffic and we try to inspect it to see if there is anybody doing anything that they shouldn't be doing and, and perhaps block them or, you know, raise, raise, raise the flag, so to speak. >>Well, the answer is probably yes, they are. Somebody's trying to, somebody's trying to, yeah, you're trying to block 'em out. Before I let you go, you've had some announcements leading up here to the show that's just to hit a few of those highlights, if you would. >>Well, you know, Kong is an organization that you know, is very proud of the technology that we create. Of course, we started with a, with the API gateway Con Gateway, which was our first product, the most adopted gateway in the world. But then we've expanded our platform with service mesh. We just announced D B P F support in the service mesh. For example, we made our con gateway, which was already one of the fastest gateway, if not the fastest gateway out there, 30% faster with Con Gateway 3.0. We have shipped an official con operator for Kubernetes, both community and enterprise. And then finally we're doubling down on insomnia, insomnia's, our API productivity application that essentially connects the developers with the APIs that are creating and allows them to create a discovery mechanism for testing, mocking the bagging, those APIs, all of this, we of course ship it OnPrem, but then also on the cloud. And you know, in a cloud conference right now, of course, cloud, right? Right. Is a very important part of our corporate strategy. And our customers are asking us that. Why? Because they don't wanna manage the software, they want the API platform, they don't, don't wanna manage it. >>Well, no, nobody does. And there are a few stragglers, >>A few, a few. And for them there is the on-prem >>Platform. Fine, let 'em go. Right? Exactly. But if you wanna make it a little quick and dirty, hand it off, right? Oh, >>That's exactly right. Yes. >>Let Con do the heavy lifting for you. Hey Marco, thanks for the time. Yeah, thank you so much. We appreciate, and again, congratulations on what appears to be a pretty good show for you guys. Yeah, thank you. Well done. All right, we continue our discussions here at aws. Reinvent 22. You're watching the Cube, the leader in high tech coverage. >>Okay.

>>Good morning and welcome back to Detroit, Michigan. My name is Savannah Peterson and I'm here on set of the cube, my co-host John Farer. How you doing this morning, John? >>Doing great. Feeling fresh. Day two of three days of coverage, feeling >>Fresh. That is that for being in the heat of the conference. I love that attitude. It's gonna >>Be a great day today. We'll see you at the end of the day. Yeah, >>Well, we'll hold him to it. All right, everyone hold 'em accountable. Very excited to start the day off with an internet, a legend as well as a cube og. We are joined this morning by Matt Klein. Matt, welcome to the show. >>Thanks for having me. Good to see you. Yep. >>It's so, what's the vibe? Day two, Everyone's buzzing. What's got you excited at the show? You've been here before, but it's been three years you >>Mentioned. I, I was saying it's been three years since I've been to a conference, so it's been interesting for me to see what is, what is the same and what is different pre and post covid. But just really great to see everyone here again and nice to not be sitting in my home by myself. >>You know, Savannah said you're an OG and we were referring before we came on camera that you were your first came on the Cub in 2017, second Cuban event. But you were, I think, on the first wave of what I call the contributor momentum, where CNCF really got the traction. Yeah. You were at Lift, Envoy was contributed and that was really hyped up and I remember that vividly. It was day zero they called it back then. Yeah. And you got so much traction. People are totally into it. Yeah. Now we've got a lot of that going on now. Right. A lot of, lot of day Zero events. They call 'em co, co-located events. You got web assembly, a lot of other hype out there. What do you see out there that you like? How would you look at some of these other Sure. Communities that are developing, What's the landscape look like as you look out? Because Envoy set the table, what is now a standard >>Practice. Yeah. What's been so interesting for me just to come here to the conference is, you know, we open source Envoy in 2016. We donated in 2017. And as you mentioned at that time, Envoy was, you know, everyone wanted to talk about Envoy. And you know, much to my amazement, Envoy is now pervasive. I mean, it's used everywhere around the world. It's like, never in my wildest dreams would I have imagined that it would be so widely used. And it's almost gotten to the point where it's become boring. You know, It's just assumed that Envoy is, is everywhere. And now we're hearing a lot about Eeb p f and Web assembly and GI ops and you know, AI and a bunch of other things. So it's, it's actually great. It's made me very happy that it's become so pervasive, but it's also fun. Yeah. We mention to, to look around all other stuff >>Like congratulate. It's just a huge accomplishment really. I think it's gonna be historic, historical moment for the industry too. But I like how it progressed. I mean, I don't mind hype cycles as long as it's some vetting. Sure. Of course. You know, use cases that are clearly defined, but you gotta get that momentum in the community, but then you start gotta get down to, to business. Yep. So, so to speak and get it deployed, get traction. Yep. What should projects look like? And, and give us the update on Envoy. Cause you guys have a, a great use case of how you got traction. Right. Take us through some of the early days of what made Envoy successful in your opinion. Great question. >>Yeah. You know, I, I think Envoy is fairly unique around this conference in the sense that Envoy was developed by Lyft, which is an end user company. And many of the projects in this ecosystem, you know, no judgment, for better or worse, they are vendor backed. And I think that's a different delivery mechanism when it's coming from an end user where you're solving a, a particular business case. So Envoy was really developed for Lyft in a, you know, very early scaling days and just, you know, trying to help Lyft solve its business problems. So I think when Envoy was developed, we were, you know, scaling, we were falling over and actually many other companies were having similar problems. So I think Envoy became very widely deployed because many companies were having similar issues. So Envoy just became pervasive among lift peer companies. And then we saw a lot of vendor uptake in the service mesh space in the API gateway space among large internet providers. So, I I I, I think it's just, it's an interesting case because I think when you're solving real problems on the ground, in some ways it's easier to actually get adoption than if you're trying to develop it from a commercial backing. >>And that's the class, I mean, almost, It's almost like open source product market fit. It is in its own way. Cause you have a problem. Absolutely. Other people have the same problem finding >>Too. I mean, it's, it's designed thinking from >>A different, When, when I talk to people about open source, I like to tell people that I do not think it's any different than starting a company. I actually think it's all the same problems finding pro product, market fit, hiring, like finding contributors and maintainers, like doing PR and marketing. Yeah. Getting team together, traction, getting, getting funding. I mean, you have to have money to do all these things. Yeah. So I think a lot of people think of open source as I, I don't know, you know, this fantastic collaborative effort and, and it is that, but there's a lot more to it. Yeah. And it is much more akin to starting a >>Company. Let's, let's just look at that for a second. Cause I think that's a good point. And I was having a conversation in the hallway two nights ago on this exact point. If the power dynamics of a startup in the open source, as you point out, is just different, it's community based. So there are things you just gotta be mindful of. It's not top down. >>Exactly. It's not like, >>Right. You know, go take that hill. It's really consensus based, but it is a startup. All those elements are in place. Absolutely. You need leadership, you gotta have debates, alignment, commit, You gotta commit to a vision. Yep. You gotta make adjustments. Build the trajectory. So based on that, I mean, do you see more end user traction? Cause I was, we were talking also about Intuit, they donated some of their tow code R goes out there. Yep. R go see the CDR goes a service. Where's the end user contributions to these days? Do you feel like it's good, still healthy? >>I, I mean, I, I'm, I'm biased. I would like to see more. I think backstage outta Spotify is absolutely fantastic. That's an area just in terms of developer portals and developer efficiency that I think has been very underserved. So seeing Backstage come outta Spotify where they've used it for years, and I think we've already seen they had a huge date, you know, day one event. And I, I think we're gonna see a lot more out of that >>Coming from, I'm an end user, pretend I'm an end user, so pretend I have some code. I want to, Oh man, I'm scared. I don't am I'm gonna lose my competitive edge. What's the, how do you talk to the enterprise out there that might be thinking about putting their project out there for whether it's the benefit of the community, developing talent, developing the product? >>Sure. Yeah. I would say that I, I would ask everyone to think through all of the pros and cons of doing that because it's not for free. I mean, doing open source is costly. It takes developer time, you know, it takes management time, it takes budgeting dollars. But the benefits if successful can be huge, right? I mean, it can be just in terms of, you know, getting people into your company, getting users, getting more features, all of that. So I would always encourage everyone to take a very pragmatic and realistic view of, of what is required to make that happen. >>What was that decision like at Lyft >>When you I I'm gonna be honest, it was very naive. I I think we've, of that we think we need to know. No, just didn't know. Yeah. I think a lot of us, myself included, had very minimal open source experience. And had we known, or had I known what would've happened, I, I still would've done it. But I, I'm gonna be honest, the last seven years have aged me what I feel like is like 70 or a hundred. It's been a >>But you say you look out in the landscape, you gotta take pride, look at what's happened. Oh, it's, I mean, it's like you said, it >>Matured fantastic. I would not trade it for anything, but it has, it has been a journey. What >>Was the biggest surprise? What was the most eye opening thing about the journey for you? >>I, I think actually just the recognition of all of the non-technical things that go into making these things a success. I think at a conference like this, people think a lot about technology. It is a technology conference, but open source is business. It really is. I mean, it, it takes money to keep it going. It takes people to keep >>It going. You gotta sell people on the concepts. >>It takes leadership to keep it going. It takes internal, it takes marketing. Yeah. So for me, what was most eyeopening is over the last five to seven years, I feel like I actually have not developed very many, if any technical skills. But my general leadership skills, you know, that would be applicable again, to running a business have applied so well to, to >>Growing off, Hey, you put it out there, you hear driving the ship. It's good to do that. They need that. It really needs it. And the results speak for itself and congratulations. Yeah. Thank you. What's the update on the project? Give us an update because you're seeing, seeing a lot of infrastructure people having the same problem. Sure. But it's also, the environments are a little bit different. Some people have different architectures. Absolutely different, more cloud, less cloud edges exploding. Yeah. Where does Envoy fit into the landscape they've seen and what's the updates? You've got some new things going on. Give the updates on what's going on with the project Sure. And then how it sits in the ecosystem vis-a-vis what people may use it for. >>Yeah. So I'm, from a core project perspective, honestly, things have matured. Things have stabilized a bit. So a lot of what we focus on now are less Big bang features, but more table stakes. We spend a lot of time on security. We spend a lot of time on software supply chain. A topic that you're probably hearing a lot about at this conference. We have a lot of software supply chain issues. We have shipped Quicken HTB three over the last year. That's generally available. That's a new internet protocol still work happening on web assembly where ha doing a lot of work on our build and release pipeline. Again, you would think that's boring. Yeah. But a lot of people want, you know, packages for their fedora or their ADU or their Docker images. And that takes a lot of effort. So a lot of what we're doing now is more table stakes, just realizing that the project is used around the world very widely. >>Yeah. The thing that I'm most interested in is, we announced in the last six months a project called Envoy Gateway, which is layered on top of Envoy. And the goal of Envoy Gateway is to make it easier for people to run Envoy within Kubernetes. So essentially as an, as an ingress controller. And Envoy is a project historically, it is a very sophisticated piece of software, very complicated piece of software. It's not for everyone. And we want to provide Envoy Gateway as a way of onboarding more users into the Envoy ecosystem and making Envoy the, the default API gateway or edge proxy within Kubernetes. But in terms of use cases, we see Envoy pervasively with service mesh, API gateway, other types of low balancing cases. I mean, honestly, it's, it's all over the place at >>This point. I'm curious because you mentioned it's expanded beyond your wildest dreams. Yeah. And how could you have even imagined what Envoy was gonna do? Is there a use case or an application that really surprised you? >>You know, I've been asked that before and I, it's hard for me to answer that. It's, it's more that, I mean, for example, Envoy is used by basically every major internet company in China. I mean, like, wow. Everyone in China uses Envoy, like TikTok, like Alibaba. I mean like everyone, all >>The large sale, >>Everyone. You know, and it's used, it's used in the, I'm just, it's not just even the us. So I, I think the thing that has surprised me more than individual use cases is just the, the worldwide adoption. You know, that something could be be everywhere. And that I think, you know, when I open my phone and I'm opening all of these apps on my phone, 80 or 90% of them are going through Envoy in some form. Yeah. You know, it's, it's just that pervasive, I blow your mind a little bit sometimes >>That does, that's why you say plumber on your Twitter handle as your title. Cause you're working on all these things that are like really important substrate issues, Right. For scale, stability, growth. >>And, you know, to, I, I guess the only thing that I would add is, my goal for Envoy has always been that it is that boring, transparent piece of technology. Kind of similar to Linux. Linux is everywhere. Right? But no one really knows that they're using Linux. It's, it's justs like Intel inside, we're not paying attention. It's just there, there's >>A core group working on, if they have pride, they understand the mission, the importance of it, and they make their job is to make it invisible. >>Right. Exactly. >>And that's really ease of use. What's some of the ease of use sways and, and simplicity that you're working on, if you can talk about that. Because to be boring, you gotta be simpler and easier. All boring complex is unique is not boring. Complex is stressful. No, >>I I think we approach it in a couple different ways. One of them is that because we view Envoy as a, as a base technology in the ecosystem, we're starting to see, you know, not only vendors, but other open source projects that are being built on top of Envoy. So things like API Gateway, sorry, Envoy Gateway or you know, projects like Istio or all the other projects that are out there. They use Envoy as a component, but in some sense Envoy is a, as a transparent piece of that system. Yeah. So I'm a big believer in the ecosystem that we need to continue to make cloud native easier for, for end users. I still think it's too complicated. And so I think we're there, we're, we're pushing up the stack a bit. >>Yeah. And that brings up a good point. When you start seeing people building on top of things, right? That's enabling. So as you look at the enablement of Envoy, what are some of the things you see out on the horizon if you got the 20 mile stare out as you check these boring boxes, make it more plumbing, Right? Stable. You'll have a disruptive enabling platform. Yeah. What do you see out there? >>I am, you know, I, again, I'm not a big buzzword person, but, so some people call it serverless functions as a service, whatever. I'm a big believer in platforms in the sense that I really believe in the next 10 to 15 years, developers, they want to provide code. You know, they want to call APIs, they want to use pub subsystems, they want to use cas and databases. And honestly, they don't care about container scheduling or networking or load balancing or any of >>These things. It's handled in the os >>They just want it to be part of the operating system. Yeah, exactly. So I, I really believe that whether it's an open source or in cloud provider, you know, package solutions, that we're going to be just moving increasingly towards systems likes Lambda and Fargate and Google Cloud Run and Azure functions and all those kinds of things. And I think that when you do that much of the functionality that has historically powered this conference like Kubernetes and Onvoy, these become critical but transparent components that people don't, they're not really aware of >>At that point. Yeah. And I think that's a great call out because one of the things we're seeing is the market forces of, of this evolution, what you just said is what has to happen Yep. For digital transformation to, to get to its conclusion. Yep. Which means that everything doesn't have to serve the business, it is the business. Right. You know it in the old days. Yep. Engineers, they serve the business. Like what does that even mean? Yep. Now, right. Developers are the business, so they need that coding environment. So for your statement to happen, that simplicity in visibility calling is invisible os has to happen. So it brings up the question in open source, the trend is things always work itself out on the wash, as we say. So when you start having these debates and the alignment has to come at some point, you can't get to those that stay without some sort of defacto or consensus. Yep. And even standards, I'm not a big be around hardcore standards, but we can all agree and have consensus Sure. That will align behind, say Kubernetes, It's Kubernetes a standard. It's not like an i e you know, but this next, what, what's your reaction to this? Because this alignment has to come after debate. So all the process contending for I am the this of that. >>Yeah. I'm a look, I mean, I totally see the value in like i e e standards and, and there's a place for that. At the same time, for me personally as a technologist, as an engineer, I prefer to let the, the market as it were sort out what are the defacto standards. So for example, at least with Envoy, Envoy has an API that we call Xds. Xds is now used beyond Envoy. It's used by gc, it's used by proprietary systems. And I'm a big believer that actually Envoy in its form is probably gonna go away before Xds goes away. So in some ways Xds has become a defacto standard. It's not an i e e standard. Yeah. We, we, we have been asked about whether we should do that. Yeah. But I just, I I think the >>It becomes a component. >>It becomes a component. Yeah. And then I think people gravitate towards these things that become de facto standards. And I guess I would rather let the people on the show floor decide what are the standards than have, you know, 10 people sitting in a room figure out >>The community define standards versus organizational institutional defined standards. >>And they both have places a >>Hundred percent. Yeah, sure. And, and there's social proof in both of them. Yep. >>Frankly, >>And we were saying on the cube that we believe that the developers will decide the standard. Sure. Because that's what you're basically saying. They're deciding what they do with their code. Right. And over time, as people realize the trade of, hey, if everyone's coding this right. And makes my life easier to get to that state of nirvana and enlightenment, as we would say. Yeah. Yeah. >>Starting strong this morning. John, I I love this. I'm curious, you mentioned Backstage by Spotify wonderful example. Do you think that this is a trend we're gonna see with more end users >>Creating open source projects? Like I, you know, I hope so. The flip side of that, and as we all know, we're entering an uncertain economic time and it can be hard to justify the effort that it takes to do it well. And what I typically counsel people when they are about to open source something is don't do it unless you're ready to commit the resources. Because opensourcing something and not supporting it. Yeah. I actually can be think, I think it'd be worse. >>It's an, it's insult that people, you're asking to commit to something. Exactly. Needs of time, need the money investment, you gotta go all in and push. >>So I, so I very much want to see it and, and I want to encourage that here, but it's hard for me to look into the crystal ball and know, you know, whether it's gonna happen more >>Or less at what point there were, are there too many projects? You know, I mean, but I'm not, I mean this in, in a, in a negative way. I mean it more in the way of, you know, you mentioned supply chain. We were riffing on the cube about at some point there's gonna be so much code open source continuing thundering away with, with the value that you're just gluing things. Right. I don't need the code, this code there. Okay. What's in the code? Okay. Maybe automation can help out on supply chain. Yeah. But ultimately composability is the new >>Right? It is. Yeah. And, and I think that's always going to be the case. Case. Good thing. It is good thing. And I, I think that's just, that's just the way of things for sure. >>So no code will be, >>I think, I think we're seeing a lot of no code situations that are working great for people. And, and, but this is actually really no different than my, than my serverless arguing from before. Just as a, as a, a slight digression. I'm building something new right now and you know, we're using cloud native technologies and all this stuff and it's still, >>What are you building? >>Even as a I'm, I'm gonna keep that, I'm gonna keep that secret. I know I'm, but >>We'll find out on Twitter. We're gonna find out now that we know it. Okay. Keep on mystery. You open that door. We're going down see in a couple weeks. >>Front >>Page is still an angle. >>But I, I was just gonna say that, you know, and I consider myself, you know, you're building something, I'm, I see myself an expert in the cloud native space. It's still difficult, It's difficult to, to pull together these technologies and I think that we will continue to make it easier for people. >>What's the biggest difficulties? Can you give us some examples? >>Well, just, I mean, we still live in a big mess of yammel, right? Is a, there's a, there's a lot of yaml out there. And I think just wrangling all of that in these systems, there's still a lot of cobbling together where I think that there can be unified platforms that make it easier for us to focus on our application logic. >>Yeah. I gotta ask you a question cuz I've talked to college kids all the time. My son's a junior in CS and he's, you know, he's coding away. What would you, how does a student or someone who's learning figure out where, who they are? Because there's now, you know, you're either into the infrastructure under the hood Yeah. Or you're, cuz that's coding there option now coding the way your infrastructure people are working on say the boring stuff so everyone else can have ease of use. And then what is just, I wanna just code, there's two types of personas. How does someone know who they are? >>My, when I give people career advice, my biggest piece of advice to them is in the first five to seven to 10 years of their career, I encourage people to do different things like every say one to two to three years. And that doesn't mean like quitting companies and changing companies, it could mean, you know, within a company that they join doing different teams, you know, working on front end versus back end. Because honestly I think people don't know. I think it's actually very, Yeah. Our industry is so broad. Yeah. That I think it's almost impossible to >>Know. You gotta get your hands dirty to jump >>In order to know what you like. And for me, in my career, you know, I've dabbled in different areas, but I've always come back to infrastructure, you know, that that's what I enjoy >>The most. Okay. You gotta, you gotta taste everything. See what you, what >>You like. Exactly. >>Right. Last question for you, Matt. It's been three years since you were here. Yep. What do you hope that we're able to say next year? That we can't say this year? Hmm. Beyond the secrets of your project, which hopefully we will definitely be discussing then. >>You know, I I, I don't have anything in particular. I would just say that I would like to see more movement towards projects that are synthesizing and making it easier to use a lot of the existing projects that we have today. So for example, I'm, I'm very bullish on backstage. Like I, I've, I've always said that we need better developer UIs that are not CLIs. Like I know it's a general perception among many people. Totally agree with you. Frankly, you're not a real systems engineer unless you type on the command line. I, I think better user interfaces are better for humans. Yep. So just for a project like Backstage to be more integrated with the rest of the projects, whether that be Envo or Kubernete or Argo or Flagger. I, I just, I think there's tremendous potential for further integration of some >>Of these projects. It just composability That makes total sense. Yep. Yep. You're, you're op you're operating and composing. >>Yep. And there's no reason that user experience can't be better. And then more people can create and build. So I think it's awesome. Matt, thank you so much. Thank you. Yeah, this has been fantastic. Be sure and check out Matt on Twitter to find out what that next secret project is. John, thank you for joining me this morning. My name is Savannah Peterson and we'll be here all day live from the cube. We hope you'll be joining us throughout the evening until a happy hour today. Thanks for coming. Thanks for coming. Thanks for watching.

(upbeat music) >> Welcome to theCube's coverage of AWS Storage Day. We're here with a couple of AWS product experts. Covering AWS's migration and transfer services, Randy Boutin is the general manager of AWS DataSync, and Mat Matthews, GM of AWS Transfer Family. Guys, good to see you again. Thanks for coming on. >> Dave, thanks. >> So look, we saw during the pandemic, the acceleration to cloud migration. We've tracked that, we've quantified that. What's driving that today? >> Yeah, so Dave, great to be back here. Saw you last year at Storage Day. >> Nice to be in studio too, isn't it? Thanks, guys, for coming in. >> We've conquered COVID. >> So yeah, I mean, this is a great question. I think digital transformation is really what's driving a lot of the focus right now from companies, and it's really not about just driving down costs. It's also about what are the opportunities available once you get into the cloud in terms of, what does that unlock in terms of innovation? So companies are focused on the usual things, optimizing costs, but ensuring they have the right security and agility. You know, a lot has happened over the last year, and companies need to be able to react, right? They need to be able to react quickly, so cloud gives them a lot of these capabilities, but the real benefit that we see is that once your data's in the cloud, it opens up the power of the cloud for analytics, for new application development, and things of that sort, so what we're seeing is that companies are really just focused on understanding cloud migration strategy, and how they can get their data there, and then use that to unlock that data for the value. >> I mean, if I've said it once, I've said it 100 times, if you weren't a digital business during the pandemic, you were out of business. You know, migration historically is a bad word in IT. Your CIOs see it and go, "Ugh." So what's the playbook for taking years of data on-prem, and moving it into the cloud? What are you seeing as best practice there? >> Yeah, so as you said, the migration historically has been painful, right? And it's a daunting task for any business or any IT executive, but fortunately, AWS has a broad suite of capabilities to help enable these migrations. And by that, I mean, we have tools to help you understand your existing on-prem workloads, understand what services in the AWS offering align to those needs, but also help you estimate the cost, right? Cost is a big part of this move. We can help you estimate that cost, and predict that cost, and then use tools like DataSync to help you move that data when that time comes. >> So you're saying you help predict the cost of the migration, or the cost of running in the cloud? >> Running in the cloud, right. Yeah, we can help estimate the run time. Based on the performance that we assess on-prem, we can then project that into a cloud service, and estimate that cost. >> So can you guys explain DataSync? Sometimes I get confused, DataSync, what's the difference between DataSync and Storage Gateway? And I want to get into when we should use each, but let's start there if we could. >> Yeah, sure, I'll take that. So Storage Gateway is primarily a means for a customer to access their data in the cloud from on-prem. All right, so if you have an application that you want to keep on-prem, you're not ready yet to migrate that application to the cloud, Gateway is a strong solution, because you can move a lot of that data, a lot of your cold or long tail data into something like S3 or EFS, but still access it from your on-prem location. DataSync's all about data movement, so if you need to move your data from A to B, DataSync is your optimized solution to do that. >> Are you finding that people, that's ideally a one time move, or is it actually, sometimes you're seeing customers do it more? Again, moving data, if I don't- Move as much data as you need to, but no more, to paraphrase Einstein. >> What we're seeing in DataSync is that customers do use DataSync for their initial migration. They'll also, as Matt was mentioning earlier, once you get your data into the cloud, that flywheel of potential starts to take hold, and customers want to ultimately move that data within the cloud to optimize its value. So you might move from service to service. You might move from EFS to S3, et cetera, to enable the cloud flywheel to benefit you. DataSync does that as well, so customers use us to initially migrate, they use us to move within the cloud, and also we just recently announced service for other clouds, so you can actually bring data in now from Google and Azure as well. >> Oh, how convenient. So okay, so that's cool. So you helped us understand the use cases, but can we dig one more layer, like what protocols are supported? I'm trying to understand really the right fit for the right job. >> Yeah, so that's really important. So for transfer specifically, one of the things that we see with customers is you've got obviously a lot of internal data within your company, but today it's a very highly interconnected world, so companies deal with lots of business partners, and historically they've used, there's a big prevalence of using file transfer to exchange data with business partners, and as you can imagine, there's a lot of value in that data, right? Sometimes it's purchase orders, inventory data from suppliers, or things like that. So historically customers have had protocols like SFTP or FTP to help them interface with or exchange data or files with external partners. So for transfer, that's what we focus on is helping customers exchange data over those existing protocols that they've used for many years. And the real focus is it's one thing to migrate your own data into the cloud, but you can't force thousands or tens of thousands sometimes of partners to also work in a different way to get you their data, so we want to make that very seamless for customers using the same exact protocols like SFTP that they've used for years. We just announced AS2 protocol, which is very heavily used in supply chains to exchange inventory and information across multi-tiers of partners, and things of that nature. So we're really focused on letting customers not have to impact their partners, and how they work and how they exchange, but also take advantage of the data, so get that data into the cloud so they can immediately unlock the value with analytics. >> So AS2 is specifically in the context of supply chain, and I'm presuming it's secure, and kind of governed, and safe. Can you explain that a little bit? >> Yeah, so AS2 has a lot of really interesting features for transactional type of exchanges, so it has signing and encryption built in, and also has notification so you can basically say, "Hey, I sent you this purchase order," and to prove that you received it, it has capability called non-repudiation, which means it's actually a legal transaction. So those things are very important in transactional type of exchanges, and allows customers in supply chains, whether it's vendors dealing with their suppliers, or transportation partners, or things like that to leverage file transfer for those types of exchanges. >> So encryption, providence of transactions, am I correct, without having to use the blockchain, and all the overhead associated with that? >> It's got some built in capabilities. >> I mean, I love blockchain, but there's drawbacks. >> Exactly, and that's why it's been popular. >> That's really interesting, 'cause Andy Jassy one day, I was on a phone call with him and John Furrier, and we were talking up crypto and blockchain. He said, "Well, why do, explain to me." You know Jassy, right? He always wants to go deeper. "Explain why I can't do this with some other approach." And so I think he was recognizing some of the drawbacks. So that's kind of a cool thing, and it leads me- We're running this obviously today, August 10th. Yesterday we had our Supercloud event in Palo Alto on August 9th, and it's all about the ecosystem. One of the observations we made about the 2020s is the cloud is totally different now. People are building value on top of the infrastructure that you guys have built out over the last 15 years. And so once an organization's data gets into the cloud, how does it affect, and it relates to AS2 somewhat, how does it affect the workflows in terms of interacting with external partners, and other ecosystem players that are also in the cloud? >> Yeah, great, yeah, again, we want to try and not have to affect those workflows, take them as they are as much as possible, get the data exchange working. One of the things that we focus on a lot is, how do you process this data once it comes in? Every company has governance requirements, security requirements, and things like that, so they usually have a set of things that they need to automate and orchestrate for the data as it's coming in, and a lot of these companies use something called Managed File Transfer Solutions that allow them to automate and orchestrate those things. We also see that many times this is very customer specific, so a bank might have a certain set of processes they have to follow, and it needs to be customized. As you know, AWS is a great solution for building custom solutions, and actually today, we're just announcing a new set of of partners in a program called the Service Delivery Program with AWS Transfer Family that allows customers to work with partners that are very well versed in transfer family and related services to help build a very specific solution that allows them to build that automation orchestration, and keep their partners kind of unaware that they're interfacing in a different way. >> And once this data is in the cloud, or actually, maybe stays on-prem in some cases, but it basically plugs in to the AWS services portfolio, the whole security model, the governance model, shared responsibility comes in, is that right? It's all, sort of all in there? >> Yeah, that's right, that's exactly right, and we're working with it's all about the customer's needs, and making sure that their investment in AWS doesn't disrupt their existing workflows and their relationships with their customers and their partners, and that's exactly what Matt's been describing is we're taking a close look at how we can extend the value of AWS, integrate into our customer's workflows, and bring that value to them with minimal investment or disruption. >> So follow up on that. So I love that, because less disruption means it's easier, less friction, and I think of like, trying to think of examples. Think about data de-duplication like purpose-built backup appliances, right? Data domain won that battle, because they could just plug right in. Avamar, they were trying to get you to redo everything, okay, and so we saw that movie play out. At the same time, I've talked to CIOs that say, "I love that, but the cloud opens up all these cool new opportunities for me to change my operating model." So are you seeing that as well? Where okay, we make it easy to get in. We're not disrupting workflows, and then once they get in, they say, "Well if we did it this way, we'd take out a bunch of costs. We'd accelerate our business." What's that dynamic like? >> Exactly that, right. So that moved to the Cloud Continuum. We don't think it's going to be binary. There's always going to be something on-prem. We accept that, but there's a continuum there, so day one, they'll migrate a portion of that workload into the cloud, start to extract and see value there, but then they'll continue, as you said, they'll continue to see opportunities. With all of the various capabilities that AWS has to offer, all the value that represents, they'll start to see that opportunity, and then start to engage and consume more of those features over time. >> Great, all right, give us the bumper sticker. What's next in transfer services from your perspectives? >> Yeah, so we're obviously always going to listen to our customers, that's our focus. >> You guys say that a lot. (all laughing) We say it a lot. But yeah, so we're focused on helping customers again increase that level of automation orchestration, again that suite of capability, generally, in our industry, known as managed file transfer, when a file comes in, it needs to get maybe encrypted, or decrypted, or compressed, or decompressed, scanned for viruses, those kind of capabilities, make that easier for customers. If you remember last year at Storage Day, we announced a low code workflow framework that allows customers to kind of build those steps. We're continuing to add built-in capabilities to that so customers can easily just say, "Okay, I want these set of activities to happen when files come in and out." So that's really what's next for us. >> All right, Randy, we'll give you the last word. Bring us home. >> I'm going to surprise you with the customer theme. >> Oh, great, love it. >> Yeah, so we're listening to customers, and what they're asking for our support for more sources, so we'll be adding support for more cloud sources, more on-prem sources, and giving the customers more options, also performance and usability, right? So we want to make it easier, as the enterprise continues to consume the cloud, we want to make DataSync and the movement of their data as easy as possible. >> I've always said it starts with the data. S3, that was the first service, and the other thing I've said a lot is the cloud is expanding. We're seeing connections to on-prem. We're seeing connections out to the edge. It's just becoming this massive global system, as Werner Vogels talks about all the time. Thanks, guys, really appreciate it. >> Dave, thank you very much. >> Thanks, Dave. >> All right, keep it right there for more coverage of AWS Storage Day 2022. You're watching theCube. (upbeat music)

(calm electronic music) >> Okay, welcome back everyone to theCUBE's coverage here live in New York City for AWS Summit 2022. I'm John Furrier, host of theCUBE, but a great conversation here as the day winds down. First of all, 10,000 plus people, this is a big event, just New York City. So sign of the times that some headwinds are happening? I don't think so, not in the cloud enterprise innovation game. Lot going on, this innovation conversation we're going to have now is about the confluence of cloud scale integration data and the future of how FinTech and other markets are going to change with technology. We got Chris Thomas, the CTO of Slalom, and Rob Krugman, chief digital officer at Broadridge. Gentlemen, thanks for coming on theCUBE. >> Thanks for having us. >> So we had a talk before we came on camera about your firm, what you guys do, take a quick minute to just give the scope and size of your firm and what you guys work on. >> Yeah, so Broadridge is a global financial FinTech company. We work on, part of our business is capital markets and wealth, and that's about a third of our business, about $7 trillion a day clearing through our platforms. And then the other side of our business is communications where we help all different types of organizations communicate with their shareholders, communicate with their customers across a variety of different digital channels and capabilities. >> Yeah, and Slalom, give a quick one minute on Slalom. I know you guys, but for the folks that don't know you. >> Yeah, no problem. So Slalom is a modern consulting firm focused on strategy, technology, and business transformation. And me personally, I'm part of the element lab, which is focused on forward thinking technology and disruptive technology in the next five to 10 years. >> Awesome, and that's the scope of this conversation. The next five to 10 years, you guys are working on a project together, you're kind of customer partners. You're building something. What are you guys working on? I can't wait to jump into it, explain. >> Sure, so similar to Chris, at Broadridge, we've created innovation capability, innovation incubation capability, and one of the first areas we're experimenting in is digital assets. So what we're looking to do is we're looking at a variety of different areas where we think consolidation network effects that we could bring can add a significant amount of value. And so the area we're working on is this concept of a wallet of wallets. How do we actually consolidate assets that are held across a variety of different wallets, maybe traditional locations- >> Digital wallets. >> Digital wallets, but maybe even traditional accounts, bring that together and then give control back to the consumer of who they want to share that information with, how they want their transactions to be able to control. So the idea of, people talk about Web 3 being the internet of value. I often think about it as the internet of control. How do you return control back to the individual so that they can make decisions about how and who has access to their information and assets? >> It's interesting, I totally like the value angle, but your point is what's the chicken and the egg here, the cart before the horse, you can look at it both ways and say, okay, control is going to drive the value. This is an interesting nuance, right? >> Yes, absolutely. >> So in this architectural world, they thought about the data plane and the control plane. Everyone's trying to go old school, middleware thinking. Let's own the data plane, we'll win everything. Not going to happen if it goes decentralized, right, Chris? >> Yeah, yeah. I mean, we're building a decentralized application, but it really is built on top of AWS. We have a serverless architecture that scales as our business scales built on top of things like S3, Lambda, DynamoDB, and of course using those security principles like Cognito and AWS Gateway, API Gateway. So we're really building an architecture of Web 3 on top of the Web 2 basics in the cloud. >> I mean, all evolutions are abstractions on top of each other, IG, DNS, Key, it goes the whole nine yards. In digital, at least, that's the way. Question about serverless real quick. I saw that Redshift just launched general availability of serverless in Redshift? >> Yes. >> You're starting to see the serverless now part of almost all the services in AWS. Is that enabling that abstraction, because most people don't see it that way. They go, oh, well, Amazon's not Web 3. They got databases, you could use that stuff. So how do you connect the dots and cross the bridge to the future with the idea that I might not think Web 2 or cloud is Web 3? >> I'll jump in quick. I mean, I think it's the decentralize. If you think about decentralization. serverless and decentralization, you could argue are the same way of, they're saying the same thing in different ways. One is thinking about it from a technology perspective. One is thinking about it from an ecosystem perspective and how things come together. You need serverless components that can talk to each other and communicate with each other to actually really reach the promise of what Web 3 is supposed to be. >> So digital bits or digital assets, I call it digital bits, 'cause I think zero ones. If you digitize everything and everything has value or now control drives the value. I could be a soccer team. I have apparel, I have value in my logos, I have photos, I have CUBE videos. I mean some say that this should be an NFT. Yeah, right, maybe, but digital assets have to be protected, but owned. So ownership drives it too, right? >> Absolutely. >> So how does that fit in, how do you explain that? 'Cause I'm trying to tie the dots here, connect the dots and tie it together. What do I get if I go down this road that you guys are building? >> So I think one of the challenges of digital assets right now is that it's a closed community. And I think the people that play in it, they're really into it. And so you look at things like NFTs and you look at some of the other activities that are happening and there are certain naysayers that look at it and say, this stuff is not based upon value. It's a bunch of artwork, it can't be worth this. Well, how about we do a time out there and we actually look at the underlying technology that's supporting this, the blockchain, and the potential ramifications of that across the entire financial ecosystem, and frankly, all different types of ecosystems of having this immutable record, where information gets stored and gets sent and the ability to go back to it at all times, that's where the real power is. So I think we're starting to see. We've hit a bit of a hiccup, if you will, in the cryptocurrencies. They're going to continue to be there. They won't all be there. A lot of them will probably disappear, but they'll be a finite number. >> What percentage of stuff do you think is vapor BS? If you had to pick an order of magnitude number. >> (laughs) I would say at least 75% of it. (John laughs) >> I mean, there's quite a few projects that are failing right now, but it's interesting in that in the crypto markets, they're failing gracefully. Because it's on the blockchain and it's all very transparent. Things are checked, you know immediately which companies are insolvent and which opportunities are still working. So it's very, very interesting in my opinion. >> Well, and I think the ones that don't have valid premises are the ones that are failing. Like Terra and some of these other ones, if you actually really looked at it, the entire industry knew these things were no good. But then you look at stable coins. And you look at what's going on with CBDCs. These are backed by real underlying assets that people can be comfortable with. And there's not a question of, is this going to happen? The question is, how quickly is it going to happen and how quickly are we going to be using digital currencies? >> It's interesting, we always talk about software, software as money now, money is software and gold and oil's moving over to that crypto. How do you guys see software? 'Cause we were just arguing in the queue, Dave Vellante and I, before you guys came on that the software industry pretty much does not exist anymore, it's open source. So everything's open source as an industry, but the value is integration, innovation. So it's not just software, it's the free. So you got to, it's integration. So how do you guys see this software driving crypto? Because it is software defined money at the end of the day. It's a token. >> No, I think that's absolutely one of the strengths of the crypto markets and the Web 3 market is it's governed by software. And because of that, you can build a trust framework. Everybody knows it's on the public blockchain. Everybody's aware of the software that's driving the rules and the rules of engagement in this blockchain. And it creates that trust network that says, hey, I can transact with you even though I don't know anything about you and I don't need a middleman to tell me I can trust you. Because this software drives that trust framework. >> Lot of disruption, lot of companies go out of business as a middleman in these markets. >> Listen, the intermediaries either have to disrupt themselves or they will be disrupted. I think that's what we're going to learn here. And it's going to start in financial services, but it's going to go to a lot of different places. I think the interesting thing that's happening now is for the first time, you're starting to see the regulators start to get involved. Which is actually a really good thing for the market. Because to Chris's point, transparency is here, how do you actually present that transparency and that trust back to consumers so they feel comfortable once that problem is solved. And I think everyone in the industry welcomes it. All of a sudden you have this ecosystem that people can play in, they can build and they can start to actually create real value. >> Every structural change that I've been involved in my 30 plus year career has been around inflection points. There was always some sort of underbelly. So I'm not going to judge crypto. It's been in the market for a while, but it's a good sign there's innovation happening. So as now, clarity comes into what's real. I think you guys are talking a conversation I think is refreshing because you're saying, okay, cloud is real, Lambda, serverless, all these tools. So Web 3 is certainly real because it's a future architecture, but it's attracting the young, it's a cultural shift. And it's also cooler than boring Web 2 and cloud. So I think the cultural shift, the fact that it's got data involved, there's some disruption around middleman and intermediaries, makes it very attractive to tech geeks. You look at, I read a stat, I heard a stat from a friend in the Bay Area that 30% of Cal computer science students are dropping out and jumping into crypto. So it's attracting the technical nerds, alpha geeks. It's a cultural revolution and there's some cool stuff going on from a business model standpoint. >> There's one thing missing. The thing that's missing, it's what we're trying to work on, I think is experience. I think if you're being honest about the entire marketplace, what you would agree is that this stuff is not easy to use today, and that's got to be satisfied. You need to do something that if it's the 85 year old grandma that wants to actually participate in these markets that not only can they feel comfortable, but they actually know how to do it. You can't use these crazy tools where you use these terms. And I think the industry, as it grows up, will satisfy a lot of those issues. >> And I think this is why I want to tie back and get your reaction to this. I think that's why you guys talking about building on top of AWS is refreshing, 'cause it's not dogmatic. Well, we can't use Amazon, it's not really Web 3. Well, a database could be used when you need it. You don't need to write everything through the blockchain. Databases are a very valuable capability, you get serverless. So all these things now can work together. So what do you guys see for companies that want to be Web 3 for all the good reasons and how do they leverage cloud specifically to get there? What are some things that you guys have learned that you can point to and share, you want to start? >> Well, I think not everything has to be open and public to everybody. You're going to want to have some things that are secret. You're going to want to encrypt some things. You're going to want to put some things within your own walls. And that's where AWS really excels. I think you can have the best of both worlds. So that's my perspective on it. >> The only thing I would add to it, so my view is it's 2022. I actually was joking earlier. I think I was at the first re:Invent. And I remember walking in and this was a new industry. >> It was tiny. >> This is foundational. Like cloud is not a, I don't view like, we shouldn't be having that conversation anymore. Of course you should build this stuff on top of the cloud. Of course you should build it on top of AWS. It just makes sense. And we should, instead of worrying about those challenges, what we should be worrying about are how do we make these applications easier to use? How do we actually- >> Energy efficient. >> How do we enable the promise of what these things are going to bring, and actually make it real, because if it happens, think about traditional assets. There's projects going on globally that are looking at how do you take equity securities and actually move them to the blockchain. When that stuff happens, boom. >> And I like what you guys are doing, I saw the news out through this crypto winter, some major wallet exchanges that have been advertising are hurting. Take me through what you guys are thinking, what the vision is around the wallet of wallets. Is it to provide an experience for the user or the market industry itself? What's the target, is it both? Share the design goals for the wallet of wallets. >> My favorite thing about innovation and innovation labs is that we can experiment. So I'll go in saying we don't know what the final answer is going to be, but this is the premise that we have. In this disparate decentralized ecosystem, you need some mechanism to be able to control what's actually happening at the consumer level. So I think the key target is how do you create an experience where the consumer feels like they're in control of that value? How do they actually control the underlying assets? And then how does it actually get delivered to them? Is it something that comes from their bank, from their broker? Is it coming from an independent organization? How do they manage all of that information? And I think the last part of it are the assets. It's easy to think about cryptos and NFTs, but thinking about traditional assets, thinking about identity information and healthcare records, all of that stuff is going to become part of this ecosystem. And imagine being able to go someplace and saying, oh, you need my information. Well, I'm going to give it to you off my phone and I'm going to give it to you for the next 24 hours so you can use it, but after that you have no access to it. Or you're my financial advisor, here's a view of what I actually have, my underlying assets. What do you recommend I do? So I think we're going to see an evolution in the market. >> Like a data clean room. >> Yeah, but that you control. >> Yes! (laughs) >> Yes! >> I think about it very similarly as well. As my journey into the crypto market has gone through different pathways, different avenues. And I've come to a place where I'm really managing eight different wallets and it's difficult to figure exactly where all my assets are and having a tool like this will allow me to visualize and aggregate those assets and maybe even recombine them in unique ways, I think is hugely valuable. >> My biggest fear is losing my key. >> Well, and that's an experience problem that has to be solved, but let me give you, my favorite use case in this space is, 'cause NFTs, right? People are like, what does NFTs really mean? Title insurance, right? Anyone buy a house or refinance your mortgage? You go through this crazy process that costs seven or eight thousand dollars every single time you close on something to get title insurance so they could validate it. What if that title was actually sitting on the chain, you got an NFT that you put in your wallet and when it goes time to sell your house or to refinance, everything's there. Okay, I'm the owner of the house. I don't know, JP Morgan Chase has the actual mortgage. There's another lien, there's some taxes. >> It's like a link tree in the wallet. (laughs) >> Yeah, think about it, you got a smart contract. Boom, closing happens immediately. >> I think that's one of the most important things. I think people look at NFTs and they think, oh, this is art. And that's sort of how it started in the art and collectable space, but it's actually quickly moving towards utilities and tokenization and passes. And that's where I think the value is. >> And ownership and the token. >> Identity and ownership, especially. >> And the digital rights ownership and the economics behind it really have a lot of scale 'cause I appreciate the FinTech angle you are coming from because I can now see what's going on here with you. It's like, okay, we got to start somewhere. Let's start with the experience. The wallet's a tough nut to crack, 'cause that requires defacto participation in the industry as a defacto standard. So how are you guys doing there? Can you give an update and then how can people get, what's the project called and how do people get involved? >> Yeah, so we're still in the innovation, incubation stages. So we're not launching it yet. But what I will tell you is what a lot of our focus is, how do we make these transactional things that you do? How do we make it easy to pull all your assets together? How do we make it easy to move things from one location to the other location in ways that you're not using a weird cryptographic numeric value for your wallet, but you actually can use real nomenclature that you can renumber and it's easy to understand. Our expectation is that sometime in the fall, we'll actually be in a position to launch this. What we're going to do over the summer is we're going to start allowing people to play with it, get their feedback, and we're going to iterate. >> So sandbox in when, November? >> I think launch in the fall, sometime in the fall. >> Oh, this fall. >> But over the summer, what we're expecting is some type of friends and family type release where we can start to realize what people are doing and then fix the challenges, see if we're on the right track and make the appropriate corrections. >> So right now you guys are just together on this? >> Yep. >> The opening up friends and family or community is going to be controlled. >> It is, yeah. >> Yeah, as a group, I think one thing that's really important to highlight is that we're an innovation lab. We're working with Broadridge's innovation lab, that partnership across innovation labs has allowed us to move very, very quickly to build this. Actually, if you think about it, we were talking about this not too long ago and we're almost close to having an internal launch. So I think it's very rapid development. We follow a lot of the- >> There's buy-in across the board. >> Exactly, exactly, and we saw lot of very- >> So who's going to run this? A Dow, or your companies, is it going to be a separate company? >> So to be honest, we're not entirely sure yet. It's a new product that we're going to be creating. What we actually do with it. Our thought is within an innovation environment, there's three things you could do with something. You can make it a product within the existing infrastructure, you can create a new business unit or you can spin it off as something new. I do think this becomes a product within the organization based upon it's so aligned to what we do today, but we'll see. >> But you guys are financing it? >> Yes. >> As collective companies? >> Yeah, right. >> Got it, okay, cool. Well, let us know how we can help. If you guys want to do a remote in to theCUBE. I would love the mission you guys are on. I think this is the kind of work that every company should be doing in the new R and D. You got to jump in the deep end and swim as fast as possible. But I think you can do it. I think that is refreshing and that's smart. >> And you have to do it quick because this market, I think the one thing we would probably agree on is that it's moving faster than we could, every week there's something else that happens. >> Okay, so now you guys were at Consensus down in Austin when the winter hit and you've been in the business for a long time, you got to know the industries. You see where it's going. What was the big thing you guys learned, any scar tissue from the early data coming in from the collaboration? Was there some aha moments, was there some oh shoot moments? Oh, wow, I didn't think that was going to happen. Share some anecdotal stories from the experience. Good, bad, and if you want to be bold say ugly, too. >> Well, I think the first thing I want to say about the timing, it is the crypto winter, but I actually think now's a really great time to build something because everybody's continuing to build. Folks are focused on the future and that's what we are as well. In terms of some of the challenges, well, the Web 3 space is so new. And there's not a way to just go online and copy somebody else's work and rinse and repeat. We had to figure a lot of things on our own. We had to try different technologies, see which worked better and make sure that it was functioning the way we wanted it to function. Really, so it was not easy. >> They oversold that product out, that's good, like this team. >> But think about it, so the joke is that when winter is when real work happens. If you look at the companies that have not been affected by this it's the infrastructure companies and what it reminds me of, it's a little bit different, but 2001, we had the dot com bust. The entire industry blew up, but what came out of that? >> Everything that exists. >> Amazon, lots of companies grew up out of that environment. >> Everything that was promoted actually happened. >> Yes, but you know what didn't happen- >> Food delivery. >> But you know what's interesting that didn't happen- >> (laughs) Pet food, the soccer never happened. >> The whole Super Bowl, yes. (John laughs) In financial services we built on top of legacy. I think what Web 3 is doing, it's getting rid of that legacy infrastructure. And the banks are going to be involved. There's going to be new players and stuff. But what I'm seeing now is a doubling down of the infrastructure investment of saying okay, how do we actually make this stuff real so we can actually show the promise? >> One of the things I just shared, Rob, you'd appreciate this, is that the digital advertising market's changing because now banner ads and the old techniques are based on Web 2 infrastructure, basically DNS as we know it. And token problems are everywhere. Sites and silos are built because LinkedIn doesn't share information. And the sites want first party data. It's a hoarding exercise, so those practices are going to get decimated. So in comes token economics, that's going to get decimated. So you're already seeing the decline of media. And advertising, cookies are going away. >> I think it's going to change, it's going to be a flip, because I think right now you're not in control. Other people are in control. And I think with tokenomics and some of the other things that are going to happen, it gives back control to the individual. Think about it, right now you get advertising. Now you didn't say I wanted this advertising. Imagine the value of advertising when you say, you know what, I am interested in getting information about this particular type of product. The lead generation, the value of that advertising is significantly higher. >> Organic notifications. >> Yeah. >> Well, gentlemen, I'd love to follow up with you. I'm definitely going to ping in. Now I'm going to put CUBE coin back on the table. For our audience CUBE coin's coming. Really appreciate it, thanks for sharing your insights. Great conversation. >> Excellent, thank you for having us. >> Excellent, thank you so much. >> theCUBE's coverage here from New York City. I'm John Furrier, we'll be back with more live coverage to close out the day. Stay with us, we'll be right back. >> Excellent. (calm electronic music)

(innovative music) >> Welcome back to theCUBE's continuous coverage of AWS re:Invent 2021. My name is Dave Vellante, and we are running one of the industry's most important and largest hybrid tech events of the year. Hybrid as in physical, not a lot of that going on this year. But we're here with the AWS ecosystem, AWS, and special thanks to AMD for supporting this year's editorial coverage of the event. We've got two live sets, two remote studios, more than a hundred guests on the program. We're going really deep, as we enter the next decade of Cloud innovation. We're super excited to be joined by Danny Allan, who's the Chief Technology Officer at Veeam, and James Kirschner who's the Engineering Director for Amazon S3. Guys, great to see you. >> Great to see you as well, Dave. >> Thanks for having me. >> So let's kick things off. Veeam and AWS, you guys have been partnering for a long time. Danny, where's the focus at this point in time? What are customers telling you they want you to solve for? And then maybe James, you can weigh in on the problems that customers are facing, and the opportunities that they see ahead. But Danny, why don't you start us off? >> Sure. So we hear from our customers a lot that they certainly want the solutions that Veeam is bringing to market, in terms of data protection. But one of the things that we're hearing is they want to move to Cloud. And so there's a number of capabilities that they're asking us for help with. Things like S3, things like EC2, and RDS. And so over the last, I'll say four or five years, we've been doing more and more together with AWS in, I'll say, two big categories. One is, how do we help them send their data to the Cloud? And we've done that in a very significant way. We support obviously tiering data into S3, but not just S3. We support S3, and S3 Glacier, and S3 Glacier Deep Archive. And more importantly than ever, we do it with immutability because customers are asking for security. So a big category of what we're working on is making sure that we can store data and we can do it securely. Second big category that we get asked about is "Help us to protect the Cloud-Native Workloads." So they have workloads running in EC2 and RDS, and EFS, and EKS, and all these different services knowing Cloud-Native Data Protection. So we're very focused on solving those problems for our customers. >> You know, James, it's interesting. I was out at the 15th anniversary of S3 in Seattle, in September. I was talking to Mai-Lan. Remember we used to talk about gigabytes and terabytes, but things have changed quite dramatically, haven't they? What's your take on this topic? >> Well, they sure have. We've seen the exponential growth data worldwide and that's made managing backups more difficult than ever before. We're seeing traditional methods like tape libraries and secondary sites fall behind, and many organizations are moving more and more of their workloads to the Cloud. They're extending backup targets to the Cloud as well. AWS offers the most storage services, data transfer methods and networking options with unmatched durability, security and affordability. And customers who are moving their Veeam Backups to AWS, they get all those benefits with a cost-effective offsite storage platform. Providing physical separation from on-premises primary data with pay-as-you-go economics, no upfront fees or capital investments, and near zero overhead to manage. AWS and APM partners like Veeam are helping to build secure, efficient, cost-effective backup, and restore solutions using the products you know and trust with the scale and reliability of the AWS Cloud. >> So thank you for that. Danny, I remember I was way back in the old days, it was a VeeamON physical event. And I remember kicking around and seeing this company called Kasten. And I was really interested in like, "You protect the containers, aren't they ephemeral?" And we started to sort of chit-chat about how that's going to change and what their vision was. Well, back in 2020, you purchased Kasten, you formed the Veeam KBU- the Kubernetes Business Unit. What was the rationale behind that acquisition? And then James, I'm going to get you to talk a little bit about modern apps. But Danny, start with the rationale behind the Kasten acquisition. >> Well, one of the things that we certainly believe is that the next generation of infrastructure is going to be based on containers, and there's a whole number of reasons for that. Things like scalability and portability. And there's a number of significant value-adds. So back in October of last year in 2020, as you mentioned, we acquired Kasten. And since that time we've been working through Kasten and from Veeam to add more capabilities and services around AWS. For example, we supported the Bottlerocket launch they just did and actually EKS anywhere. And so we're very focused on making sure that our customers can protect their data no matter whether it's a Kubernetes cluster, or whether it's on-premises in a data center, or if it's running up in the Cloud in EC2. We give this consistent data management experience and including, of course, the next generation of infrastructure that we believe will be based on containers. >> Yeah. You know, James, I've always noted to our audience that, "Hey AWS, they provide rich set of primitives and API's that ISV's like Veeam can take advantage of it." But I wonder if you could talk about your perspective, maybe what you're seeing in the ecosystem, maybe comment on what Veeam's doing. Specifically containers, app modernization in the Cloud, the evolution of S3 to support all these trends. >> Yeah. Well, it's been great to see Veeam expands for more and more AWS services to help joint customers protect their data. Especially since Veeam stores their data in Amazon S3 storage classes. And over the last 15 years, S3 has helped companies around the world optimize their work, so I'd be happy to share some insights into that with you today. When you think about S3 well, you can find virtually every use case across all industries running on S3. That ranges from backup, to (indistinct) data, to machine learning models, the list goes on and on. And one of the reasons is because S3 provides industry leading scalability, availability, durability, security, and performance. Those are characteristics customers want. To give you some examples, S3 stores exabytes the data across millions of hard drives, trillions of objects around the world and regularly peaks at millions of requests per second. S3 can process in a single region over 60 terabytes a second. So in summary, it's a very powerful storage offering. >> Yeah, indeed. So you guys always talking about, you know, working backwards, the customer centricity. I think frankly that AWS sort of change the culture of the entire industry. So, let's talk about customers. Danny do you have an example of a joint customer? Maybe how you're partnering with AWS to try to address some of the challenges in data protection. What are customers is seeing today? >> Well, we're certainly seeing that migration towards the Cloud as James alluded today. And actually, if we're talking about Kubernetes, actually there's a customer that I know of right now, Leidos. They're a fortune 500 Information Technology Company. They deal in the engineering and technology services space, and focus on highly regulated industry. Things like defense and intelligence in the civil space. And healthcare in these very regulated industries. Anyway, they decided to make a big investment in continuous integration, continuous development. There's a segment of the industry called portable DevSecOps, and they wanted to build infrastructure as code that they could deploy services, not in days or weeks or months, but they literally wanted to deploy their services in hours. And so they came to us, and with Kasten K10 actually around Kubernetes, they created a service that could enable them to do that. So they could be fully compliant, and they could deliver the services in, like I say, hours, not days or months. And they did that all while delivering the same security that they need in a cost-effective way. So it's been a great partnership, and that's just one example. We see these all the time, customers who want to combine the power of Kubernetes with the scale of the Cloud from AWS, with the data protection that comes from Veeam. >> Yes, so James, you know at AWS you don't get dinner if you don't have a customer example. So maybe you could share one with us. >> Yeah. We do love working backwards from customers and Danny, I loved hearing that story. One customer leveraging Veeam and AWS is Maritz. Maritz provides business performance solutions that connect people to results, ensuring brands deliver on their customer promises and drive growth. Recently Maritz moved over a thousand VM's and petabytes of data into AWS, using Veeam. Veeam Backup for AWS enables Maritz to protect their Amazon EC2 instances with the backup of the data in the Amazon S3 for highly available, cost-effective, long-term storage. >> You know, one of the hallmarks of Cloud is strong ecosystem. I see a lot of companies doing sort of their own version of Cloud. I always ask "What's the partner ecosystem look like?" Because that is a fundamental requirement, in my view anyway, and attribute. And so, a big part of that, Danny, is channel partners. And you have a 100 percent channel model. And I wonder if we could talk about your strategy in that regard. Why is it important to be all channel? How to consulting partners fit into the strategy? And then James, I'm going to ask you what's the fit with the AWS ecosystem. But Danny, let's start with you. >> Sure, so one of the things that we've learned, we're 15 years old as well, actually. I think we're about two months older, or younger I should say than AWS. I think their birthday was in August, ours was in October. But over that 15 years, we've learned that our customers enjoy the services, and support, and expertise that comes from the channel. And so we've always been a 100 percent channel company. And so one of the things that we've done with AWS is to make sure that our customers can purchase both how and when they want through the AWS marketplace. They have a program called Consulting Partners Private Agreements, or CPPO, I think is what it's known as. And that allows our customers to consume through the channel, but with the terms and bill that they associate with AWS. And so it's a new route-to-market for us, but we continue to partner with AWS in the channel programs as well. >> Yeah. The marketplace is really impressive. James, I wonder if you could maybe add in a little bit. >> Yeah. I think Danny said it well, AWS marketplace is a sales channel for ISV's and consulting partners. It lets them sell their solutions to AWS customers. And we focus on making it really easy for customers to find, buy, deploy, and manage software solutions, including software as a service in just a matter of minutes. >> Danny, you mentioned you're 15 years old. The first time I mean, the name Veeam. The brilliance of tying it to virtualization and VMware. I was at a VMUG when I first met you guys and saw your ascendancy tied to virtualization. And now you're obviously leaning heavily into the Cloud. You and I have talked a lot about the difference between just wrapping your stack in a container and hosting it in the Cloud versus actually taking advantage of Cloud-Native Services to drive further innovation. So my question to you is, where does Veeam fit on that spectrum, and specifically what Cloud-Native Services are you leveraging on AWS? And maybe what have been some outcomes of those efforts, if in fact that's what you're doing? And then James, I have a follow-up for you. >> Sure. So the, the outcomes clearly are just more success, more scale, more security. All the things that James is alluding to, that's true for Veeam it's true for our customers. And so if you look at the Cloud-Native capabilities that we protect today, certainly it began with EC2. So we run things in the Cloud in EC2, and we wanted to protect that. But we've gone well beyond that today, we protect RDS, we protect EFS- Elastic File Services. We talked about EKS- Elastic Kubernetes Services, ECS. So there's a number of these different services that we protect, and we're going to continue to expand on that. But the interesting thing is in all of these, Dave, when we do data protection, we're sending it to S3, and we're doing all of that management, and tiering, and security that our customers know and love and expect from Veeam. And so you'll continue to see these types of capabilities coming from Veeam as we go forward. >> Thank you for that. So James, as we know S3- very first service offered in 2006 on the AWS' Cloud. As I said, theCUBE was out in Seattle, September. It was a great, you know, a little semi-hybrid event. But so over the decade and a half, you really expanded the offerings quite dramatically. Including a number of, you got on-premise services things, like Outposts. You got other services with "Wintery" names. How have you seen partners take advantage of those services? Is there anything you can highlight maybe that Veeam is doing that's notable? What can you share? >> Yeah, I think you're right to call out that growth. We have a very broad and rich set of features and services, and we keep growing that. Almost every day there's a new release coming out, so it can be hard to keep up with. And Veeam has really been listening and innovating to support our joint customers. Like Danny called out a number of the ways in which they've expanded their support. Within Amazon S3, I want to call out their support for our infrequent access, infrequent access One-Zone, Glacier, and Glacier Deep Archive Storage Classes. And they also support other AWS storage services like AWS Outposts, AWS Storage Gateway, AWS Snowball Edge, and the Cold-themed storage offerings. So absolutely a broad set of support there. >> Yeah. There's those, winter is coming. Okay, great guys, we're going to leave it there. Danny, James, thanks so much for coming to theCUBE. Really good to see you guys. >> Good to see you as well, thank you. >> All right >> Thanks for having us. >> You're very welcome. You're watching theCUBE's coverage of 2021 AWS re:Invent, keep it right there for more action on theCUBE, your leader in hybrid tech event coverage, right back. (uplifting music)

>>Welcome back to the cubes coverage of AWS storage. They were here in downtown Seattle, crisp downtown Seattle. Winter is coming we're to talk about the snow unintended and also the ever expanding cloud, the cloud it's in a way it's like the universe, it's moving out to the edge and to the data center, which is literally another edge node. If you think about it, Mark Curry is here as the general manager of AWS gateway and Sid Roy is the GM of AWS snow family. Folks. Welcome. Good to see you. Thank you. So mark, talk about how you think about on-prem and hybrid. >>That's an excellent question, Dave. So I represent a group of services called storage gateway, and that's exactly what storage gateway does. Is it bridges your on-prem applications with the cloud? And the way we do that is we deliver it with really four services that we all call it. We call it gateway is the first one being volume gateway. And what volume gateway does is give you a way to connect your block storage on prem with the cloud for file shares for backup is what popular application there. And, uh, for applications that can tolerate some latency and that's a traditional service, then we, uh, came out with something called virtual tape gateway, which I'm personally really excited about because we all know about, you know, the big clunky tapes that have been around for 50 years, that you have to have trucks pick up and go store in a mountain and all that, um, with the virtual tape gateway, what we can do is we all have our gateways install either as a software package on-prem or as an appliance hardware appliance, but we put the tape gateway on prem and the customer is able to back up their tapes to us. >>And we look like a tape drive, virtual tape dry. So what we're doing is we're allowing the customer to basically digitize in the cloud, all of their legacy tapes. And this I think is a huge industry and we've got some great customers there. One would be formula one. Um, they've used virtual tape library. Our gateway to, um, basically could reduce the recovery time from five days down to one. So big impact there. Uh, the next gateway is our file gateway. And what I felt gateway does, again, sits on-prem either the software package or as a hardware appliance and fell gateway exposed as both an SMB share for Microsoft traffic and then an NFS share for your NFS traffic. And basically what we do as we front end S3 with this gateway. And so the gateway caches, so your active workflow gets really great performance, but you can move your inactive data to the cloud in S3, uh, where you've got durable storage. >>It's, you know, it's over multiple regions. You can run all of our analytics on that, on that data as well. Um, a good example, there would be modernize. A company worked on the COVID vaccine. They used storage gateway the file version to move their instrumentation and scientific data into the cloud, where once it's up in S3 week, you know, we've got a really robust set of tools, allow them to do analytics on it. And then finally, but not least our last announcement was something called FSX gateway and FSX is a chemical product. So we offer FSX as a windows file system or file share in the cloud. Um, the, the gateway basically acts as a cache to that. So a customer can put our FSX gateway on prem in lieu of like a server of some sort, and we'll cash all the traffic for that active workflow again, and then push their inactive data back to the FSX file system in the cloud. >>Cool. Lots of ways to get data to the cloud compatibility >>Issues. So, excellent. Thank you for that. Mark said, >>We know about snowball snowcones snowmobile all the snows, where does that fit >>In? Yeah. So let me, let me talk about the AWS edge. First, the broader edge spectrum of AWS spans many things from snow to outpost, to IOT, where there's a lot of data being created at the edge within this edge spectrum. There's the rugged mobile edge, which is where snow plays, right? So snow's purpose is really to capture transform and optionally move the data from rugged edge to AWS, right? And in our portfolio we have different devices. Uh, so let me start with the stone device. We announced last year in 2020, uh, snow cone is a small, uh, tissue box sized device. You know, it, it, it is portable. It's highly mobile, portable, rugged. It can, it can capture data from rugged sensory and end points and industrial equipment. And once we capture the data, you can process the data locally right there. And then if you have to send the data back to AWS, you can ship the device back or use data sync to transfer the data back at VWs. >>Now, if you have higher compute needs, where you have what we call the core edge, where it's not portable, but you need to kind of process there. We have the snowball edge device now that can be single known or multi-node snowball edge devices in groups of clusters for storage at storage edge compute. There, you can process like large scale data capture and transform it right there with, you know, machine learning or other data management and analytics right there for real time and AI based edge local decisions. So I'll give you a couple of examples in each category. So for snowcones, for example, we are partnering with Facebook to deliver, uh, private, LTE based, uh, networks for, uh, remote and rural areas where the connectivity is not here there. Right? So, so, uh, we are serving those communities in partnership with Facebook to deliver private LTE networks. The second example I'll give you is with the snowball edge device, that multiple nodes, we, us air force recently demonstrated, uh, that ABM a system, which is the advanced battle management system, where they can do like a lot of data capture and local simulation with AI and ML on containers, right on the snow cone, uh, on the snowball edge devices. So those are two examples of how we're doing, uh, edge local processing and capture. >>Well, I think, I think you guys got it right. You got a lot of ways to get data on the on-ramps into the cloud, but I I'm particularly struck by your edge. You know, we didn't get into the it strategy, but the idea of processing locally, bringing machine learning, uh, you know, cause the future we think anyway is AI and for instance, where the data lives, right. And yet, like you said, if you want to bring it back and bring it back and we have ways to get it back. Right, exactly. I'll give you guys the last word. >>Well, I, I would just say, you know, our FSX gateways of relatively new announcement, it's got some really cool applications for, um, high-performance Microsoft applications, but also for remote offices that want to share files. >>Great. Well guys, mark said, thanks so much for coming on the cube. Thank you for sharing the insights and the data and really appreciate it. Okay. Thank you for watching. This is the cubes coverage of AWS storage day. Keep it right there.

>>Welcome back to Dell Technology World. 2021. Del Tech World. The virtual edition. My name is Dave Volonte. We're gonna talk about the Edge. Very excited to invite Pierluigi Deli, who's the Vice President, Product management for the Edge portfolio. Adele and Gil Schwarzman, who is the Senior Vice President. Edge portfolio, also with Dell Technologies Gentlemen. Great to see you. Welcome to the cube. >>Thank you. Thank >>you. You see you, >>Yeah, great to see you guys to which we were face to face, but maybe maybe in 22 Gil, let's start with you. The edge is very exciting. Uh, it's, you know, not really defined, it's very fragmented, but it's there, you know, it's kind of, you know, it when you see it, what do you get excited about when you think about the edge? >>Yeah, I think uh there's two elements. The first one is that we all live at the edge. In other words, the areas we deal with our around us every day will show up um when we uh, you know, when we consume when we drive. So it's a, it's a very physical type of activity. We know it's there. What's really exciting motive to me is that you started with talking about fragmentation right on the bet. Um, it is a great opportunity for the technology is to add value um because it's so fragmented because it's so new because it has developed and evolved the way it is. We see an amazing opportunity for us to add much more value than we do today and solve problems that have yet to be solved in the industry. >>And it's an exciting, it's almost like an infinite playground for a technologist. You >>dave, I think that's exactly what we find out. The Edge is very exciting. There is a lot of motion, especially due to the pandemic and other things. Big factor that accelerate innovation at the edge but this is an inorganic acceleration and what it kills for one of the most of our customer is also confusion, right? They need to apply multiple solution but not very organized. So you try to solve the outcome like having the right production on the, on your line because demand is surging but you don't have an organic things to do that and solve the problem. So you see a lot of silence coming in for each one of the solution and that's what Gil was referring. That's a great opportunity for us as dealt with the breath of the portfolio we have and what our team that is a new team is focusing doing is to bring that idea to be able to consolidate multiple things at the edge and process things at the edge. >>We did a an event cube, had an event called the Cuban cloud and Q one and we had john Rosen and the title of segment was something like gaining the technology edge And we were kind of freaking out on, on the tech at the edge. Uh it might take away there was trying to like what is the edge? It's like, well it's the place where it makes most sense to process the data and so that brings up a lot of challenges. There are technical challenges and there are business challenges. I wonder if we could sort of dig into those a little bit. How do you guys look at that? Maybe gil you want to start maybe on the business side and then we can dig a short, right >>the way things evolved if you think about it, um, at the edge of very vertical lesson because of that they're very use case driven And so in every industry possible you start with some business person making a decision whether they have a need or they want to grow their business. And so for example they would buy an applying to do fraud protection in retail or detection retail or they will apply an application to medical robotics in the factory. And it would come with its own gateway in plant compute in a cloud portal and then you do it again and again and again every time you have a business opportunity all of the sudden you have this proliferation of I. T. Type equipment at the end where it's it's the worst place to have it really because you don't have the right I. T. Resources and you are um in the need to protect it in a much more um in a different way than you do in a data center. And so all of that brings to bring us to a point that you know we see an opportunity to simplify. Um And so not only simplification and this is you know simplification or simplicity is the most important driver for any I. T. Purchase. Um Things that are simple are the easiest that the most economical to operate the next demand that we see from a customary security because things are at the they have a much more um you know extended attack surface um they need to be connected to networks, they need to be connected without I. T. Staff. So if you can simplify insecure you can really unlock amazing value by processing data where closely to where it's created without it. You know we were seeing this opportunity as businesses but we can we get to it because there are so those two hurdles in front of us. >>So when you say thank you for that bill, when you think about, when you hear you hear a lot about AI influencing at the edge and and if you think about AI today much of the work is modeling, it's done in the cloud, but you're not going to be doing A i influencing in real time in the cloud, you know, take the autonomous vehicle example, so that brings some some technical challenges. Um, there's obviously data challenges. I'm curious as to how you think about that. I mean we always talk about how much data is going to be persisted, I think Tesla persists like five minutes of data, right? But some of it is gonna go back, that's true, but a lot of it is going to be processed real time and that's just really different than the way we typically think about. Yeah, >>absolutely. So at the Edge, especially in manufacturing, we see right now or in a uh, another use case, it's very important to get the outcome very quickly. Now. You don't use that a deep learning model for that. You need to just understand, for example, in a computer vision use case where you take the image of your production line, you actually to your point dave you not keep those image when you keep the image where you have the defect. But you need to process that. Ai Ml needs to be intelligent enough to understand that you have a defect and send that image them to the club. So the search of the data at the edge is a very important factor and why you need to process data, the Edge because your point, you can't wait to send to the cloud and I'm waiting right? Um, Tesla is a clear example of that all the autonomous car where you need to react instantaneously to change. But in manufacturing for example that is our focus for now is for example the robots that if you need to optimize the robot, you need to have a immediate understanding of where the pieces are and when they need to put in the tolerance need to be act immediately. Otherwise you come out with the thousands of pieces that they are not in the right tolerance. So at the end of the day, what we see is not only the search of the need of processing ai ml to the edge but also the need of a new type of compute at the edge. So in the past was just Gateway and you get the gate when you send the data to the cloud. Now it's a form of a new computer that come as also GPU capability and other things to process the data. So very important. And I think the Dell especially we are very focused on that because is uh is really where the customer need to extract the value. >>Thank you. And Gil I want to get into the unique value proposition to tell what makes you distinct. And it's uh I infer from your comments, your strategy you said is to simplify and so I see two vectors. There. One is to simplify at the edge. The other is to where we're needed, connect that edge, whether it's on prem public cloud across cloud, that kind of simplification layer that abstracts the complex, the underlying complexity. Uh Maybe you could talk about your strategy and what makes you guys different. >>Sure. Um We've been talking to a, well we always talk to our customers and we've been doing business at the edge for many many years. Um You know let's call it coincidental were very large company we have reached, we serve our customers so when they decide to buy something for their you know environment, they come to us as well as other vendors and we win a percentage of the time based on our market share. Um But when we decided to take another look at how can we be even more relevant? We started talking to a lot of them great depth. And what would we do we discovered was the problem I talked about before, the problem of complexity, the problem of security and the problem of you know choice. And so our focus is to do what we do best. We at the end of the day we're an I. T. Company. Um and our our customers for the most part our I. T. People and we see them dragged more and more into edge projects because customers need to connect edge to the network and they need to security and that's how it starts. And so those worlds of I. T. And OTR coming together and their coming together applying best practices which is exactly what we know how to do. And so because of that we think that they need to think about architecture versus unique silent solutions architecture can support multiple use cases that can grow with time, consolidate more and more use cases as they grow. Simplify what they do by applying you know tried and true or tried and true best practices in a secure manner. So the deal approach would be doing that taking a more architectural approach to the adverse as a use case and then just like you predicted um meet the customers where they are from an application stand book. And so we we know that a lot of applications are growing and development on a hyper scale or public clouds. We would like to connect to those. We would like to allow them to keep working as they have except when they run into the edge. Think about environments that could consolidate multiple workloads and not solve it for each one at the same time. And so that would be our overall approach. That's what we're working on. >>Yeah. Okay. So that horizontal layer, if you will uh to to to serve many many use cases, not just you're not gonna go a mile deep into one and be the expert at some narrow use case. You want to be that horizontal platform. But at the same time, look, I wonder does does that call for more program ability as we over time of the of the products to to really allow people to kind of design in that flexibility if you will build my own. Uh is that something that we can expect? >>Yeah, absolutely. So uh we spoke a little bit about this before the interview and the things that is very important is compose ability starting from a very small from factor to the cluster and then expand to the cloud is a fundamental things and a trend that we see. The fact that you can compose the infrastructure um starting from a small gateway that is changing in this market, right up to the cloud and be able to use the same layer that allow you to run the same application is the fundamental things and we are working on that. Um we are working on this vision and our strategy is really to be able to be transparent but provide the right building block to do all the use case that they are required where the data are. So we again, not only meeting the customer but meeting where the data are, what the customer wants out of those data. So that's a fundamental things. And you know, we we have project Apex. So obviously we are plugging into the project apex from an edge point of view, will allow the customer to have this unique experience to go in Apex and also deploy the edge infrastructure that is needed. So that's that's we started right now with that. So we will touch later, but that's the first building block of that journey. >>Actually, let's touch now you've got some news around Apex and and and and talking what are you announcing? So >>we are very exciting because as I said, our team is, it's pretty new and um, it's a very important investment that Dell makes uh not only in us as a team but as a motion. Um, so we are announcing a reference architecture with PTC. PTC is the one of the biggest company for actually based here in boston uh for manufacturing and reference architecture will be run on based on apex private cloud so the customer can go to the portal, order, order apex private cloud and deploy deploy PTC on top of that. So, very important things is that the first step in this journey and but it's an important, very, very important steps. So we want to thank you also PTC to allow us to work with them. Um, we have other stuff as well that we are announcing. Um, I don't know if you are familiar but we have a very unique streaming data platform, um, streaming data platform that can stream multiple data collected from Gateway from every place. And uh it's a need obviously when you need to process data in real time, very important to have a streaming, what we're doing with the new streaming data platform approach is the ability to deploy single note. So it can be very appealing for the edge and up to free notes and last but not least gil if you want to speak about our other partnership is very important. >>Sure. Um once we started looking more in depth into manufacturing, we discover that this market is today served by combinations of um oT vendors, people who make equipment? S eyes, people who consult on integration and um and you know, a lot of SVS that make up this ecosystem and people like ourselves. And so one of the things that we decided to do is partner with accenture, accenture Industry X practice to bring our joint value to customers. We started by investing in in a five G lab. They have four industry act. So you know the usage of five G. Manufacturing industry and we will still we will expand that and work on that as a as a joint offer for our joint customers going forward. So we're really excited about this because we feel that consolidation needs to happen not only technology but also in the partnerships, we need to partner if you want to bring true value to our customers and that's the first step, >>awesome. That's great. So a couple of comments on that. So it's funny, we did the live work show in the cube a couple years ago. PTC is a big, big event and it was like it was the edge and I remember looking around saying where's all the vendors? So that's great to see you guys leaning in like that parallel to the streaming platform. Tell me more about that. What's the tech behind it? >>Uh So the streaming data platform is a project that we start a couple of years ago is actually uh start from open source Provida. Um it's uh it's a very interesting technology where you can stream multiple data, it is not a traditional storage, ah use a technology that can ah really collect thousands of different streams and that's very important when you need to mind the data, bring the data um in the structure data in a inefficient that you, you can process them at the real time. It's very important. So um there are very cool use case of that. But now that we look at the edge, this is make more and more tangible sense because we have a lot of partners that they're working with us, especially to extend when you have all this sensor, you bring the data to the gateways and from the gateways then you can use data streaming platform to collect all these dreams and then you can easily process them. So it's a very fundamental technology, we are very proud of that. Um as I said, our enterprise version uh is getting more and more and now we can land this on different architecture, so it is, it can be backed up by an Iceland. Uh it can be also on different storage type now and as I said, we're looking now to bring from a what was a data center kind of structure down to the edge because now we can put a single node up to three notes, >>it makes a lot of sense. Is this like a Kafka based thing or open source or is it something you guys built or a combination? >>It's a combination. We actually project. The project is an open source project, but we did that, we start this many years ago and um he works with Kafka, but he's not Kafka. So it's, it's a he has plugging that can work with Kafka and all the other things and, and it's very easy to deploy. So it's a very, very, very important. And the other things is the scalability of this platform. >>I mean, it sounds like the kind of thing you had in the labs and you said, OK, this is going to be important. That boom all of a sudden the market comes to you as if you pop it right in. And then of course, the accenture of relationship deep, deep industry expertise, so that makes a lot of sense. 55 Gs happening a different world the next 10 years in the last 10 years isn't it? What is it about manufacturing? Why why did you start there? >>I can take this. Um We looked at where the opportunity was from two perspectives. One is where the opportunity, what the opportunities to sell, even the other one obviously comes with it because there is an opportunity to have and manufacturing today at the edges about 30 of the opportunity in sales according to NBC but more so it's been around for the longer time and so they it's very it's maturing um it's the most demanding. Um and you know, it's got very long horizons of investment and what we did was we figured that if we can solve problems for industry we can then extend that and solving for everyone years. Because this would be the toughest one to solve and we like challenge. And so we decided to focus and go deep. You said it before? Well, our approach is definitely horizontal approach. We cannot take a horizontal approach without vertical izing and understand specific needs. So nobody can avoid doing both at the same time. You need to understand. But you also want to solve it in a way that doesn't proliferate the silos. So that's our role. We will understand what we will make it more generic so other people can never get later on >>and David, if I cannot. Uh I think the manufacturing is also very exciting for us as a technologist, right? Uh and uh Dell technology as in the name the technology. So it's very exciting because if I look at manufacturing, we we are really in the middle of a industrial transformation. I mean it's a new era. Um If you think about um nobody care in the past to connect their machinery with that the F. P. L. C. To the network. All of this is changing because the life that where we live right now with the pandemic with the remote working with the fact that you need to have a much more control and be able to have predictive matters. So you're not stopping your manufacturing is pushing the entire manufacturing instrument industry to connect this machine and with the connectivity of this machinery you get a lot of data. You get also a lot of challenge. For example security. So now that's the place where connectivity brings the I. T. Aspect in and U. T. Guys now they're starting to speak with because now it's a more complex things right? It's not any more computerized competitor eyes only to one machinery specific is the entire floor. So it's a very interesting dynamics >>is the connection between that programmable logic controller and the Dell solution is you mentioned to secure better security and I presume it's also to connect back to whatever the core or the cloud etcetera. Is it also to do you know, something locally? Does it improve? Is their value add that you can provide locally? And what is that value add? >>Absolutely. So the value, as I said, um if you think right in the past right, you have a machine that uh, probably stay in the manufacturing for 2025 years, then you have an artwork attached to that machine that it is the P. L. C. About 11 years. The guy that he knows better about that machine is actually not the software component on. But he's the guy that has been working on that machine for 15 years now. How you translate that knowledge To a learning algorithm that actually can do that 4000 of machine. And and that's really the key right. You need to centralize information, process those information but not in the cloud, not in the central data center, but on the manufacturing floor. And you need to have a way to represent these things in a very simple way. So the plant manager can take action or the or the guy that is responsible for the entire line can take action immediately. And that's where the changes is not anymore to is trying to extend that knowledge to multiple machine multiple floor and try to get this change immediately. So that's really >>so the PLC doesn't become a general purpose computer or even necessarily the Uber computer. It connects to that capability because that enables data sharing across clouds and that's >>enabled the entire things. You know, you you can't do a model just with one source. You need to have multiple sources. Um, and also think about the manufacturing is changing not only for the machinery, but people that they build new manufacturing right? They need to be smart building. They need to have a technology for being more green solar energy consumption. So the manufacturing itself is mean five or six different things that you need to solve. It's not just the machine. So this idea of the silence environment is started to collapse in one and that's why it's important for us to start from a vertical, but also in the manufacturing, you already see this will expand to multiple things. Also like smart building another thing because they need it. >>Yeah. The red guilt to your point manufacturers like the Big Apple. If you can make it there, you can make it anywhere and you've got adjacent seas, you can, you know, you can take the learnings from manufacturing and apply them to those adjacent industries. Uh, give us the last word. >>Um, look, usually when we talk at the technologies world, we talked to an I. D. Audience and we were, we're thinking this year that the way to talk about edge, at least with the people who traditionally buy from us is exposed them to the fact that they are more and more are going to be responsible for projects. And so our advice would be our hope that they would partner with us to think ahead. Just like they do with data center with their cloud strategy, think ahead as they think about their edge and try to set up some architectural guidelines. So when they do get the request, they're ready for it and think about what they think about the best practices that they applied, all of that is coming to them. They need to be prepared as well. And so we would like to partner with all of our customers to make them ready and obviously help them simplify secure, consolidate as they grow. >>Well guys, thank you, I learned a lot today. I you made a lot of progress. You know, this is the hallmark of Dell, right? It's a very high, let me make sure I get this right, very high due to say ratio right. You guys talked about doing this, you know, a couple a couple of years ago, uh, and you've made a lot of progress and I really appreciate you coming in the cube to explain the strategy. It makes a lot of sense. And so congratulations and uh, good luck in the future. >>Thank you. >>All right. And thank you for watching everybody. This is Dave Volonte for the cubes, ongoing coverage of Del Tech World 2021. The virtual edition. Keep it right there, right back, >>mm.

>>all right, We're five minutes after the hour. That's all aboard. Who's coming aboard? Welcome everyone to the tutorial track for our launchpad of them. So for the next couple of hours, we've got a SYRIZA videos and experts on hand to answer questions about our new product, Doctor Enterprise Container Cloud. Before we jump into the videos and the technology, I just want to introduce myself and my other emcee for the session. I'm Bill Milks. I run curriculum development for Mirant us on. And >>I'm Bruce Basil Matthews. I'm the Western regional Solutions architect for Moran Tissue esa and welcome to everyone to this lovely launchpad oven event. >>We're lucky to have you with us proof. At least somebody on the call knows something about your enterprise Computer club. Um, speaking of people that know about Dr Enterprise Container Cloud, make sure that you've got a window open to the chat for this session. We've got a number of our engineers available and on hand to answer your questions live as we go through these videos and disgusting problem. So that's us, I guess, for Dr Enterprise Container Cloud, this is Mirant asses brand new product for bootstrapping Doctor Enterprise Kubernetes clusters at scale Anything. The airport Abu's? >>No, just that I think that we're trying Thio. Uh, let's see. Hold on. I think that we're trying Teoh give you a foundation against which to give this stuff a go yourself. And that's really the key to this thing is to provide some, you know, many training and education in a very condensed period. So, >>yeah, that's exactly what you're going to see. The SYRIZA videos we have today. We're going to focus on your first steps with Dr Enterprise Container Cloud from installing it to bootstrapping your regional child clusters so that by the end of the tutorial content today, you're gonna be prepared to spin up your first documentary prize clusters using documented prize container class. So just a little bit of logistics for the session. We're going to run through these tutorials twice. We're gonna do one run through starting seven minutes ago up until I guess it will be ten fifteen Pacific time. Then we're gonna run through the whole thing again. So if you've got other colleagues that weren't able to join right at the top of the hour and would like to jump in from the beginning, ten. Fifteen Pacific time. We're gonna do the whole thing over again. So if you want to see the videos twice, you got public friends and colleagues that, you know you wanna pull in for a second chance to see this stuff, we're gonna do it all. All twice. Yeah, this session. Any any logistics I should add, Bruce that No, >>I think that's that's pretty much what we had to nail down here. But let's zoom dash into those, uh, feature films. >>Let's do Edmonds. And like I said, don't be shy. Feel free to ask questions in the chat or engineers and boosting myself are standing by to answer your questions. So let me just tee up the first video here and walk their cost. Yeah. Mhm. Yes. Sorry. And here we go. So our first video here is gonna be about installing the Doctor Enterprise Container Club Management cluster. So I like to think of the management cluster as like your mothership, right? This is what you're gonna use to deploy all those little child clusters that you're gonna use is like, Come on it as clusters downstream. So the management costs was always our first step. Let's jump in there >>now. We have to give this brief little pause >>with no good day video. Focus for this demo will be the initial bootstrap of the management cluster in the first regional clusters to support AWS deployments. The management cluster provides the core functionality, including identity management, authentication, infantry release version. The regional cluster provides the specific architecture provided in this case, eight of us and the Elsie um, components on the UCP Cluster Child cluster is the cluster or clusters being deployed and managed. The deployment is broken up into five phases. The first phase is preparing a big strap note on this dependencies on handling with download of the bridge struck tools. The second phase is obtaining America's license file. Third phase. Prepare the AWS credentials instead of the adduce environment. The fourth configuring the deployment, defining things like the machine types on the fifth phase. Run the bootstrap script and wait for the deployment to complete. Okay, so here we're sitting up the strap node, just checking that it's clean and clear and ready to go there. No credentials already set up on that particular note. Now we're just checking through AWS to make sure that the account we want to use we have the correct credentials on the correct roles set up and validating that there are no instances currently set up in easy to instance, not completely necessary, but just helps keep things clean and tidy when I am perspective. Right. So next step, we're just going to check that we can, from the bootstrap note, reach more antis, get to the repositories where the various components of the system are available. They're good. No areas here. Yeah, right now we're going to start sitting at the bootstrap note itself. So we're downloading the cars release, get get cars, script, and then next, we're going to run it. I'm in. Deploy it. Changing into that big struck folder. Just making see what's there. Right now we have no license file, so we're gonna get the license filed. Oh, okay. Get the license file through the more antis downloads site, signing up here, downloading that license file and putting it into the Carisbrook struck folder. Okay, Once we've done that, we can now go ahead with the rest of the deployment. See that the follow is there. Uh, huh? That's again checking that we can now reach E C two, which is extremely important for the deployment. Just validation steps as we move through the process. All right, The next big step is valid in all of our AWS credentials. So the first thing is, we need those route credentials which we're going to export on the command line. This is to create the necessary bootstrap user on AWS credentials for the completion off the deployment we're now running an AWS policy create. So it is part of that is creating our Food trucks script, creating the mystery policy files on top of AWS, Just generally preparing the environment using a cloud formation script you'll see in a second will give a new policy confirmations just waiting for it to complete. Yeah, and there is done. It's gonna have a look at the AWS console. You can see that we're creative completed. Now we can go and get the credentials that we created Today I am console. Go to that new user that's being created. We'll go to the section on security credentials and creating new keys. Download that information media Access key I D and the secret access key. We went, Yeah, usually then exported on the command line. Okay. Couple of things to Notre. Ensure that you're using the correct AWS region on ensure that in the conflict file you put the correct Am I in for that region? I'm sure you have it together in a second. Yes. Okay, that's the key. Secret X key. Right on. Let's kick it off. Yeah, So this process takes between thirty and forty five minutes. Handles all the AWS dependencies for you, and as we go through, the process will show you how you can track it. Andi will start to see things like the running instances being created on the west side. The first phase off this whole process happening in the background is the creation of a local kind based bootstrapped cluster on the bootstrap node that clusters then used to deploy and manage all the various instances and configurations within AWS. At the end of the process, that cluster is copied into the new cluster on AWS and then shut down that local cluster essentially moving itself over. Okay. Local clusters boat just waiting for the various objects to get ready. Standard communities objects here Okay, so we speed up this process a little bit just for demonstration purposes. Yeah. There we go. So first note is being built the best in host. Just jump box that will allow us access to the entire environment. Yeah, In a few seconds, we'll see those instances here in the US console on the right. Um, the failures that you're seeing around failed to get the I. P for Bastian is just the weight state while we wait for a W s to create the instance. Okay. Yes. Here, beauty there. Okay. Mhm. Okay. Yeah, yeah. Okay. On there. We got question. Host has been built on three instances for the management clusters have now been created. We're going through the process of preparing. Those nodes were now copying everything over. See that? The scaling up of controllers in the big Strap cluster? It's indicating that we're starting all of the controllers in the new question. Almost there. Yeah. Yeah, just waiting for key. Clark. Uh huh. Start to finish up. Yeah. No. What? Now we're shutting down control this on the local bootstrap node on preparing our I. D. C. Configuration. Fourth indication, soon as this is completed. Last phase will be to deploy stack light into the new cluster the last time Monitoring tool set way Go stack like to plan It has started. Mhm coming to the end of the deployment Mountain. Yeah, America. Final phase of the deployment. Onda, We are done. Okay, You'll see. At the end they're providing us the details of you. I log in so there's a keeper clogging. You can modify that initial default password is part of the configuration set up with one documentation way. Go Councils up way can log in. Yeah, yeah, thank you very much for watching. >>Excellent. So in that video are wonderful field CTO Shauna Vera bootstrapped up management costume for Dr Enterprise Container Cloud Bruce, where exactly does that leave us? So now we've got this management costume installed like what's next? >>So primarily the foundation for being able to deploy either regional clusters that will then allow you to support child clusters. Uh, comes into play the next piece of what we're going to show, I think with Sean O'Mara doing this is the child cluster capability, which allows you to then deploy your application services on the local cluster. That's being managed by the ah ah management cluster that we just created with the bootstrap. >>Right? So this cluster isn't yet for workloads. This is just for bootstrapping up the downstream clusters. Those or what we're gonna use for workings. >>Exactly. Yeah. And I just wanted to point out, since Sean O'Mara isn't around, toe, actually answer questions. I could listen to that guy. Read the phone book, and it would be interesting, but anyway, you can tell him I said that >>he's watching right now, Crusoe. Good. Um, cool. So and just to make sure I understood what Sean was describing their that bootstrap er knows that you, like, ran document fresh pretender Cloud from to begin with. That's actually creating a kind kubernetes deployment kubernetes and Docker deployment locally. That then hits the AWS a p i in this example that make those e c two instances, and it makes like a three manager kubernetes cluster there, and then it, like, copies itself over toe those communities managers. >>Yeah, and and that's sort of where the transition happens. You can actually see it. The output that when it says I'm pivoting, I'm pivoting from my local kind deployment of cluster AP, I toothy, uh, cluster, that's that's being created inside of AWS or, quite frankly, inside of open stack or inside of bare metal or inside of it. The targeting is, uh, abstracted. Yeah, but >>those air three environments that we're looking at right now, right? Us bare metal in open staff environments. So does that kind cluster on the bootstrap er go away afterwards. You don't need that afterwards. Yeah, that is just temporary. To get things bootstrapped, then you manage things from management cluster on aws in this example? >>Yeah. Yeah. The seed, uh, cloud that post the bootstrap is not required anymore. And there's no, uh, interplay between them after that. So that there's no dependencies on any of the clouds that get created thereafter. >>Yeah, that actually reminds me of how we bootstrapped doctor enterprise back in the day, be a temporary container that would bootstrap all the other containers. Go away. It's, uh, so sort of a similar, similar temporary transient bootstrapping model. Cool. Excellent. What will convict there? It looked like there wasn't a ton, right? It looked like you had to, like, set up some AWS parameters like credentials and region and stuff like that. But other than that, that looked like heavily script herbal like there wasn't a ton of point and click there. >>Yeah, very much so. It's pretty straightforward from a bootstrapping standpoint, The config file that that's generated the template is fairly straightforward and targeted towards of a small medium or large, um, deployment. And by editing that single file and then gathering license file and all of the things that Sean went through, um, that that it makes it fairly easy to script >>this. And if I understood correctly as well that three manager footprint for your management cluster, that's the minimum, right. We always insist on high availability for this management cluster because boy do not wanna see oh, >>right, right. And you know, there's all kinds of persistent data that needs to be available, regardless of whether one of the notes goes down or not. So we're taking care of all of that for you behind the scenes without you having toe worry about it as a developer. >>No, I think there's that's a theme that I think will come back to throughout the rest of this tutorial session today is there's a lot of there's a lot of expertise baked him to Dr Enterprise Container Cloud in terms of implementing best practices for you like the defaulter, just the best practices of how you should be managing these clusters, Miss Seymour. Examples of that is the day goes on. Any interesting questions you want to call out from the chap who's >>well, there was. Yeah, yeah, there was one that we had responded to earlier about the fact that it's a management cluster that then conduce oh, either the the regional cluster or a local child molester. The child clusters, in each case host the application services, >>right? So at this point, we've got, in some sense, like the simplest architectures for our documentary prize Container Cloud. We've got the management cluster, and we're gonna go straight with child cluster. In the next video, there's a more sophisticated architecture, which will also proper today that inserts another layer between those two regional clusters. If you need to manage regions like across a BS, reads across with these documents anything, >>yeah, that that local support for the child cluster makes it a lot easier for you to manage the individual clusters themselves and to take advantage of our observation. I'll support systems a stack light and things like that for each one of clusters locally, as opposed to having to centralize thumb >>eso. It's a couple of good questions. In the chat here, someone was asking for the instructions to do this themselves. I strongly encourage you to do so. That should be in the docks, which I think Dale helpfully thank you. Dale provided links for that's all publicly available right now. So just head on in, head on into the docks like the Dale provided here. You can follow this example yourself. All you need is a Mirante license for this and your AWS credentials. There was a question from many a hear about deploying this toe azure. Not at G. Not at this time. >>Yeah, although that is coming. That's going to be in a very near term release. >>I didn't wanna make promises for product, but I'm not too surprised that she's gonna be targeted. Very bracing. Cool. Okay. Any other thoughts on this one does. >>No, just that the fact that we're running through these individual pieces of the steps Well, I'm sure help you folks. If you go to the link that, uh, the gentleman had put into the chat, um, giving you the step by staff. Um, it makes it fairly straightforward to try this yourselves. >>E strongly encourage that, right? That's when you really start to internalize this stuff. OK, but before we move on to the next video, let's just make sure everyone has a clear picture in your mind of, like, where we are in the life cycle here creating this management cluster. Just stop me if I'm wrong. Who's creating this management cluster is like, you do that once, right? That's when your first setting up your doctor enterprise container cloud environment of system. What we're going to start seeing next is creating child clusters and this is what you're gonna be doing over and over and over again. When you need to create a cluster for this Deb team or, you know, this other team river it is that needs commodity. Doctor Enterprise clusters create these easy on half will. So this was once to set up Dr Enterprise Container Cloud Child clusters, which we're going to see next. We're gonna do over and over and over again. So let's go to that video and see just how straightforward it is to spin up a doctor enterprise cluster for work clothes as a child cluster. Undocumented brands contain >>Hello. In this demo, we will cover the deployment experience of creating a new child cluster, the scaling of the cluster and how to update the cluster. When a new version is available, we begin the process by logging onto the you I as a normal user called Mary. Let's go through the navigation of the U I so you can switch. Project Mary only has access to development. Get a list of the available projects that you have access to. What clusters have been deployed at the moment there. Nan Yes, this H Keys Associate ID for Mary into her team on the cloud credentials that allow you to create access the various clouds that you can deploy clusters to finally different releases that are available to us. We can switch from dark mode to light mode, depending on your preferences, Right? Let's now set up semester search keys for Mary so she can access the notes and machines again. Very simply, had Mississippi key give it a name, we copy and paste our public key into the upload key block. Or we can upload the key if we have the file available on our local machine. A simple process. So to create a new cluster, we define the cluster ad management nodes and add worker nodes to the cluster. Yeah, again, very simply, you go to the clusters tab. We hit the create cluster button. Give the cluster name. Yeah, Andi, select the provider. We only have access to AWS in this particular deployment, so we'll stick to AWS. What's like the region in this case? US West one release version five point seven is the current release Onda Attach. Mary's Key is necessary Key. We can then check the rest of the settings, confirming the provider Any kubernetes c r D r I p address information. We can change this. Should we wish to? We'll leave it default for now on. Then what components? A stack light I would like to deploy into my Custer. For this. I'm enabling stack light on logging on Aiken. Sit up the retention sizes Attention times on. Even at this stage, at any customer alerts for the watchdogs. E consider email alerting which I will need my smart host details and authentication details. Andi Slack Alerts. Now I'm defining the cluster. All that's happened is the cluster's been defined. I now need to add machines to that cluster. I'll begin by clicking the create machine button within the cluster definition. Oh, select manager, Select the number of machines. Three is the minimum. Select the instant size that I'd like to use from AWS and very importantly, ensure correct. Use the correct Am I for the region. I commend side on the route device size. There we go, my three machines obviously creating. I now need to add some workers to this custom. So I go through the same process this time once again, just selecting worker. I'll just add to once again, the AM is extremely important. Will fail if we don't pick the right, Am I for a boon to machine in this case and the deployment has started. We can go and check on the bold status are going back to the clusters screen on clicking on the little three dots on the right. We get the cluster info and the events, so the basic cluster info you'll see pending their listen cluster is still in the process of being built. We kick on, the events will get a list of actions that have been completed This part of the set up of the cluster. So you can see here we've created the VPC. We've created the sub nets on We've created the Internet gateway. It's unnecessary made of us and we have no warnings of the stage. Yeah, this will then run for a while. We have one minute past waken click through. We can check the status of the machine bulls as individuals so we can check the machine info, details of the machines that we've assigned, right? Mhm Onda. See any events pertaining to the machine areas like this one on normal? Yeah. Just watch asked. The community's components are waiting for the machines to start. Go back to Custer's. Okay, right. Because we're moving ahead now. We can see we have it in progress. Five minutes in new Matt Gateway on the stage. The machines have been built on assigned. I pick up the U. S. Thank you. Yeah. There we go. Machine has been created. See the event detail and the AWS. I'd for that machine. Mhm. No speeding things up a little bit. This whole process and to end takes about fifteen minutes. Run the clock forward, you'll notice is the machines continue to bold the in progress. We'll go from in progress to ready. A soon as we got ready on all three machines, the managers on both workers way could go on and we could see that now we reached the point where the cluster itself is being configured. Mhm, mhm. And then we go. Cluster has been deployed. So once the classes deployed, we can now never get around our environment. Okay, Are cooking into configure cluster We could modify their cluster. We could get the end points for alert alert manager on See here The griffon occupying and Prometheus are still building in the background but the cluster is available on you would be able to put workloads on it the stretch to download the cube conflict so that I can put workloads on it. It's again three little dots in the right for that particular cluster. If the download cube conflict give it my password, I now have the Q conflict file necessary so that I can access that cluster Mhm all right Now that the build is fully completed, we can check out cluster info on. We can see that Allow the satellite components have been built. All the storage is there, and we have access to the CPU. I So if we click into the cluster, we can access the UCP dashboard, right? Shit. Click the signing with Detroit button to use the SSO on. We give Mary's possible to use the name once again. Thing is, an unlicensed cluster way could license at this point. Or just skip it on. There. We have the UCP dashboard. You can see that has been up for a little while. We have some data on the dashboard going back to the console. We can now go to the griffon, a data just being automatically pre configured for us. We can switch and utilized a number of different dashboards that have already been instrumented within the cluster. So, for example, communities cluster information, the name spaces, deployments, nodes. Mhm. So we look at nodes. If we could get a view of the resource is utilization of Mrs Custer is very little running in it. Yeah. General dashboard of Cuba navies cluster one of this is configurable. You can modify these for your own needs, or add your own dashboards on de scoped to the cluster. So it is available to all users who have access to this specific cluster, all right to scale the cluster on to add a notice. A simple is the process of adding a mode to the cluster, assuming we've done that in the first place. So we go to the cluster, go into the details for the cluster we select, create machine. Once again, we need to be ensure that we put the correct am I in and any other functions we like. You can create different sized machines so it could be a larger node. Could be bigger disks and you'll see that worker has been added from the provisioning state on shortly. We will see the detail off that worker as a complete to remove a note from a cluster. Once again, we're going to the cluster. We select the node would like to remove. Okay, I just hit delete On that note. Worker nodes will be removed from the cluster using according and drawing method to ensure that your workouts are not affected. Updating a cluster. When an update is available in the menu for that particular cluster, the update button will become available. And it's a simple as clicking the button, validating which release you would like to update to. In this case, the next available releases five point seven point one. Here I'm kicking the update by in the background We will coordinate. Drain each node slowly go through the process of updating it. Andi update will complete depending on what the update is as quickly as possible. Girl, we go. The notes being rebuilt in this case impacted the manager node. So one of the manager nodes is in the process of being rebuilt. In fact, to in this case, one has completed already on In a few minutes we'll see that there are great has been completed. There we go. Great. Done. Yeah. If you work loads of both using proper cloud native community standards, there will be no impact. >>Excellent. So at this point, we've now got a cluster ready to start taking our communities of workloads. He started playing or APs to that costume. So watching that video, the thing that jumped out to me at first Waas like the inputs that go into defining this workload cost of it. All right, so we have to make sure we were using on appropriate am I for that kind of defines the substrate about what we're gonna be deploying our cluster on top of. But there's very little requirements. A so far as I could tell on top of that, am I? Because Docker enterprise Container Cloud is gonna bootstrap all the components that you need. That s all we have is kind of kind of really simple bunch box that we were deploying these things on top of so one thing that didn't get dug into too much in the video. But it's just sort of implied. Bruce, maybe you can comment on this is that release that Shawn had to choose for his, uh, for his cluster in creating it. And that release was also the thing we had to touch. Wanted to upgrade part cluster. So you have really sharp eyes. You could see at the end there that when you're doing the release upgrade enlisted out a stack of components docker, engine, kubernetes, calico, aled, different bits and pieces that go into, uh, go into one of these commodity clusters that deploy. And so, as far as I can tell in that case, that's what we mean by a release. In this sense, right? It's the validated stack off container ization and orchestration components that you know we've tested out and make sure it works well, introduction environments. >>Yeah, and and And that's really the focus of our effort is to ensure that any CVS in any of the stack are taken care of that there is a fixes air documented and up streamed to the open stack community source community, um, and and that, you know, then we test for the scaling ability and the reliability in high availability configuration for the clusters themselves. The hosts of your containers. Right. And I think one of the key, uh, you know, benefits that we provide is that ability to let you know, online, high. We've got an update for you, and it's fixes something that maybe you had asked us to fix. Uh, that all comes to you online as your managing your clusters, so you don't have to think about it. It just comes as part of the product. >>You just have to click on Yes. Please give me that update. Uh, not just the individual components, but again. It's that it's that validated stack, right? Not just, you know, component X, y and Z work. But they all work together effectively Scalable security, reliably cool. Um, yeah. So at that point, once we started creating that workload child cluster, of course, we bootstrapped good old universal control plane. Doctor Enterprise. On top of that, Sean had the classic comment there, you know? Yeah. Yeah. You'll see a little warnings and errors or whatever. When you're setting up, UCP don't handle, right, Just let it do its job, and it will converge all its components, you know, after just just a minute or two. But we saw in that video, we sped things up a little bit there just we didn't wait for, you know, progress fighters to complete. But really, in real life, that whole process is that anything so spend up one of those one of those fosters so quite quite quick. >>Yeah, and and I think the the thoroughness with which it goes through its process and re tries and re tries, uh, as you know, and it was evident when we went through the initial ah video of the bootstrapping as well that the processes themselves are self healing, as they are going through. So they will try and retry and wait for the event to complete properly on. And once it's completed properly, then it will go to the next step. >>Absolutely. And the worst thing you could do is panic at the first warning and start tearing things that don't don't do that. Just don't let it let it heal. Let take care of itself. And that's the beauty of these manage solutions is that they bake in a lot of subject matter expertise, right? The decisions that are getting made by those containers is they're bootstrapping themselves, reflect the expertise of the Mirant ISS crew that has been developing this content in these two is free for years and years now, over recognizing humanities. One cool thing there that I really appreciate it actually that it adds on top of Dr Enterprise is that automatic griffon a deployment as well. So, Dr Enterprises, I think everyone knows has had, like, some very high level of statistics baked into its dashboard for years and years now. But you know our customers always wanted a double click on that right to be able to go a little bit deeper. And Griffon are really addresses that it's built in dashboards. That's what's really nice to see. >>Yeah, uh, and all of the alerts and, uh, data are actually captured in a Prometheus database underlying that you have access to so that you are allowed to add new alerts that then go out to touch slack and say hi, You need to watch your disk space on this machine or those kinds of things. Um, and and this is especially helpful for folks who you know, want to manage the application service layer but don't necessarily want to manage the operations side of the house. So it gives them a tool set that they can easily say here, Can you watch these for us? And Miran tas can actually help do that with you, So >>yeah, yeah, I mean, that's just another example of baking in that expert knowledge, right? So you can leverage that without tons and tons of a long ah, long runway of learning about how to do that sort of thing. Just get out of the box right away. There was the other thing, actually, that you could sleep by really quickly if you weren't paying close attention. But Sean mentioned it on the video. And that was how When you use dark enterprise container cloud to scale your cluster, particularly pulling a worker out, it doesn't just like Territo worker down and forget about it. Right? Is using good communities best practices to cordon and drain the No. So you aren't gonna disrupt your workloads? You're going to just have a bunch of containers instantly. Excellent crash. You could really carefully manage the migration of workloads off that cluster has baked right in tow. How? How? Document? The brass container cloud is his handling cluster scale. >>Right? And And the kubernetes, uh, scaling methodology is is he adhered to with all of the proper techniques that ensure that it will tell you. Wait, you've got a container that actually needs three, uh, three, uh, instances of itself. And you don't want to take that out, because that node, it means you'll only be able to have to. And we can't do that. We can't allow that. >>Okay, Very cool. Further thoughts on this video. So should we go to the questions. >>Let's let's go to the questions >>that people have. Uh, there's one good one here, down near the bottom regarding whether an a p I is available to do this. So in all these demos were clicking through this web. You I Yes, this is all a p. I driven. You could do all of this. You know, automate all this away is part of the CSC change. Absolutely. Um, that's kind of the point, right? We want you to be ableto spin up. Come on. I keep calling them commodity clusters. What I mean by that is clusters that you can create and throw away. You know, easily and automatically. So everything you see in these demos eyes exposed to FBI? >>Yeah. In addition, through the standard Cube cuddle, Uh, cli as well. So if you're not a programmer, but you still want to do some scripting Thio, you know, set up things and deploy your applications and things. You can use this standard tool sets that are available to accomplish that. >>There is a good question on scale here. So, like, just how many clusters and what sort of scale of deployments come this kind of support our engineers report back here that we've done in practice up to a Zeman ia's like two hundred clusters. We've deployed on this with two hundred fifty nodes in a cluster. So were, you know, like like I said, hundreds, hundreds of notes, hundreds of clusters managed by documented press container fall and then those downstream clusters, of course, subject to the usual constraints for kubernetes, right? Like default constraints with something like one hundred pods for no or something like that. There's a few different limitations of how many pods you can run on a given cluster that comes to us not from Dr Enterprise Container Cloud, but just from the underlying kubernetes distribution. >>Yeah, E. I mean, I don't think that we constrain any of the capabilities that are available in the, uh, infrastructure deliveries, uh, service within the goober Netease framework. So were, you know, But we are, uh, adhering to the standards that we would want to set to make sure that we're not overloading a node or those kinds of things, >>right. Absolutely cool. Alright. So at this point, we've got kind of a two layered our protection when we are management cluster, but we deployed in the first video. Then we use that to deploy one child clustering work, classroom, uh, for more sophisticated deployments where we might want to manage child clusters across multiple regions. We're gonna add another layer into our architectural we're gonna add in regional cluster management. So this idea you're gonna have the single management cluster that we started within the first video. On the next video, we're gonna learn how to spin up a regional clusters, each one of which would manage, for example, a different AWS uh, US region. So let me just pull out the video for that bill. We'll check it out for me. Mhm. >>Hello. In this demo, we will cover the deployment of additional regional management. Cluster will include a brief architectures of you how to set up the management environment, prepare for the deployment deployment overview and then just to prove it, to play a regional child cluster. So, looking at the overall architecture, the management cluster provides all the core functionality, including identity management, authentication, inventory and release version. ING Regional Cluster provides the specific architecture provider in this case AWS on the LCN components on the D you speak Cluster for child cluster is the cluster or clusters being deployed and managed? Okay, so why do you need a regional cluster? Different platform architectures, for example aws who have been stack even bare metal to simplify connectivity across multiple regions handle complexities like VPNs or one way connectivity through firewalls, but also help clarify availability zones. Yeah. Here we have a view of the regional cluster and how it connects to the management cluster on their components, including items like the LCN cluster Manager we also Machine Manager were held. Mandel are managed as well as the actual provider logic. Mhm. Okay, we'll begin by logging on Is the default administrative user writer. Okay, once we're in there, we'll have a look at the available clusters making sure we switch to the default project which contains the administration clusters. Here we can see the cars management cluster, which is the master controller. And you see, it only has three nodes, three managers, no workers. Okay, if we look at another regional cluster similar to what we're going to deploy now, also only has three managers once again, no workers. But as a comparison, here's a child cluster This one has three managers, but also has additional workers associate it to the cluster. All right, we need to connect. Tell bootstrap note. Preferably the same note that used to create the original management plaster. It's just on AWS, but I still want to machine. All right. A few things we have to do to make sure the environment is ready. First thing we're going to see go into route. We'll go into our releases folder where we have the kozberg struck on. This was the original bootstrap used to build the original management cluster. Yeah, we're going to double check to make sure our cube con figures there once again, the one created after the original customers created just double check. That cute conflict is the correct one. Does point to the management cluster. We're just checking to make sure that we can reach the images that everything is working. A condom. No damages waken access to a swell. Yeah. Next we're gonna edit the machine definitions. What we're doing here is ensuring that for this cluster we have the right machine definitions, including items like the am I. So that's found under the templates AWS directory. We don't need to edit anything else here. But we could change items like the size of the machines attempts. We want to use that The key items to ensure where you changed the am I reference for the junta image is the one for the region in this case AWS region for utilizing this was no construct deployment. We have to make sure we're pointing in the correct open stack images. Yeah, okay. Set the correct and my save file. Now we need to get up credentials again. When we originally created the bootstrap cluster, we got credentials from eight of the U. S. If we hadn't done this, we would need to go through the u A. W s set up. So we're just exporting the AWS access key and I d. What's important is CAAs aws enabled equals. True. Now we're sitting the region for the new regional cluster. In this case, it's Frankfurt on exporting our cube conflict that we want to use for the management cluster. When we looked at earlier Yeah, now we're exporting that. Want to call the cluster region Is Frank Foods Socrates Frankfurt yet trying to use something descriptive It's easy to identify. Yeah, and then after this, we'll just run the bootstrap script, which will complete the deployment for us. Bootstrap of the regional cluster is quite a bit quicker than the initial management clusters. There are fewer components to be deployed. Um, but to make it watchable, we've spent it up. So we're preparing our bootstrap cluster on the local bootstrap node. Almost ready on. We started preparing the instances at W s and waiting for that bastard and no to get started. Please. The best you nerd Onda. We're also starting to build the actual management machines they're now provisioning on. We've reached the point where they're actually starting to deploy. Dr. Enterprise, this is probably the longest face. Yeah, seeing the second that all the nerds will go from the player deployed. Prepare, prepare. Yeah, You'll see their status changes updates. He was the first night ready. Second, just applying second already. Both my time. No waiting from home control. Let's become ready. Removing cluster the management cluster from the bootstrap instance into the new cluster running the date of the U. S. All my stay. Ah, now we're playing Stockland. Switch over is done on. Done. Now I will build a child cluster in the new region very, very quickly to find the cluster will pick. Our new credential has shown up. We'll just call it Frankfurt for simplicity a key and customs to find. That's the machine. That cluster stop with three managers. Set the correct Am I for the region? Yeah, Do the same to add workers. There we go test the building. Yeah. Total bill of time Should be about fifteen minutes. Concedes in progress. It's going to expect this up a little bit. Check the events. We've created all the dependencies, machine instances, machines, a boat shortly. We should have a working cluster in Frankfurt region. Now almost a one note is ready from management. Two in progress. Yeah, on we're done. Clusters up and running. Yeah. >>Excellent. So at this point, we've now got that three tier structure that we talked about before the video. We got that management cluster that we do strapped in the first video. Now we have in this example to different regional clustering one in Frankfurt, one of one management was two different aws regions. And sitting on that you can do Strap up all those Doctor enterprise costumes that we want for our work clothes. >>Yeah, that's the key to this is to be able to have co resident with your actual application service enabled clusters the management co resident with it so that you can, you know, quickly access that he observation Elson Surfboard services like the graph, Ana and that sort of thing for your particular region. A supposed to having to lug back into the home. What did you call it when we started >>the mothership? >>The mothership. Right. So we don't have to go back to the mother ship. We could get >>it locally. Yeah, when, like to that point of aggregating things under a single pane of glass? That's one thing that again kind of sailed by in the demo really quickly. But you'll notice all your different clusters were on that same cluster. Your pain on your doctor Enterprise Container Cloud management. Uh, court. Right. So both your child clusters for running workload and your regional clusters for bootstrapping. Those child clusters were all listed in the same place there. So it's just one pane of glass to go look for, for all of your clusters, >>right? And, uh, this is kind of an important point. I was, I was realizing, as we were going through this. All of the mechanics are actually identical between the bootstrapped cluster of the original services and the bootstrapped cluster of the regional services. It's the management layer of everything so that you only have managers, you don't have workers and that at the child cluster layer below the regional or the management cluster itself, that's where you have the worker nodes. And those are the ones that host the application services in that three tiered architecture that we've now defined >>and another, you know, detail for those that have sharp eyes. In that video, you'll notice when deploying a child clusters. There's not on Lee. A minimum of three managers for high availability management cluster. You must have at least two workers that's just required for workload failure. It's one of those down get out of work. They could potentially step in there, so your minimum foot point one of these child clusters is fine. Violence and scalable, obviously, from a >>That's right. >>Let's take a quick peek of the questions here, see if there's anything we want to call out, then we move on to our last want to my last video. There's another question here about, like where these clusters can live. So again, I know these examples are very aws heavy. Honestly, it's just easy to set up down on the other us. We could do things on bare metal and, uh, open stack departments on Prem. That's what all of this still works in exactly the same way. >>Yeah, the, uh, key to this, especially for the the, uh, child clusters, is the provision hers? Right? See you establish on AWS provision or you establish a bare metal provision or you establish a open stack provision. Or and eventually that list will include all of the other major players in the cloud arena. But you, by selecting the provision or within your management interface, that's where you decide where it's going to be hosted, where the child cluster is to be hosted. >>Speaking off all through a child clusters. Let's jump into our last video in the Siri's, where we'll see how to spin up a child cluster on bare metal. >>Hello. This demo will cover the process of defining bare metal hosts and then review the steps of defining and deploying a bare metal based doctor enterprise cluster. So why bare metal? Firstly, it eliminates hyper visor overhead with performance boost of up to thirty percent. Provides direct access to GP use, prioritize for high performance wear clothes like machine learning and AI, and supports high performance workloads like network functions, virtualization. It also provides a focus on on Prem workloads, simplifying and ensuring we don't need to create the complexity of adding another opera visor. Lay it between so continue on the theme Why Communities and bare metal again Hyper visor overhead. Well, no virtualization overhead. Direct access to hardware items like F p G A s G p us. We can be much more specific about resource is required on the nodes. No need to cater for additional overhead. Uh, we can handle utilization in the scheduling. Better Onda we increase the performances and simplicity of the entire environment as we don't need another virtualization layer. Yeah, In this section will define the BM hosts will create a new project will add the bare metal hosts, including the host name. I put my credentials I pay my address the Mac address on then provide a machine type label to determine what type of machine it is for later use. Okay, let's get started. So well again. Was the operator thing. We'll go and we'll create a project for our machines to be a member off helps with scoping for later on for security. I begin the process of adding machines to that project. Yeah. So the first thing we had to be in post, Yeah, many of the machine A name. Anything you want, que experimental zero one. Provide the IAP my user name type my password. Okay. On the Mac address for the common interface with the boot interface and then the i p m I i p address These machines will be at the time storage worker manager. He's a manager. Yeah, we're gonna add a number of other machines on will. Speed this up just so you could see what the process looks like in the future. Better discovery will be added to the product. Okay. Okay. Getting back there we have it are Six machines have been added, are busy being inspected, being added to the system. Let's have a look at the details of a single note. Yeah, you can see information on the set up of the node. Its capabilities? Yeah. As well as the inventory information about that particular machine. I see. Okay, let's go and create the cluster. Yeah, So we're going to deploy a bare metal child cluster. The process we're going to go through is pretty much the same as any other child cluster. So we'll credit custom. We'll give it a name, but if it were selecting bare metal on the region, we're going to select the version we want to apply. No way. We're going to add this search keys. If we hope we're going to give the load. Balancer host I p that we'd like to use out of dress range on update the address range that we want to use for the cluster. Check that the sea ideal blocks for the Cuban ladies and tunnels are what we want them to be. Enable disabled stack light. Yeah, and soothe stack light settings to find the cluster. And then, as for any other machine, we need to add machines to the cluster. Here. We're focused on building communities clusters, so we're gonna put the count of machines. You want managers? We're gonna pick the label type manager and create three machines is the manager for the Cuban eighties. Casting Okay thing. We're having workers to the same. It's a process. Just making sure that the worker label host level are I'm sorry. On when Wait for the machines to deploy. Let's go through the process of putting the operating system on the notes validating and operating system deploying doctor identifies Make sure that the cluster is up and running and ready to go. Okay, let's review the bold events waken See the machine info now populated with more information about the specifics of things like storage and of course, details of a cluster etcetera. Yeah, yeah, well, now watch the machines go through the various stages from prepared to deploy on what's the cluster build? And that brings us to the end of this particular demo. You can see the process is identical to that of building a normal child cluster we got our complaint is complete. >>All right, so there we have it, deploying a cluster to bare metal. Much the same is how we did for AWS. I guess maybe the biggest different stepwise there is there is that registration face first, right? So rather than just using AWS financials toe magically create PM's in the cloud. You got a point out all your bare metal servers to Dr Enterprise between the cloud and they really come in, I guess three profiles, right? You got your manager profile with a profile storage profile which has been labeled as allocate. Um, crossword cluster has appropriate, >>right? And And I think that the you know, the key differentiator here is that you have more physical control over what, uh, attributes that love your cat, by the way, uh, where you have the different attributes of a server of physical server. So you can, uh, ensure that the SSD configuration on the storage nodes is gonna be taken advantage of in the best way the GP use on the worker nodes and and that the management layer is going to have sufficient horsepower to, um, spin up to to scale up the the environments, as required. One of the things I wanted to mention, though, um, if I could get this out without the choking much better. Um, is that Ah, hey, mentioned the load balancer and I wanted to make sure in defining the load balancer and the load balancer ranges. Um, that is for the top of the the cluster itself. That's the operations of the management, uh, layer integrating with your systems internally to be able to access the the Cube Can figs. I I p address the, uh, in a centralized way. It's not the load balancer that's working within the kubernetes cluster that you are deploying. That's still cube proxy or service mesh, or however you're intending to do it. So, um, it's kind of an interesting step that your initial step in building this, um and we typically use things like metal L B or in gen X or that kind of thing is to establish that before we deploy this bear mental cluster so that it can ride on top of that for the tips and things. >>Very cool. So any other thoughts on what we've seen so far today? Bruce, we've gone through all the different layers. Doctor enterprise container clouds in these videos from our management are regional to our clusters on aws hand bear amount, Of course, with his dad is still available. Closing thoughts before we take just a very short break and run through these demos again. >>You know, I've been very exciting. Ah, doing the presentation with you. I'm really looking forward to doing it the second time, so that we because we've got a good rhythm going about this kind of thing. So I'm looking forward to doing that. But I think that the key elements of what we're trying to convey to the folks out there in the audience that I hope you've gotten out of it is that will that this is an easy enough process that if you follow the step by steps going through the documentation that's been put out in the chat, um, that you'll be able to give this a go yourself, Um, and you don't have to limit yourself toe having physical hardware on prim to try it. You could do it in a ws as we've shown you today. And if you've got some fancy use cases like, uh, you you need a Hadoop And and, uh, you know, cloud oriented ai stuff that providing a bare metal service helps you to get there very fast. So right. Thank you. It's been a pleasure. >>Yeah, thanks everyone for coming out. So, like I said we're going to take a very short, like, three minute break here. Uh, take the opportunity to let your colleagues know if they were in another session or they didn't quite make it to the beginning of this session. Or if you just want to see these demos again, we're going to kick off this demo. Siri's again in just three minutes at ten. Twenty five a. M. Pacific time where we will see all this great stuff again. Let's take a three minute break. I'll see you all back here in just two minutes now, you know. Okay, folks, that's the end of our extremely short break. We'll give people just maybe, like one more minute to trickle in if folks are interested in coming on in and jumping into our demo. Siri's again. Eso For those of you that are just joining us now I'm Bill Mills. I head up curriculum development for the training team here. Moran Tous on Joining me for this session of demos is Bruce. Don't you go ahead and introduce yourself doors, who is still on break? That's cool. We'll give Bruce a minute or two to get back while everyone else trickles back in. There he is. Hello, Bruce. >>How'd that go for you? Okay, >>Very well. So let's kick off our second session here. I e just interest will feel for you. Thio. Let it run over here. >>Alright. Hi. Bruce Matthews here. I'm the Western Regional Solutions architect for Marantz. Use A I'm the one with the gray hair and the glasses. Uh, the handsome one is Bill. So, uh, Bill, take it away. >>Excellent. So over the next hour or so, we've got a Siris of demos that's gonna walk you through your first steps with Dr Enterprise Container Cloud Doctor Enterprise Container Cloud is, of course, Miranda's brand new offering from bootstrapping kubernetes clusters in AWS bare metal open stack. And for the providers in the very near future. So we we've got, you know, just just over an hour left together on this session, uh, if you joined us at the top of the hour back at nine. A. M. Pacific, we went through these demos once already. Let's do them again for everyone else that was only able to jump in right now. Let's go. Our first video where we're gonna install Dr Enterprise container cloud for the very first time and use it to bootstrap management. Cluster Management Cluster, as I like to describe it, is our mother ship that's going to spin up all the other kubernetes clusters, Doctor Enterprise clusters that we're gonna run our workloads on. So I'm gonna do >>I'm so excited. I can hardly wait. >>Let's do it all right to share my video out here. Yeah, let's do it. >>Good day. The focus for this demo will be the initial bootstrap of the management cluster on the first regional clusters. To support AWS deployments, the management cluster provides the core functionality, including identity management, authentication, infantry release version. The regional cluster provides the specific architecture provided in this case AWS and the Elsom components on the UCP cluster Child cluster is the cluster or clusters being deployed and managed. The deployment is broken up into five phases. The first phase is preparing a bootstrap note on its dependencies on handling the download of the bridge struck tools. The second phase is obtaining America's license file. Third phase. Prepare the AWS credentials instead of the ideas environment, the fourth configuring the deployment, defining things like the machine types on the fifth phase, Run the bootstrap script and wait for the deployment to complete. Okay, so here we're sitting up the strap node. Just checking that it's clean and clear and ready to go there. No credentials already set up on that particular note. Now, we're just checking through aws to make sure that the account we want to use we have the correct credentials on the correct roles set up on validating that there are no instances currently set up in easy to instance, not completely necessary, but just helps keep things clean and tidy when I am perspective. Right. So next step, we're just gonna check that we can from the bootstrap note, reach more antis, get to the repositories where the various components of the system are available. They're good. No areas here. Yeah, right now we're going to start sitting at the bootstrap note itself. So we're downloading the cars release, get get cars, script, and then next we're going to run it. Yeah, I've been deployed changing into that big struck folder, just making see what's there right now we have no license file, so we're gonna get the license filed. Okay? Get the license file through more antis downloads site signing up here, downloading that license file and putting it into the Carisbrook struck folder. Okay, since we've done that, we can now go ahead with the rest of the deployment. Yeah, see what the follow is there? Uh huh. Once again, checking that we can now reach E C two, which is extremely important for the deployment. Just validation steps as we move through the process. Alright. Next big step is violating all of our AWS credentials. So the first thing is, we need those route credentials which we're going to export on the command line. This is to create the necessary bootstrap user on AWS credentials for the completion off the deployment we're now running in AWS policy create. So it is part of that is creating our food trucks script. Creating this through policy files onto the AWS, just generally preparing the environment using a cloud formation script, you'll see in a second, I'll give a new policy confirmations just waiting for it to complete. And there is done. It's gonna have a look at the AWS console. You can see that we're creative completed. Now we can go and get the credentials that we created. Good day. I am console. Go to the new user that's being created. We'll go to the section on security credentials and creating new keys. Download that information media access Key I. D and the secret access key, but usually then exported on the command line. Okay, Couple of things to Notre. Ensure that you're using the correct AWS region on ensure that in the conflict file you put the correct Am I in for that region? I'm sure you have it together in a second. Okay, thanks. Is key. So you could X key Right on. Let's kick it off. So this process takes between thirty and forty five minutes. Handles all the AWS dependencies for you. Um, as we go through, the process will show you how you can track it. Andi will start to see things like the running instances being created on the AWS side. The first phase off this whole process happening in the background is the creation of a local kind based bootstrapped cluster on the bootstrap node that clusters then used to deploy and manage all the various instances and configurations within AWS at the end of the process. That cluster is copied into the new cluster on AWS and then shut down that local cluster essentially moving itself over. Yeah, okay. Local clusters boat. Just waiting for the various objects to get ready. Standard communities objects here. Yeah, you mentioned Yeah. So we've speed up this process a little bit just for demonstration purposes. Okay, there we go. So first note is being built the bastion host just jump box that will allow us access to the entire environment. Yeah, In a few seconds, we'll see those instances here in the US console on the right. Um, the failures that you're seeing around failed to get the I. P for Bastian is just the weight state while we wait for AWS to create the instance. Okay. Yeah. Beauty there. Movies. Okay, sketch. Hello? Yeah, Okay. Okay. On. There we go. Question host has been built on three instances for the management clusters have now been created. Okay, We're going through the process of preparing. Those nodes were now copying everything over. See that scaling up of controllers in the big strapped cluster? It's indicating that we're starting all of the controllers in the new question. Almost there. Right? Okay. Just waiting for key. Clark. Uh huh. So finish up. Yeah. No. Now we're shutting down. Control this on the local bootstrap node on preparing our I. D. C configuration, fourth indication. So once this is completed, the last phase will be to deploy stack light into the new cluster, that glass on monitoring tool set, Then we go stack like deployment has started. Mhm. Coming to the end of the deployment mountain. Yeah, they were cut final phase of the deployment. And we are done. Yeah, you'll see. At the end, they're providing us the details of you. I log in. So there's a key Clark log in. Uh, you can modify that initial default possible is part of the configuration set up where they were in the documentation way. Go Councils up way can log in. Yeah. Yeah. Thank you very much for watching. >>All right, so at this point, what we have we got our management cluster spun up, ready to start creating work clusters. So just a couple of points to clarify there to make sure everyone caught that, uh, as advertised. That's darker. Enterprise container cloud management cluster. That's not rework loans. are gonna go right? That is the tool and you're gonna use to start spinning up downstream commodity documentary prize clusters for bootstrapping record too. >>And the seed host that were, uh, talking about the kind cluster dingy actually doesn't have to exist after the bootstrap succeeds eso It's sort of like, uh, copies head from the seed host Toothy targets in AWS spins it up it then boots the the actual clusters and then it goes away too, because it's no longer necessary >>so that bootstrapping know that there's not really any requirements, Hardly on that, right. It just has to be able to reach aws hit that Hit that a p I to spin up those easy to instances because, as you just said, it's just a kubernetes in docker cluster on that piece. Drop note is just gonna get torn down after the set up finishes on. You no longer need that. Everything you're gonna do, you're gonna drive from the single pane of glass provided to you by your management cluster Doctor enterprise Continue cloud. Another thing that I think is sort of interesting their eyes that the convict is fairly minimal. Really? You just need to provide it like aws regions. Um, am I? And that's what is going to spin up that spending that matter faster. >>Right? There is a mammal file in the bootstrap directory itself, and all of the necessary parameters that you would fill in have default set. But you have the option then of going in and defining a different Am I different for a different region, for example? Oh, are different. Size of instance from AWS. >>One thing that people often ask about is the cluster footprint. And so that example you saw they were spitting up a three manager, um, managing cluster as mandatory, right? No single manager set up at all. We want high availability for doctrine Enterprise Container Cloud management. Like so again, just to make sure everyone sort of on board with the life cycle stage that we're at right now. That's the very first thing you're going to do to set up Dr Enterprise Container Cloud. You're going to do it. Hopefully exactly once. Right now, you've got your management cluster running, and they're gonna use that to spend up all your other work clusters Day today has has needed How do we just have a quick look at the questions and then lets take a look at spinning up some of those child clusters. >>Okay, e think they've actually been answered? >>Yeah, for the most part. One thing I'll point out that came up again in the Dail, helpfully pointed out earlier in surgery, pointed out again, is that if you want to try any of the stuff yourself, it's all of the dogs. And so have a look at the chat. There's a links to instructions, so step by step instructions to do each and every thing we're doing here today yourself. I really encourage you to do that. Taking this out for a drive on your own really helps internalizing communicate these ideas after the after launch pad today, Please give this stuff try on your machines. Okay, So at this point, like I said, we've got our management cluster. We're not gonna run workloads there that we're going to start creating child clusters. That's where all of our work and we're gonna go. That's what we're gonna learn how to do in our next video. Cue that up for us. >>I so love Shawn's voice. >>Wasn't that all day? >>Yeah, I watched him read the phone book. >>All right, here we go. Let's now that we have our management cluster set up, let's create a first child work cluster. >>Hello. In this demo, we will cover the deployment experience of creating a new child cluster the scaling of the cluster on how to update the cluster. When a new version is available, we begin the process by logging onto the you I as a normal user called Mary. Let's go through the navigation of the u I. So you can switch Project Mary only has access to development. Uh huh. Get a list of the available projects that you have access to. What clusters have been deployed at the moment there. Man. Yes, this H keys, Associate ID for Mary into her team on the cloud credentials that allow you to create or access the various clouds that you can deploy clusters to finally different releases that are available to us. We can switch from dark mode to light mode, depending on your preferences. Right. Let's now set up some ssh keys for Mary so she can access the notes and machines again. Very simply, had Mississippi key give it a name. We copy and paste our public key into the upload key block. Or we can upload the key if we have the file available on our machine. A very simple process. So to create a new cluster, we define the cluster ad management nodes and add worker nodes to the cluster. Yeah, again, very simply, we got the clusters tab we had to create cluster button. Give the cluster name. Yeah, Andi, select the provider. We only have access to AWS in this particular deployment, so we'll stick to AWS. What's like the region in this case? US West one released version five point seven is the current release Onda Attach. Mary's Key is necessary key. We can then check the rest of the settings, confirming the provider any kubernetes c r D a r i p address information. We can change this. Should we wish to? We'll leave it default for now and then what components of stack light? I would like to deploy into my custom for this. I'm enabling stack light on logging, and I consider the retention sizes attention times on. Even at this stage, add any custom alerts for the watchdogs. Consider email alerting which I will need my smart host. Details and authentication details. Andi Slack Alerts. Now I'm defining the cluster. All that's happened is the cluster's been defined. I now need to add machines to that cluster. I'll begin by clicking the create machine button within the cluster definition. Oh, select manager, Select the number of machines. Three is the minimum. Select the instant size that I'd like to use from AWS and very importantly, ensure correct. Use the correct Am I for the region. I convinced side on the route. Device size. There we go. My three machines are busy creating. I now need to add some workers to this cluster. So I go through the same process this time once again, just selecting worker. I'll just add to once again the am I is extremely important. Will fail if we don't pick the right. Am I for a Clinton machine? In this case and the deployment has started, we can go and check on the bold status are going back to the clusters screen on clicking on the little three dots on the right. We get the cluster info and the events, so the basic cluster info you'll see pending their listen. Cluster is still in the process of being built. We kick on, the events will get a list of actions that have been completed This part of the set up of the cluster. So you can see here. We've created the VPC. We've created the sub nets on. We've created the Internet Gateway. It's unnecessary made of us. And we have no warnings of the stage. Okay, this will then run for a while. We have one minute past. We can click through. We can check the status of the machine balls as individuals so we can check the machine info, details of the machines that we've assigned mhm and see any events pertaining to the machine areas like this one on normal. Yeah. Just last. The community's components are waiting for the machines to start. Go back to customers. Okay, right. Because we're moving ahead now. We can see we have it in progress. Five minutes in new Matt Gateway. And at this stage, the machines have been built on assigned. I pick up the U S. Yeah, yeah, yeah. There we go. Machine has been created. See the event detail and the AWS. I'd for that machine. No speeding things up a little bit this whole process and to end takes about fifteen minutes. Run the clock forward, you'll notice is the machines continue to bold the in progress. We'll go from in progress to ready. A soon as we got ready on all three machines, the managers on both workers way could go on and we could see that now we reached the point where the cluster itself is being configured mhm and then we go. Cluster has been deployed. So once the classes deployed, we can now never get around. Our environment are looking into configure cluster. We could modify their cluster. We could get the end points for alert Alert Manager See here the griffon occupying and Prometheus are still building in the background but the cluster is available on You would be able to put workloads on it at this stage to download the cube conflict so that I can put workloads on it. It's again the three little dots in the right for that particular cluster. If the download cube conflict give it my password, I now have the Q conflict file necessary so that I can access that cluster. All right, Now that the build is fully completed, we can check out cluster info on. We can see that all the satellite components have been built. All the storage is there, and we have access to the CPU. I. So if we click into the cluster, we can access the UCP dashboard, click the signing with the clock button to use the SSO. We give Mary's possible to use the name once again. Thing is an unlicensed cluster way could license at this point. Or just skip it on. Do we have the UCP dashboard? You could see that has been up for a little while. We have some data on the dashboard going back to the console. We can now go to the griffon. A data just been automatically pre configured for us. We can switch and utilized a number of different dashboards that have already been instrumented within the cluster. So, for example, communities cluster information, the name spaces, deployments, nodes. Um, so we look at nodes. If we could get a view of the resource is utilization of Mrs Custer is very little running in it. Yeah, a general dashboard of Cuba Navies cluster. What If this is configurable, you can modify these for your own needs, or add your own dashboards on de scoped to the cluster. So it is available to all users who have access to this specific cluster. All right to scale the cluster on to add a No. This is simple. Is the process of adding a mode to the cluster, assuming we've done that in the first place. So we go to the cluster, go into the details for the cluster we select, create machine. Once again, we need to be ensure that we put the correct am I in and any other functions we like. You can create different sized machines so it could be a larger node. Could be bigger group disks and you'll see that worker has been added in the provisioning state. On shortly, we will see the detail off that worker as a complete to remove a note from a cluster. Once again, we're going to the cluster. We select the node we would like to remove. Okay, I just hit delete On that note. Worker nodes will be removed from the cluster using according and drawing method to ensure that your workloads are not affected. Updating a cluster. When an update is available in the menu for that particular cluster, the update button will become available. And it's a simple as clicking the button validating which release you would like to update to this case. This available releases five point seven point one give you I'm kicking the update back in the background. We will coordinate. Drain each node slowly, go through the process of updating it. Andi update will complete depending on what the update is as quickly as possible. Who we go. The notes being rebuilt in this case impacted the manager node. So one of the manager nodes is in the process of being rebuilt. In fact, to in this case, one has completed already. Yeah, and in a few minutes, we'll see that the upgrade has been completed. There we go. Great. Done. If you work loads of both using proper cloud native community standards, there will be no impact. >>All right, there. We haven't. We got our first workload cluster spun up and managed by Dr Enterprise Container Cloud. So I I loved Shawn's classic warning there. When you're spinning up an actual doctor enterprise deployment, you see little errors and warnings popping up. Just don't touch it. Just leave it alone and let Dr Enterprises self healing properties take care of all those very transient temporary glitches, resolve themselves and leave you with a functioning workload cluster within victims. >>And now, if you think about it that that video was not very long at all. And that's how long it would take you if someone came into you and said, Hey, can you spend up a kubernetes cluster for development development A. Over here, um, it literally would take you a few minutes to thio Accomplish that. And that was with a W s. Obviously, which is sort of, ah, transient resource in the cloud. But you could do exactly the same thing with resource is on Prem or resource is, um physical resource is and will be going through that later in the process. >>Yeah, absolutely one thing that is present in that demo, but that I like to highlight a little bit more because it just kind of glides by Is this notion of, ah, cluster release? So when Sean was creating that cluster, and also when when he was upgrading that cluster, he had to choose a release. What does that didn't really explain? What does that mean? Well, in Dr Enterprise Container Cloud, we have released numbers that capture the entire staff of container ization tools that will be deploying to that workload costume. So that's your version of kubernetes sed cor DNs calico. Doctor Engineer. All the different bits and pieces that not only work independently but are validated toe work together as a staff appropriate for production, humanities, adopted enterprise environments. >>Yep. From the bottom of the stack to the top, we actually test it for scale. Test it for CVS, test it for all of the various things that would, you know, result in issues with you running the application services. And I've got to tell you from having, you know, managed kubernetes deployments and things like that that if you're the one doing it yourself, it can get rather messy. Eso This makes it easy. >>Bruce, you were staying a second ago. They I'll take you at least fifteen minutes to install your release. Custer. Well, sure, but what would all the other bits and pieces you need toe? Not just It's not just about pressing the button to install it, right? It's making the right decision. About what components work? Well, our best tested toe be successful working together has a staff? Absolutely. We this release mechanism and Dr Enterprise Container Cloud. Let's just kind of package up that expert knowledge and make it available in a really straightforward, fashionable species. Uh, pre Confederate release numbers and Bruce is you're pointing out earlier. He's got delivered to us is updates kind of transparent period. When when? When Sean wanted toe update that cluster, he created little update. Custer Button appeared when an update was available. All you gotta do is click. It tells you what Here's your new stack of communities components. It goes ahead. And the straps those components for you? >>Yeah, it actually even displays at the top of the screen. Ah, little header That says you've got an update available. Do you want me to apply? It s o >>Absolutely. Another couple of cool things. I think that are easy to miss in that demo was I really like the on board Bafana that comes along with this stack. So we've been Prometheus Metrics and Dr Enterprise for years and years now. They're very high level. Maybe in in previous versions of Dr Enterprise having those detailed dashboards that Ravana provides, I think that's a great value out there. People always wanted to be ableto zoom in a little bit on that, uh, on those cluster metrics, you're gonna provides them out of the box for us. Yeah, >>that was Ah, really, uh, you know, the joining of the Miranda's and Dr teams together actually spawned us to be able to take the best of what Morantes had in the open stack environment for monitoring and logging and alerting and to do that integration in in a very short period of time so that now we've got it straight across the board for both the kubernetes world and the open stack world. Using the same tool sets >>warm. One other thing I wanna point out about that demo that I think there was some questions about our last go around was that demo was all about creating a managed workplace cluster. So the doctor enterprise Container Cloud managers were using those aws credentials provisioned it toe actually create new e c two instances installed Docker engine stalled. Doctor Enterprise. Remember all that stuff on top of those fresh new VM created and managed by Dr Enterprise contain the cloud. Nothing unique about that. AWS deployments do that on open staff doing on Parramatta stuff as well. Um, there's another flavor here, though in a way to do this for all of our long time doctor Enterprise customers that have been running Doctor Enterprise for years and years. Now, if you got existing UCP points existing doctor enterprise deployments, you plug those in to Dr Enterprise Container Cloud, uh, and use darker enterprise between the cloud to manage those pre existing Oh, working clusters. You don't always have to be strapping straight from Dr Enterprises. Plug in external clusters is bad. >>Yep, the the Cube config elements of the UCP environment. The bundling capability actually gives us a very straightforward methodology. And there's instructions on our website for exactly how thio, uh, bring in import and you see p cluster. Um so it it makes very convenient for our existing customers to take advantage of this new release. >>Absolutely cool. More thoughts on this wonders if we jump onto the next video. >>I think we should move press on >>time marches on here. So let's Let's carry on. So just to recap where we are right now, first video, we create a management cluster. That's what we're gonna use to create All our downstream were closed clusters, which is what we did in this video. Let's maybe the simplest architectures, because that's doing everything in one region on AWS pretty common use case because we want to be able to spin up workload clusters across many regions. And so to do that, we're gonna add a third layer in between the management and work cluster layers. That's gonna be our regional cluster managers. So this is gonna be, uh, our regional management cluster that exists per region that we're going to manage those regional managers will be than the ones responsible for spending part clusters across all these different regions. Let's see it in action in our next video. >>Hello. In this demo, we will cover the deployment of additional regional management. Cluster will include a brief architectural overview, how to set up the management environment, prepare for the deployment deployment overview, and then just to prove it, to play a regional child cluster. So looking at the overall architecture, the management cluster provides all the core functionality, including identity management, authentication, inventory and release version. ING Regional Cluster provides the specific architecture provider in this case, AWS on the L C M components on the d you speak cluster for child cluster is the cluster or clusters being deployed and managed? Okay, so why do you need original cluster? Different platform architectures, for example AWS open stack, even bare metal to simplify connectivity across multiple regions handle complexities like VPNs or one way connectivity through firewalls, but also help clarify availability zones. Yeah. Here we have a view of the regional cluster and how it connects to the management cluster on their components, including items like the LCN cluster Manager. We also machine manager. We're hell Mandel are managed as well as the actual provider logic. Okay, we'll begin by logging on Is the default administrative user writer. Okay, once we're in there, we'll have a look at the available clusters making sure we switch to the default project which contains the administration clusters. Here we can see the cars management cluster, which is the master controller. When you see it only has three nodes, three managers, no workers. Okay, if we look at another regional cluster, similar to what we're going to deploy now. Also only has three managers once again, no workers. But as a comparison is a child cluster. This one has three managers, but also has additional workers associate it to the cluster. Yeah, all right, we need to connect. Tell bootstrap note, preferably the same note that used to create the original management plaster. It's just on AWS, but I still want to machine Mhm. All right, A few things we have to do to make sure the environment is ready. First thing we're gonna pseudo into route. I mean, we'll go into our releases folder where we have the car's boot strap on. This was the original bootstrap used to build the original management cluster. We're going to double check to make sure our cube con figures there It's again. The one created after the original customers created just double check. That cute conflict is the correct one. Does point to the management cluster. We're just checking to make sure that we can reach the images that everything's working, condone, load our images waken access to a swell. Yeah, Next, we're gonna edit the machine definitions what we're doing here is ensuring that for this cluster we have the right machine definitions, including items like the am I So that's found under the templates AWS directory. We don't need to edit anything else here, but we could change items like the size of the machines attempts we want to use but the key items to ensure where changed the am I reference for the junta image is the one for the region in this case aws region of re utilizing. This was an open stack deployment. We have to make sure we're pointing in the correct open stack images. Yeah, yeah. Okay. Sit the correct Am I save the file? Yeah. We need to get up credentials again. When we originally created the bootstrap cluster, we got credentials made of the U. S. If we hadn't done this, we would need to go through the u A. W s set up. So we just exporting AWS access key and I d. What's important is Kaz aws enabled equals. True. Now we're sitting the region for the new regional cluster. In this case, it's Frankfurt on exporting our Q conflict that we want to use for the management cluster when we looked at earlier. Yeah, now we're exporting that. Want to call? The cluster region is Frankfurt's Socrates Frankfurt yet trying to use something descriptive? It's easy to identify. Yeah, and then after this, we'll just run the bootstrap script, which will complete the deployment for us. Bootstrap of the regional cluster is quite a bit quicker than the initial management clusters. There are fewer components to be deployed, but to make it watchable, we've spent it up. So we're preparing our bootstrap cluster on the local bootstrap node. Almost ready on. We started preparing the instances at us and waiting for the past, you know, to get started. Please the best your node, onda. We're also starting to build the actual management machines they're now provisioning on. We've reached the point where they're actually starting to deploy Dr Enterprise, he says. Probably the longest face we'll see in a second that all the nodes will go from the player deployed. Prepare, prepare Mhm. We'll see. Their status changes updates. It was the first word ready. Second, just applying second. Grady, both my time away from home control that's become ready. Removing cluster the management cluster from the bootstrap instance into the new cluster running a data for us? Yeah, almost a on. Now we're playing Stockland. Thanks. Whichever is done on Done. Now we'll build a child cluster in the new region very, very quickly. Find the cluster will pick our new credential have shown up. We'll just call it Frankfurt for simplicity. A key on customers to find. That's the machine. That cluster stop with three manages set the correct Am I for the region? Yeah, Same to add workers. There we go. That's the building. Yeah. Total bill of time. Should be about fifteen minutes. Concedes in progress. Can we expect this up a little bit? Check the events. We've created all the dependencies, machine instances, machines. A boat? Yeah. Shortly. We should have a working caster in the Frankfurt region. Now almost a one note is ready from management. Two in progress. On we're done. Trust us up and running. >>Excellent. There we have it. We've got our three layered doctor enterprise container cloud structure in place now with our management cluster in which we scrap everything else. Our regional clusters which manage individual aws regions and child clusters sitting over depends. >>Yeah, you can. You know you can actually see in the hierarchy the advantages that that presents for folks who have multiple locations where they'd like a geographic locations where they'd like to distribute their clusters so that you can access them or readily co resident with your development teams. Um and, uh, one of the other things I think that's really unique about it is that we provide that same operational support system capability throughout. So you've got stack light monitoring the stack light that's monitoring the stack light down to the actual child clusters that they have >>all through that single pane of glass that shows you all your different clusters, whether their workload cluster like what the child clusters or usual clusters from managing different regions. Cool. Alright, well, time marches on your folks. We've only got a few minutes left and I got one more video in our last video for the session. We're gonna walk through standing up a child cluster on bare metal. So so far, everything we've seen so far has been aws focus. Just because it's kind of easy to make that was on AWS. We don't want to leave you with the impression that that's all we do, we're covering AWS bare metal and open step deployments as well documented Craftsman Cloud. Let's see it in action with a bare metal child cluster. >>We are on the home stretch, >>right. >>Hello. This demo will cover the process of defining bare metal hosts and then review the steps of defining and deploying a bare metal based doctor enterprise cluster. Yeah, so why bare metal? Firstly, it eliminates hyper visor overhead with performance boost of up to thirty percent provides direct access to GP use, prioritize for high performance wear clothes like machine learning and AI, and support high performance workouts like network functions, virtualization. It also provides a focus on on Prem workloads, simplifying and ensuring we don't need to create the complexity of adding another hyper visor layer in between. So continuing on the theme Why communities and bare metal again Hyper visor overhead. Well, no virtualization overhead. Direct access to hardware items like F p g A s G p, us. We can be much more specific about resource is required on the nodes. No need to cater for additional overhead. We can handle utilization in the scheduling better Onda. We increase the performance and simplicity of the entire environment as we don't need another virtualization layer. Yeah, In this section will define the BM hosts will create a new project. Will add the bare metal hosts, including the host name. I put my credentials. I pay my address, Mac address on, then provide a machine type label to determine what type of machine it is. Related use. Okay, let's get started Certain Blufgan was the operator thing. We'll go and we'll create a project for our machines to be a member off. Helps with scoping for later on for security. I begin the process of adding machines to that project. Yeah. Yeah. So the first thing we had to be in post many of the machine a name. Anything you want? Yeah, in this case by mental zero one. Provide the IAP My user name. Type my password? Yeah. On the Mac address for the active, my interface with boot interface and then the i p m i P address. Yeah, these machines. We have the time storage worker manager. He's a manager. We're gonna add a number of other machines on will speed this up just so you could see what the process. Looks like in the future, better discovery will be added to the product. Okay, Okay. Getting back there. We haven't Are Six machines have been added. Are busy being inspected, being added to the system. Let's have a look at the details of a single note. Mhm. We can see information on the set up of the node. Its capabilities? Yeah. As well as the inventory information about that particular machine. Okay, it's going to create the cluster. Mhm. Okay, so we're going to deploy a bare metal child cluster. The process we're going to go through is pretty much the same as any other child cluster. So credit custom. We'll give it a name. Thank you. But he thought were selecting bare metal on the region. We're going to select the version we want to apply on. We're going to add this search keys. If we hope we're going to give the load. Balancer host I p that we'd like to use out of the dress range update the address range that we want to use for the cluster. Check that the sea idea blocks for the communities and tunnels are what we want them to be. Enable disabled stack light and said the stack light settings to find the cluster. And then, as for any other machine, we need to add machines to the cluster. Here we're focused on building communities clusters. So we're gonna put the count of machines. You want managers? We're gonna pick the label type manager on create three machines. Is a manager for the Cuban a disgusting? Yeah, they were having workers to the same. It's a process. Just making sure that the worker label host like you are so yes, on Duin wait for the machines to deploy. Let's go through the process of putting the operating system on the notes, validating that operating system. Deploying Docker enterprise on making sure that the cluster is up and running ready to go. Okay, let's review the bold events. We can see the machine info now populated with more information about the specifics of things like storage. Yeah, of course. Details of a cluster, etcetera. Yeah, Yeah. Okay. Well, now watch the machines go through the various stages from prepared to deploy on what's the cluster build, and that brings us to the end of this particular do my as you can see the process is identical to that of building a normal child cluster we got our complaint is complete. >>Here we have a child cluster on bare metal for folks that wanted to play the stuff on Prem. >>It's ah been an interesting journey taken from the mothership as we started out building ah management cluster and then populating it with a child cluster and then finally creating a regional cluster to spread the geographically the management of our clusters and finally to provide a platform for supporting, you know, ai needs and and big Data needs, uh, you know, thank goodness we're now able to put things like Hadoop on, uh, bare metal thio in containers were pretty exciting. >>Yeah, absolutely. So with this Doctor Enterprise container cloud platform. Hopefully this commoditized scooping clusters, doctor enterprise clusters that could be spun up and use quickly taking provisioning times. You know, from however many months to get new clusters spun up for our teams. Two minutes, right. We saw those clusters gets better. Just a couple of minutes. Excellent. All right, well, thank you, everyone, for joining us for our demo session for Dr Enterprise Container Cloud. Of course, there's many many more things to discuss about this and all of Miranda's products. If you'd like to learn more, if you'd like to get your hands dirty with all of this content, police see us a training don Miranda's dot com, where we can offer you workshops and a number of different formats on our entire line of products and hands on interactive fashion. Thanks, everyone. Enjoy the rest of the launchpad of that >>thank you all enjoy.

>> Thank you, everyone for joining. I'm here today to talk about ingress controllers, API gateways, and service mesh on Kubernetes, three very hot topics that are also frequently confusing. So I'm Richard Li, founder/CEO of Ambassador Labs, formerly known as Datawire. We sponsor a number of popular open source projects that are part of the Cloud Native Computing Foundation, including Telepresence and Ambassador, which is a Kubernetes native API gateway. And most of what I'm going to talk about today is related to our work around Ambassador. So I want to start by talking about application architecture and workflow on Kubernetes and how applications that are being built on Kubernetes really differ from how they used to be built. So when you're building applications on Kubernetes, the traditional architecture is the very famous monolith. And the monolith is a central piece of software. It's one giant thing that you build deploy, run. And the value of a monolith is it's really simple. And if you think about the monolithic development process, more importantly is that architecture is really reflected in that workflow. So with a monolith, you have a very centralized development process. You tend not to release too frequently because you have all these different development teams that are working on different features, and then you decide in advance when you're going to release that particular piece of software and everyone works towards that release train. And you have specialized teams. You have a development team, which has all your developers. You have a QA team, you have a release team, you have an operations team. So that's your typical development organization and workflow with a monolithic application. As organizations shift to microservices, they adopt a very different development paradigm. It's a decentralized development paradigm where you have lots of different independent teams that are simultaneously working on different parts of this application, and those application components are really shipped as independent services. And so you really have a continuous release cycle because instead of synchronizing all your teams around one particular vehicle, you have so many different release vehicles that each team is able to ship as soon as they're ready. And so we call this full cycle development because that team is really responsible not just for the coding of that microservice, but also the testing and the release and operations of that service. So this is a huge change, particularly with workflow, and there's a lot of implications for this. So I have a diagram here that just tries to visualize a little bit more the difference in organization. With the monolith, you have everyone who works on this monolith. With microservices, you have the yellow folks work on the yellow microservice and the purple folks work on the purple microservice and maybe just one person work on the orange microservice and so forth. So there's a lot more diversity around your teams and your microservices, and it lets you really adjust the granularity of your development to your specific business needs. So how do users actually access your microservices? Well, with a monolith, it's pretty straightforward. You have one big thing, so you just tell the internet, well, I have this one big thing on the internet. Make sure you send all your traffic to the big thing. But when you have microservices and you have a bunch of different microservices, how do users actually access these microservices? So the solution is an API gateway. So the API gateway consolidates all access to your microservices. So requests come from the internet. They go to your API gateway. The API gateway looks at these requests, and based on the nature of these requests, it routes them to the appropriate microservice. And because the API gateway is centralizing access to all of the microservices, it also really helps you simplify authentication, observability, routing, all these different cross-cutting concerns, because instead of implementing authentication in each of your microservices, which would be a maintenance nightmare and a security nightmare, you've put all of your authentication in your API gateway. So if you look at this world of microservices, API gateways are a really important part of your infrastructure which are really necessary, and pre-microservices, pre-Kubernetes, an API gateway, while valuable, was much more optional. So that's one of the really big things around recognizing with the microservices architecture, you really need to start thinking much more about an API gateway. The other consideration with an API gateway is around your management workflow, because as I mentioned, each team is actually responsible for their own microservice, which also means each team needs to be able to independently manage the gateway. So Team A working on that microservice needs to be able to tell the API gateway, this is how I want you to route requests to my microservice, and the purple team needs to be able to say something different for how purple requests get routed to the purple microservice. So that's also a really important consideration as you think about API gateways and how it fits in your architecture, because it's not just about your architecture, it's also about your workflow. So let me talk about API gateways on Kubernetes. I'm going to start by talking about ingress. So ingress is the process of getting traffic from the internet to services inside the cluster. Kubernetes, from an architectural perspective, it actually has a requirement that all the different pods in a Kubernetes cluster needs to communicate with each other. And as a consequence, what Kubernetes does is it creates its own private network space for all these pods, and each pod gets its own IP address. So this makes things very, very simple for interpod communication. Kubernetes, on the other hand, does not say very much around how traffic should actually get into the cluster. So there's a lot of detail around how traffic actually, once it's in the cluster, how you route it around the cluster, and it's very opinionated about how this works, but getting traffic into the cluster, there's a lot of different options and there's multiple strategies. There's Pod IP, there's Ingress, there's LoadBalancer resources, there's NodePort. I'm not going to go into exhaustive detail on all these different options, and I'm going to just talk about the most common approach that most organizations take today. So the most common strategy for routing is coupling an external load balancer with an ingress controller. And so an external load balancer can be a hardware load balancer. It can be a virtual machine. It can be a cloud load balancer. But the key requirement for an external load balancer is to be able to attach a stable IP address so that you can actually map a domain name and DNS to that particular external load balancer, and that external load balancer usually, but not always, will then route traffic and pass that traffic straight through to your ingress controller. And then your ingress controller takes that traffic and then routes it internally inside Kubernetes to the various pods that are running your microservices. There are other approaches, but this is the most common approach. And the reason for this is that the alternative approaches really require each of your microservices to be exposed outside of the cluster, which causes a lot of challenges around management and deployment and maintenance that you generally want to avoid. So I've been talking about an ingress controller. What exactly is an ingress controller? So an ingress controller is an application that can process rules according to the Kubernetes ingress specification. Strangely, Kubernetes is not actually shipped with a built-in ingress controller. I say strangely because you think, well, getting traffic into a cluster is probably a pretty common requirement, and it is. It turns out that this is complex enough that there's no one size fits all ingress controller. And so there is a set of ingress rules that are part of the Kubernetes ingress specification that specify how traffic gets routed into the cluster, and then you need a proxy that can actually route this traffic to these different pods. And so an ingress controller really translates between the Kubernetes configuration and the proxy configuration, and common proxies for ingress controllers include HAProxy, Envoy Proxy, or NGINX. So let me talk a little bit more about these common proxies. So all these proxies, and there are many other proxies. I'm just highlighting what I consider to be probably the three most well-established proxies, HAProxy, NGINX, and Envoy Proxy. So HAProxy is managed by HAProxy Technologies. Started in 2001. The HAProxy organization actually creates an ingress controller. And before they created an ingress controller, there was an open source project called Voyager which built an ingress controller on HAProxy. NGINX, managed by NGINX, Inc., subsequently acquired by F5. Also open source. Started a little bit later, the proxy, in 2004. And there's the Nginx-ingress, which is a community project. That's the most popular. As well as the Nginx, Inc. kubernetes-ingress project, which is maintained by the company. This is a common source of confusion because sometimes people will think that they're using the NGINX ingress controller, and it's not clear if they're using this commercially supported version or this open source version. And they actually, although they have very similar names, they actually have different functionality. Finally, Envoy Proxy, the newest entrant to the proxy market, originally developed by engineers at Lyft, the ride sharing company. They subsequently donated it to the Cloud Native Computing Foundation. Envoy has become probably the most popular cloud native proxy. It's used by Ambassador, the API gateway. It's used in the Istio service mesh. It's used in the VMware Contour. It's been used by Amazon in App Mesh. It's probably the most common proxy in the cloud native world. So as I mentioned, there's a lot of different options for ingress controllers. The most common is the NGINX ingress controller, not the one maintained by NGINX, Inc., but the one that's part of the Kubernetes project. Ambassador is the most popular Envoy-based option. Another common option is the Istio Gateway, which is directly integrated with the Istio mesh, and that's actually part of Docker Enterprise. So with all these choices around ingress controller, how do you actually decide? Well, the reality is the ingress specification's very limited. And the reason for this is that getting traffic into a cluster, there's a lot of nuance into how you want to do that, and it turns out it's very challenging to create a generic one size fits all specification because of the vast diversity of implementations and choices that are available to end users. And so you don't see ingress specifying anything around resilience. So if you want to specify a timeout or rate-limiting, it's not possible. Ingress is really limited to support for HTTP. So if you're using gRPC or web sockets, you can't use the ingress specification. Different ways of routing, authentication. The list goes on and on. And so what happens is that different ingress controllers extend the core ingress specification to support these use cases in different ways. So NGINX ingress, they actually use a combination of config maps and the ingress resources plus custom annotations that extend the ingress to really let you configure a lot of the additional extensions that is exposed in the NGINX ingress. With Ambassador, we actually use custom resource definitions, different CRDs that extend Kubernetes itself to configure Ambassador. And one of the benefits of the CRD approach is that we can create a standard schema that's actually validated by Kubernetes. So when you do a kub control apply of an Ambassador CRD, kub control can immediately validate and tell you if you're actually applying a valid schema and format for your Ambassador configuration. And as I previously mentioned, Ambassador's built on Envoy Proxy, Istio Gateway also uses CRDs. They can be used in extension of the service mesh CRDs as opposed to dedicated gateway CRDs. And again, Istio Gateway is built on Envoy Proxy. So I've been talking a lot about ingress controllers, but the title of my talk was really about API gateways and ingress controllers and service mesh. So what's the difference between an ingress controller and an API gateway? So to recap, an ingress controller processes Kubernetes ingress routing rules. An API gateway is a central point for managing all your traffic to Kubernetes services. It typically has additional functionality such as authentication, observability, a developer portal, and so forth. So what you find is that not all API gateways are ingress controllers because some API gateways don't support Kubernetes at all. So you can't, they can't be ingress controllers. And not all ingress controllers support the functionality such as authentication, observability, developer portal, that you would typically associate with an API gateway. So generally speaking, API gateways that run on Kubernetes should be considered a superset of an ingress controller. But if the API gateway doesn't run on Kubernetes, then it's an API gateway and not an ingress controller. So what's the difference between a service mesh and an API gateway? So an API gateway is really focused on traffic into and out of a cluster. So the colloquial term for this is North/South traffic. A service mesh is focused on traffic between services in a cluster, East/West traffic. All service meshes need an API gateway. So Istio includes a basic ingress or API gateway called the Istio Gateway, because a service mesh needs traffic from the internet to be routed into the mesh before it can actually do anything. Envoy Proxy, as I mentioned, is the most common proxy for both mesh and gateways. Docker Enterprise provides an Envoy-based solution out of the box, Istio Gateway. The reason Docker does this is because, as I mentioned, Kubernetes doesn't come package with an ingress. It makes sense for Docker Enterprise to provide something that's easy to get going, no extra steps required, because with Docker enterprise, you can deploy it and get going, get it exposed on the internet without any additional software. Docker Enterprise can also be easily upgraded to Ambassador because they're both built on Envoy. It ensures consistent routing semantics. And also with Ambassador, you get greater security for single sign-on. There's a lot of security by default that's configured directly into Ambassador. Better control over TLS, things like that. And then finally, there's commercial support that's actually available for Ambassador. Istio is an open source project that has a very broad community, but no commercial support options. So to recap, ingress controllers and API gateways are critical pieces of your cloud native stack. So make sure that you choose something that works well for you. And I think a lot of times organizations don't think critically enough about the API gateway until they're much further down the Kubernetes journey. Considerations around how to choose that API gateway include functionality such as how does it do with traffic management and observability? Does it support the protocols that you need? Also nonfunctional requirements such as does it integrate with your workflow? Do you offer commercial support? Can you get commercial support for this? An API gateway is focused on North/South traffic, so traffic into and out of your Kubernetes cluster. A service mesh is focused on East/West traffic, so traffic between different services inside the same cluster. Docker Enterprise includes Istio Gateway out of the box. Easy to use, but can also be extended with Ambassador for enhanced functionality and security. So thank you for your time. Hope this was helpful in understanding the difference between API gateways, ingress controllers, and service meshes, and how you should be thinking about that on your Kubernetes deployment.

>>thank you everyone for joining. I'm here today to talk about English controllers. AP Gateways and service mention communities three very hot topics that are also frequently confusing. So I'm Richard Lee, founder CEO of Ambassador Labs, formerly known as Data Wire. We sponsor a number of popular open source projects that are part of the Cloud Native Computing Foundation, including telepresence and Ambassador, which is a kubernetes native AP gateway. And most of what I'm going to talk about today is related to our work around ambassador. Uh huh. So I want to start by talking about application architecture, er and workflow on kubernetes and how applications that are being built on kubernetes really differ from how they used to be built. So when you're building applications on kubernetes, the traditional architectures is the very famous monolith, and the monolith is a central piece of software. It's one giant thing that you build, deployed run, and the value of a monolith is it's really simple. And if you think about the monolithic development process, more importantly, is the architecture er is really reflecting that workflow. So with the monolith, you have a very centralized development process. You tend not to release too frequently because you have all these different development teams that are working on different features, and then you decide in advance when you're going to release that particular pieces offering. Everyone works towards that release train, and you have specialized teams. You have a development team which has all your developers. You have a Q A team. You have a release team, you have an operations team, so that's your typical development organization and workflow with a monolithic application. As organization shift to micro >>services, they adopt a very different development paradigm. It's a decentralized development paradigm where you have lots of different independent teams that are simultaneously working on different parts of the application, and those application components are really shipped as independent services. And so you really have a continuous release cycle because instead of synchronizing all your teams around one particular vehicle, you have so many different release vehicles that each team is able to ship a soon as they're ready. And so we call this full cycle development because that team is >>really responsible, not just for the coding of that micro service, but also the testing and the release and operations of that service. Um, >>so this is a huge change, particularly with workflow. And there's a lot of implications for this, s o. I have a diagram here that just try to visualize a little bit more the difference in organization >>with the monolith. You have everyone who works on this monolith with micro services. You have the yellow folks work on the Yellow Micro Service, and the purple folks work on the Purple Micro Service and maybe just one person work on the Orange Micro Service and so forth. >>So there's a lot more diversity around your teams and your micro services, and it lets you really adjust the granularity of your development to your specific business need. So how do users actually access your micro services? Well, with the monolith, it's pretty straightforward. You have one big thing. So you just tell the Internet while I have this one big thing on the Internet, make sure you send all your travel to the big thing. But when you have micro services and you have a bunch of different micro services, how do users actually access these micro services? So the solution is an AP gateway, so the gateway consolidates all access to your micro services, so requests come from the Internet. They go to your AP gateway. The AP Gateway looks at these requests, and based on the nature of these requests, it routes them to the appropriate micro service. And because the AP gateway is centralizing thing access to all the micro services, it also really helps you simplify authentication, observe ability, routing all these different crosscutting concerns. Because instead of implementing authentication in each >>of your micro services, which would be a maintenance nightmare and a security nightmare, you put all your authentication in your AP gateway. So if you look at this world of micro services, AP gateways are really important part of your infrastructure, which are really necessary and pre micro services. Pre kubernetes Unhappy Gateway Well valuable was much more optional. So that's one of the really big things around. Recognizing with the micro services architecture er, you >>really need to start thinking much more about maybe a gateway. The other consideration within a P A gateway is around your management workflow because, as I mentioned, each team is actually response for their own micro service, which also means each team needs to be able to independently manage the gateway. So Team A working on that micro service needs to be able to tell the AP at Gateway. This this is >>how I want you to write. Request to my micro service, and the Purple team needs to be able to say something different for how purple requests get right into the Purple Micro Service. So that's also really important consideration as you think about AP gateways and how it fits in your architecture. Because it's not just about your architecture. It's also about your workflow. So let me talk about a PR gateways on kubernetes. I'm going to start by talking about ingress. So ingress is the process of getting traffic from the Internet to services inside the cluster kubernetes. From an architectural perspective, it actually has a requirement that all the different pods in a kubernetes cluster needs to communicate with each other. And as a consequence, what Kubernetes does is it creates its own private network space for all these pods, and each pod gets its own I p address. So this makes things very, very simple for inter pod communication. Cooper in any is, on the other hand, does not say very much around how traffic should actually get into the cluster. So there's a lot of detail around how traffic actually, once it's in the cluster, how you routed around the cluster and it's very opinionated about how this works but getting traffic into the cluster. There's a lot of different options on there's multiple strategies pot i p. There's ingress. There's low bounce of resource is there's no port. >>I'm not gonna go into exhaustive detail on all these different options on. I'm going to just talk about the most common approach that most organizations take today. So the most common strategy for routing is coupling an external load balancer with an ingress controller. And so an external load balancer can be >>ah, Harvard load balancer. It could be a virtual machine. It could be a cloud load balancer. But the key requirement for an external load balancer >>is to be able to attack to stable I people he address so that you can actually map a domain name and DNS to that particular external load balancer and that external load balancer, usually but not always well, then route traffic and pass that traffic straight through to your ingress controller, and then your English controller takes that traffic and then routes it internally inside >>kubernetes to the various pods that are running your micro services. There are >>other approaches, but this is the most common approach. And the reason for this is that the alternative approaches really required each of your micro services to be exposed outside of the cluster, which causes a lot of challenges around management and deployment and maintenance that you generally want to avoid. So I've been talking about in English controller. What exactly is an English controller? So in English controller is an application that can process rules according to the kubernetes English specifications. Strangely, Kubernetes is not actually ship with a built in English controller. Um, I say strangely because you think, well, getting traffic into a cluster is probably a pretty common requirement. And it is. It turns out that this is complex enough that there's no one size fits all English controller. And so there is a set of ingress >>rules that are part of the kubernetes English specifications at specified how traffic gets route into the cluster >>and then you need a proxy that can actually route this traffic to these different pods. And so an increase controller really translates between the kubernetes configuration and the >>proxy configuration and common proxies for ingress. Controllers include H a proxy envoy Proxy or Engine X. So >>let me talk a little bit more about these common proxies. So all these proxies and there >>are many other proxies I'm just highlighting what I consider to be probably the most three most well established proxies. Uh, h a proxy, uh, Engine X and envoy proxies. So H a proxy is managed by a plastic technology start in 2000 and one, um, the H a proxy organization actually creates an ingress controller. And before they kept created ingress controller, there was an open source project called Voyager, which built in ingress Controller on >>H a proxy engine X managed by engine. Xing, subsequently acquired by F five Also open source started a little bit later. The proxy in 2004. And there's the engine Xing breast, which is a community project. Um, that's the most popular a zwelling the engine Next Inc Kubernetes English project which is maintained by the company. This is a common source of confusion because sometimes people will think that they're using the ingress engine X ingress controller, and it's not clear if they're using this commercially supported version or the open source version, and they actually, although they have very similar names, uh, they actually have different functionality. Finally. Envoy Proxy, the newest entrant to the proxy market originally developed by engineers that lift the ride sharing company. They subsequently donated it to the cloud. Native Computing Foundation Envoy has become probably the most popular cloud native proxy. It's used by Ambassador uh, the A P a. Gateway. It's using the SDO service mash. It's using VM Ware Contour. It's been used by Amazon and at mesh. It's probably the most common proxy in the cloud native world. So, as I mentioned, there's a lot of different options for ingress. Controller is the most common. Is the engine X ingress controller, not the one maintained by Engine X Inc but the one that's part of the Cooper Nannies project? Um, ambassador is the most popular envoy based option. Another common option is the SDO Gateway, which is directly integrated with the SDO mesh, and that's >>actually part of Dr Enterprise. So with all these choices around English controller. How do you actually decide? Well, the reality is the ingress specifications very limited. >>And the reason for this is that getting traffic into the cluster there's a lot of nuance into how you want to do that. And it turns out it's very challenging to create a generic one size fits all specifications because of the vast diversity of implementations and choices that are available to end users. And so you don't see English specifying anything around resilience. So if >>you want to specify a time out or rate limiting, it's not possible in dresses really limited to support for http. So if you're using GSPC or Web sockets, you can't use the ingress specifications, um, different ways of routing >>authentication. The list goes on and on. And so what happens is that different English controllers extend the core ingress specifications to support these use cases in different ways. Yeah, so engine X ingress they actually use a combination of config maps and the English Resource is plus custom annotations that extend the ingress to really let you configure a lot of additional extensions. Um, that is exposing the engineers ingress with Ambassador. We actually use custom resource definitions different CRTs that extend kubernetes itself to configure ambassador. And one of the benefits of the CRD approach is that we can create a standard schema that's actually validated by kubernetes. So when you do a coup control apply of an ambassador CRD coop Control can immediately validate and tell >>you if you're actually applying a valid schema in format for your ambassador configuration on As I previously mentioned, ambassadors built on envoy proxy, >>it's the Gateway also uses C R D s they can to use a necks tension of the service match CRD s as opposed to dedicated Gateway C R D s on again sdo Gateway is built on envoy privacy. So I've been talking a lot about English controllers. But the title of my talk was really about AP gateways and English controllers and service smashed. So what's the difference between an English controller and an AP gateway? So to recap, an immigrant controller processes kubernetes English routing rules and a P I. G. Wave is a central point for managing all your traffic to community services. It typically has additional functionality such as authentication, observe, ability, a >>developer portal and so forth. So what you find Is that not all Ap gateways or English controllers? Because some MP gateways don't support kubernetes at all. S o eso you can't make the can't be ingress controllers and not all ingrates. Controllers support the functionality such as authentication, observe, ability, developer portal >>that you would typically associate with an AP gateway. So, generally speaking, um, AP gateways that run on kubernetes should be considered a super set oven ingress controller. But if the A p a gateway doesn't run on kubernetes, then it's an AP gateway and not an increase controller. Yeah, so what's the difference between a service Machin and AP Gateway? So an AP gateway is really >>focused on traffic into and out of a cluster, so the political term for this is North South traffic. A service mesh is focused on traffic between services in a cluster East West traffic. All service meshes need >>an AP gateway, so it's Theo includes a basic ingress or a P a gateway called the SDO gateway, because a service mention needs traffic from the Internet to be routed into the mesh >>before it can actually do anything Omelet. Proxy, as I mentioned, is the most common proxy for both mesh and gateways. Dr. Enterprise provides an envoy based solution out of the box. >>Uh, SDO Gateway. The reason Dr does this is because, as I mentioned, kubernetes doesn't come package with an ingress. Uh, it makes sense for Dr Enterprise to provide something that's easy to get going. No extra steps required because with Dr Enterprise, you can deploy it and get going. Get exposed on the Internet without any additional software. Dr. Enterprise can also be easily upgraded to ambassador because they're both built on envoy and interest. Consistent routing. Semantics. It also with Ambassador. You get >>greater security for for single sign on. There's a lot of security by default that's configured directly into Ambassador Better control over TLS. Things like that. Um And then finally, there's commercial support that's actually available for Ambassador. SDO is an open source project that has a has a very broad community but no commercial support options. So to recap, ingress controllers and AP gateways are critical pieces of your cloud native stack. So make sure that you choose something that works well for you. >>And I think a lot of times organizations don't think critically enough about the AP gateway until they're much further down the Cuban and a journey. Considerations around how to choose that a p a gateway include functionality such as How does it do with traffic management and >>observe ability? Doesn't support the protocols that you need also nonfunctional requirements such as Does it integrate with your workflow? Do you offer commercial support? Can you get commercial support for this on a P? A. Gateway is focused on north south traffic, so traffic into and out of your kubernetes cluster. A service match is focused on East West traffic, so traffic between different services inside the same cluster. Dr. Enterprise includes SDO Gateway out of the box easy to use but can also be extended with ambassador for enhanced functionality and security. So thank you for your time. Hope this was helpful in understanding the difference between a P gateways, English controllers and service meshes and how you should be thinking about that on your kubernetes deployment

>> Announcer: From around the globe, it's theCUBE with digital coverage of AWS Public Sector Partner Awards brought to you by Amazon web services. >> Hi, and welcome back. I'm Stu Miniman. This is theCUBE coverage of the AWS Public Sector Partner Awards. We going to be talking about the Customer Obsession Mission award winner. So happy to welcome to the program. First of all, welcoming back Joel Lipkin. He is the chief operating officer of Four Points Technologies, which is the winner of the aforementioned award and joining him one of his customers, Ryan Hillard, who is a assistant developer with the United States, Small Business Administration, and of course the SBA, an organization that a lot of people in the United States have gotten more familiar with this year. Joel and Ryan, thanks so much for joining us. >> Hi Stu? >> Hey Stu; Thank you. >> All right, so Ryan, I'm sorry, Joel, as I mentioned, you've been on the program, but maybe just give us a sketch if you would, Four Points, your role, your partnership with AWS. >> Sure, I'm Joel Lipkin. I'm the chief operating officer at Four Points Technology, Four Points is a value added technology reseller focused on the federal government and we've been working with federal customer since 2002. We're a service disabled veteran owned small business, and we've been in a Amazon partner since 2012. >> Wonderful; Ryan, if you could, obviously, as I mentioned, the SBA, a lot of people know for the PPP in 2020, if you could tell us a little bit about your role in your organization and tee up for us, if you would, the project that Four Points was involved with that you worked on. >> Sure; so I worked for the chief information officer and I don't have this official title, but I am the de facto manager of our Amazon Web Services presence. This year, we've had a very exciting time with what's been happening in the world, the Paycheck Protection Program, and the SBA have been kind of leveraged to help the US economy recover in the face of the pandemic. And a key part of that has been using Amazon Web Services and our partnership with Four Points Technology to launch new applications to address those requirements. >> Wonderful; Joel, maybe a connect for us. How long has Four Points been working with the SBA and start to give us a little bit more about the projects that you're working together, which I understand was predated the COVID incidents. >> Sure; we've been with SBA for several years now. And SBA was one of the earlier federal agencies that really saw the value in separating their procurement for cloud capacity, from the development implementation and managed services that they either did internally or use third party contractors for. So, Four Points came in as a true value added reseller of cloud to SBA providing cloud capacity and also Amazon professionals services. >> All right; so Ryan bring us in a little bit, the project that we're talking about here, what was the challenge? What were the goals you were looking to accomplish? Help flush out a little bit, what you're doing there? >> Yeah, so most recently Four Points partnered with us to deliver Lender Gateway. Lender Gateway is an application for small community oriented lenders to submit Paycheck Protection loans. So some of these lenders don't have giant established IT departments like big banks do, and they needed an easier way to help their customers. We built that application in six days and I called the Four Points cloud manager on a Saturday, and I said, help, help, I need two accounts by three o'clock and Four Points was there for us. We got new accounts set up. We were able to build the application and deploy it literally in a week and meet the requirements set for us. And that system has now moved billions of dollars of loans. I don't know the exact amount, but has done an incredible amount of work and it wouldn't have been possible without our partnership with Four Points. So we're really excited about that. >> Yeah, If I could drill in there for a second. Absolutely it's been an unprecedented, how fast that amount of money move through the legislature to out to the end user. Help us understand a little bit, how much were you using AWS technologies and solutions that Four Points had helped you with, and how much of this was kind of a net new, you said you built a new application, you had to activate some things fast, help us understand a little bit more. >> Yeah, that's so that's a great question. So we have five major systems in AWS today. And so we're very comfortable with AWS service offerings. What's interesting about Lender Gateway is that it's the first application we've built from scratch in a totally serverless capacity. So one of the hard technical requirements of the Paycheck Protection Program is that, it has huge amounts of demand. So when we're launching a system, we need to know that that system will not go down no matter how much traffic it receives or how many requests it has to handle. So we leaned on services like AWS Lambda, S3, dynamoDB, all of their serverless offerings to make sure that under no circumstances could this application fail. And it never did. We never even actually saw a performance degradation. So a massive success from my perspective as the program manager. >> well, that's wonderful. Joel, of course, you talk about scalability, you talk about uptime. Those are really the promise the public cloud has brought. Ryan did a good job of teeing out some of the services from AWS, but help us understand architecturally how you help put that together, and, the various pieces underneath. >> Yes Stu, it's interesting. Four Points is really focused on delivering capacity. Our delivery model is very much built around giving our customers like Ryan full control over their cloud environments so that they can use it as transparently as though they were working with Amazon directly. They have access to all of the 200+ services that AWS has. They also have a direct access to billing and usage information that lets them really optimize things. So this is sort of a perfect example of how well that works because SBA and Ryan knew their requirements better than anyone. And they were able to leverage exactly the right AWS tools without having to apply to use them. It was as though they were working directly with AWS and the AWS environment on the technology side. And I will say SBA has been really a leader in using of variety of AWS services beyond standard compute and storage, not just in a tested environment, but in a live very, very robust, really large environment. >> Yeah, right, and I was excited to hear about your Lambda usage, how you're building with the serverless architecture there. Could you just bring us through a little bit, how you ramped up on that, any tools or community solutions that you were leveraging to make sure you understood that and any lessons you learned along the way as you were building that application and rolling it out? >> Yeah, that's a great question. So I think one of the mistakes that I see program managers make all the time is thinking that they can migrate a workload to the cloud and keep it architecturally the same way it was. And what they quickly find out is that their old architecture that ran in their on premise data center might actually be more expensive in the cloud than it was in their data center. And so when you're thinking about migrating a workload, you really need to come in with the assumption that you will actually be redesigning that workload and building the system in cloud native technology. You know, the concept of Lambda is so powerful, but it didn't exist for, you know, it didn't exist 20 years ago when some of these systems and applications were being written and now being able to leverage Lambda to only use exactly the compute you need, means you can literally pay pennies on the dollar. One of the interesting things about the PPP program and everything happening in the world is that our main website, sba.gov is now serving a a hundred or a thousand times more traffic daily than it was used to doing. But because we lean on serverless technology like Lambda, we have scaled non-linearly in terms of costs. So we're only paying like two or three times more than we used to pay per month, but we're doing a hundred or a thousand times more work. That's a win, that's a huge victory for cloud technology, in my opinion. >> Yeah, and on that point, I think the other thing that SBA did really amazingly well was take advantage of first reserved instances. But I think it was the day that Amazon announced savings plans as a cost control mechanism. Ryan and SBA were on them. They were our first customer to use savings plans. And I think there were probably the first customer in the federal space to use them. So it's not just using the technology smart, it's using the cost control tools really well also. >> Yeah, so Stu, I wanted to jump in here just because I'm so glad Joel brought that up. I was describing how workloads need to morph and transform as they move from legacy setups into more cloud native ones. Well, we were the first federal agency to buy savings plans. And for folks who don't know savings plans essentially make your reserved instances fungible across services. So if you had a workload that was running on EC2 before, now instead of buying a reserved instance at a certain instant size, a certain family, you can instead buy a savings plan. And when your workload is ready to be moved from EC2 to something a little bit more containerized or cloud native, like Fargate or Lambda, then you don't actually forego your reserved instance. I see program managers get into this weird spot where they bought reserved instances, so they feel like they need to use them for a whole year. So they don't upgrade their system until their reserved instances expire. And that's really the tail wagging the dog. We were very excited about savings plans. I think we bought them four days after they came out and they have enabled us to do things like, be very ambitious with how we rethink our systems and how we rebuild them. And I'm so glad you brought that up to all because it's been such a key thing over this last year. >> Yeah, it's been a really interesting discussion point I've been having the last few years, is that the role between developers and that, that finance piece. So, Ryan, who is it that advises you on this? Is there somebody on the finance team from the SBA? is it Four Points? You know, being aware of savings plan, it was something that was announced at Reinvent, but it takes a while for that to trickle and oftentimes developers don't need to think about or think that they don't need to think about the financial implications of how they're architecting things. So how, how does that communication and decision making happen? >> That's such a great question. I think it goes back to how Four Points is customer obsessed. One of our favorite things about using a small business reseller like Four Points instead of dealing directly with our cloud service provider is that Four Points provides us a service where every quarter they do an independent assessment of our systems, how much we're spending and what that looks like from a service breakdown. And then we get that perspective and that opinion, and we enrich it with our conversation with our AWS account manager, with our finance people. But having that third party independent person come in and say, "Hey, this is what we think" has been so powerful because Joel and Dana and team have always had observations that nobody else has had. And those kinds of insights are nice to have, when you have people who are suspicious of a vendor telling you to buy more things with them, because they're the vendor >> From the lessons you've learned there, any final advice that you'd give to your peers out there, and how will you take what you've learned working on this project to other things, either in the SBA or in talking with your peers in other organizations. >> So I have two big things. So one is go use a small business reseller. I would be remiss if I didn't use this opportunity to tell you as a member of the US Small Business Administration, that there are some really, really great service providers out there. They are part of our programs like Four Points, and they can help you achieve that balance between trusting your cloud service provider and having that a third party entity that can come in and, call bowl and also call Yahtzee. So recognize good things and recognize bad things. So that would be number one. And then number two is moving to the cloud is so often sold as a technology project. And it's like 20% technology and 80% culture and workforce change. And so be honest with yourselves and your executive teams that this isn't a technology project. This is, we going to change how we do business project, and we going to change the culture of this organization kind of project. >> All right; and Joel, I'll let you have the final word on lessons learned here and also about Four Points and congratulations again, the Customer Obsession Mission award winner. >> Great, thanks Stu, we're so appreciative to Amazon for their recognition and to Ryan and SBA for giving us the opportunity to support such an important program. We are a small business, we are very much focused on delivering what our customers need in the cloud. And it's just such a tremendous feeling to be able to work on a program like this that has such, such payoff for the whole country. >> All right, Well, Joel and Ryan, thank you so much for sharing your updates, such an important project this year. Thanks so much. >> Thank you Stu. >> Thanks >> Stay with us for more covered from the AWS Public Sector Partner awards. I'm Stu Miniman, and thank you for watching theCUBE.

from the cube studios in Palo Alto in Boston connecting with thought leaders all around the world this is a cube conversation vibrator this is Dave Volante and welcome to this special cube conversation as you know I've been running a CXO series now for several weeks really trying to understand how leaders are dealing and coping with the Cova 19 crisis today we want to switch gears a little bit and talk not only about how leadership has sort of navigated through this crisis but also start to imagine what it's going to look like coming out of it I'm going to introduce you to a company that have been talking about now for the last well six to nine months company called octave as you know from my previous breaking analysis this is a company that not only is in the security business they really kind of made their mark with identification management but also really there's a data angle normally when you think about security you thinking about auto security it means that less user flexibility it means less value from the user standpoint what what octa has done really successfully is bring together both endpoint security as well as that data angle and so the company is about six hundred million dollars in revenue they've got an eighteen billion dollar valuation which you know may sound kind of rich at 30 X a revenue multiple but as I've reported the company is growing very rapidly I've talked about the you know the rule of 40 octa is really a rule of 50 type of company you know by that definition they're with me here to talk about the product side of things as dia jolly who's the chief product officer yeah thanks so much for coming on the cube I hope you're doing okay how are things out in California things are going well good to meet you as well Dave I hope you're doing well as well yeah we're hanging in there you know the studios are rocking the cube you know continues our daily reporting I want to start with your role you're relatively new to octa you've got a really interesting background particularly understanding endpoints you're at Google Google home of Google Nest you spent some time you know worrying about looking after Xbox do you a good understanding of what's going on in the marketplace but talk about your your role and how specifically you're bringing that to enterprise sure so I drove about this I I say that I've done every kind of known product management imaginable the man at this point I'm done both Hardware Don software so dealt a lot with endpoints as you talked about that a lot with sass dealt with consumer dealt with enterprise and all over the place completely different sizes so after really my role as a chief product officer is to be able to understand and what our customers need right and what are the challenges they're facing and not just the challenges they're facing today but also what are the challenges that they'll face tomorrow that they don't even know about and then help build products to be able to overcome that both with our engineering teams as well as with our sales engineering team so that we can take it to market now my background is unique because I've seen so many identity being used in so many different ways across so many different use cases whether it's enterprise or its consumer and that given that we covered both sides spectrum I can bring that to bear yes so what I've reported previously is that that you guys kind of made your mark with with identification management but in terms of both workforce but also customer identification management which has been I think allowed you to be very very successful I want to bring up a chart and share something that I've I've shared a lot of data with our audience previously some guys if you bring that up so this is data from enterprise Technology Research our data partner and for those who follow this program you know we we generally talk in in two metrics a net score which is a measure of spending momentum and and also market share which really isn't real market share but it's it's pervasiveness in the survey and what you can see here is the latest April survey from over 1200 CIOs and IT practitioners and we're isolating on an octa and and we brought it back to July 15 survey you see a couple of points here I want to make one is it something to the right this is pervasiveness or market share so octa in the market is doing very very well it's why the valuation is so high what's driving the growth and then you can see in the green a 55% net net score very very strong it's one of the leaders in security but as I said it's more than than that so dia from a product standpoint what is powering this momentum sure so as you well know the world is working from home what after does is it provides Identity Management that allows you to connect to any technology and by any technology it primarily means technology technology that's not just on premise like your applications on-premise old-school applications or into software that's on premise but it also means technology that's in the clouds of SAS applications application infrastructure that's in the cloud etc and on the other hand it also allows companies to deploy applications where they can connect to their customers online so as more and more of the world moves to work from home you need to be able to securely and seamlessly allow your employees your partners to be able to connect from their home and to be able to do their work and that's the foundation that we provide now if you look at if you we've heard a lot in the press about companies like zoom slack people that provide online collaboration and their usage has gone up we're seeing similar trends across both octa as well as the entire security industry in general right and if you look at information recently since over to started phishing attacks have increased by six hundred and sixty seven percent and what we've seen in response is one of our products which is multi-factor authentication we've experienced in eighty percent growth in usage so really as Corvette has pushed forward there was a trend for people to be able to work remotely for people to be able to access cloud apps and but as ubered has suddenly poured gas on the fire for that we're seeing our customers reaching out to us a lot more needing more support and just the level of awareness and the level of interest raising let's talk about some of the trends that you guys see in the marketplace and like to better understand how that informs your product or you know roadmap and decisions you know obviously this cloud you guys have made a really good mark in the cloud space you know with both your your operating model your pricing model the modern stack the other is a reference that upfront which data talked a lot about digital transformation digital us data course the third is purity related to trust we've talked a lot on the cube about how the perimeter is there is no particular anymore the Queen is left her castle and so what are the big trends that you see the big waves that that you're riding and how does that inform your product directly sure so a few different things I think number one if you think about the way I've phrase this is or the way I think about it is the following any big technological trend you see today right whether it's the move the cloud whether it's mobile whether it's artificial intelligence intelligence you think about the neural nets etc or it's a personalized consumer experience all of that fundamentally depends on identity so the most important the so from a from being an identity provider the most important thing for us is to be able to build something that is flexible enough that is broad enough that it is able to span multiple uses right so we've taken from a product perspective that means we can follow two philosophies we can either the try and go solve each of these pain points one by one or we can actually try to build a platform that is more open that's more extensible and that's more flexible so that we can solve many of these use cases right and not only can we solve it because there's it extensible our customers can customize it they can build on top of it our partners can build on top of it so that's one thing that's one product philosophy that we hold dear and so we have the Octagon cloud which is a platform which provides both workforce identity as well as customer identity using the same underlying components the same multi-factor authentication we use for workforce we package up as an SDK so that our customer identity customers that's number one the second thing is you rightfully mention is data you can't really secure identity without data so we have very we have a lot of data across our customers we know when the users logging in we know what device they're logging in front we know the security posture on the device we know where they're logging in from we know their different behaviors were apps they go into or during wartime of the day etc so being able to harness all this data to say hey and apply ml model squared to say hey is the user secure or not is a very very core foundation of our product so for example we have what we call risk-based authentication you can not only do things like hey this user seems to be logging on from a location they've never logged on from but you could even do things like well you may not want to stop the user they may be traveling so instead of just asking them for a for a password you ask them for a multi-factor right so that's the other piece of it and in many ways data and security and usability are three legs of a triangle the more data you have the more you can allow a user you more security you can provide a user without creating more friction so it's sometimes helpful for the audience to understand a company in a edit Avant act in the landscape so the obvious platform out there is Active Directory now Microsoft with Azure Active Directory you know really you know trying to and and that's really been on their platforms but with api's you know Microsoft has got a thumbs in every pie how does octave differentiate from some of the other traditional platforms that are out there and and what gives you confidence that it and you can continue to do so going forward post kovat that's it that's a fantastic question Dave um so I think we divide if you think about our competitors on the workforce side we've got Microsoft and a couple of other competitors and on the customer Identity side really it's a bill versus buy story right most companies customer identity internally so let's take workforce first Microsoft is the dominant player there they've got Active Directory they've now got Azure Active Directory and from a Microsoft perspective I think Microsoft is always been great at building products or building technology that interconnected run the world is going to more there's more and more technology proliferation in the world and the way we differentiate is by becoming a neutral and independent platform so whether you're on a Microsoft stack whether you're on a Google stack whether you're on an amazon stack we are able to connect with you deeply we connect just as well with all 365 as they connect with Salesforce as we connect with AWS right and that has been our core philosophy and not only is that a philosophy for other when other vendors it's a philosophy for ourselves as well we have multi-factor authentication so do many other providers like duo if you want to use ours great if you don't want to use ours with our platform who use the one that's best for your technology and I think what we've always believed in from a product perspective is this independence this neutrality this ability to plug-and-play any technology you want into a platform to be able to do what you want and the technology that's best for your business's need so what's interesting what you said about the sort of make versus buy that's particularly relevant for the customer identification management because let's say you know I'm buying from Amazon I've got Amazon they know who I am but if I understand it correctly customers now are able to look across brands maybe cohort selling maybe make specific offers analyze the data that's an advantage that you bring that maybe do it yourself doesn't Frank maybe talk about that a little bit sure so really if you think about if you think about a bill versus buying even ten years ago life used to be relatively simple maybe 15 years ago you had a website you as your username your the password you weren't really using you don't have multiple channels you didn't have multiple devices as prevalent you didn't have multiple apps in a lot of cases connected to each other right and in that in that day and age password was fairly secure you weren't doing a lot of personalization with the user data or had a lot of sensitive user data so building a custom identity solution having your customer managing your customers identity yourself was fairly easy now it's becoming more and more hard number one I just talked about the phishing attacks they're an equal number of attacks on the customer identity side right so how do you actually secure this identity how do you actually use things like multi-factor authentication how do you keep up with all the latest in multi-factor authentication touch ID face ID etcetera and that's one the second thing we provide is scale for a number of companies we also provide the ability to scale dramatically which scaling identity and being being able to authenticate someone and keep someone authenticated in real time is actually a very big channel challenge as you get to more and more scale and then the last thing that you mentioned is this ability we provide a single view of the user which is super super powerful because now if you think about one of our customers Albertsons they have multiple different apps there are multiple different digital experiences and he don't have a siloed view of their customer across all these experiences here one identity for your customer that customer uses that one identity to log on to all your digital experiences across all channels and we're able to bring that data back together so if Albertsons wants to say hey somebody shot a in or bought something in one particular app but I know people that buy this particular object like something else that's available in another app they can give a promotion for it or they can give a discomfort that's so that makes a lot of sense I went into the PR platform get our data partner and I looked at which industries are really showing moment so remember this survey focus was run right in the heart of the the Cova 19 pandemic from from mid-march the mid April so it's a good of good current data point and there were four that stood out large companies healthcare and pharma telco which is courses this work-from-home thing and then consumer the example that you just gave from Albertsons is really you know sort of around that consumer there are a lot of industries that obviously been hit airlines restaurants hospitality but but these four really stood out as growth areas despite the kovat 19 pandemic I want to ask you about octane you just got it had your big user conference anything product specific that came out of that that our audience should know about I mean I'm an interested in access gateway I know that wasn't necessarily a new announcement but Cloud Gateway what were the highlights of some of those things from a product stamp yeah of course so we did we did made a very difficult decision to pivot octane virtually and we did this because a number of our customers are given what they're facing with the Kovach pandemic wanted to hear more around news around what our product launches are how they could use this with cetera and really I'd say there are three key product launches that I want to highlight here we had a number of different announcements and it was a very successful conference but the three that are the most relevant here one is we've always talked about being a platform and we've set this for the past four or five years I think and but over the last your and going into the next couple of years we're investing very very heavily in making our platform even more powerful even more extensible even more customizable and so that it can go across the scenarios you described right which is whether you're on Prem with Auto access gateway or you're in the cloud or in some kind of hybrid environment or you using some mix-and-match or work from home people in the office etc so really what we did this year over the last year was deepen our platform footprint and we started releasing the four components available in a platform which we call platform services so we have six components and we were directories that is customizable and and flexible so you can build your own emails except for N equals four users adds information related to them we have an integration platform that we've made available at a deep level where where our customers can use SDKs tools etc to be able to integrate with octa in a platform which we've talked a lot about and then we released three new platform services and one was what we call arc identity engine we had released we talked about this last year and this year we talked about it last year from a customer identity perspective this year we brought her into our workforce identity but also what that does is it allows you a lot more flexibility for situations like we're in right it allows you flexibility to define security policies at the parabola it so you could decide hey for my email I don't want my customers to have to use a multi-factor authentication for but for Salesforce I would definitely want them to use a multi-factor authentication if they're not in the office and it also allows you to have a lot more flexible factor recovery so for example if you forgot your password one of the biggest pain points of co-ed has been the number of helpdesk costs have been rising through the roof the phone calls are ringing nonstop right and one of the biggest reasons for helpdesk are says oh I can't login I got locked out either lost a factor or L forgot my password it helps with that um so that's one set of announcements the second set of announcements was we launched a brand new devices platform and personally this is my personal favorite but really what the devices platform allows you to do is the feature in it that we launched is called Fast Pass and what phosphorous allows you to do is it actually takes phosphorous to the next level it allows you to basically use logging into your device and us understanding the posture of the device and all the user context around you to be able to log you directly dr. then I imagine if you're on a Mac or a iOS device or an Android or a Windows device just being able to face match into your iOS or being able to touch ID into your Windows hello and you're automatically logged into lockdown right that is that and and the way we do that is we have this client on across all these operating systems that can really understand the security posture of the device it can understand of the device is managed if it's safe if it's jailbroken if it's unmanaged it can also connect with multiple signals on the device so if you have an EDR and MDM vendor we can ingest those signals and what they think of the risk we can also ingest signals directly from apps if apps things like um G suite and Salesforce actually track user behavior to determine risk they can pass those signals to us and then we can make a decision on hey we should allow the user to authenticate directly into octa because they've authenticated their device which we can make a decision that says no let's provider let's ask them to step up with a multi-factor authentication or we can say no this is too risky let's deny access and all of this is configurable by the IT admin they can decide the risk levels they're comfortable with they can decide the different risk levels by different apps so that was another major announcement and then and as a product person you rarely ever get the chance to actually increase security and usability at one time which is why it's my favorite you increase both security and usability together now the last one was action was a workflows engine we call it workflows lifecycle management and we it's really we launched a graphical no cord user interface identity is so important so many business processes for our customers there's so many business processes built an identity for example if someone joins her company you usually either have a script that allows them access to the applications they need to or you actually have an IT admin sitting in there trying to manually provide access or when they leave right what workflow lifecycle management or lifecycle management workflows allows you to do is it actually allows you to provide it actually provides you the no core graphical user interface where you can build all these flows so now you don't need someone that knows coding you can even have a business unit so for example I for me in the product for the product org I can have someone say hey building a business process similar it's something you would build in sort of like an iPad and allow everyone that comes in to be able to have access to fig mom because we use pigma a lot right those are the kinds of things you can do and it's super powerful and it takes the ability of our already existing lifecycle management product to the next level well thank you for that that's that summary dear so I want to kind of close with I mean those of you have been following the cube for a while there I think there's some similarities between octa and and and service now that obviously obvious differences but we started following you know ServiceNow pre-ipo is less than a hundred million dollar company and we've seen that company build out as a platform company and that's really what octa is doing here we're talking about a total available market that's yeah probably north of 50 billion so the the question I have he is you know what Frederic and pod started 11 years ago playing on the dynamics coming out of the financial crisis that got us to where we are today now you've got the challenge of you've achieved reached escape velocity now you've got this you know massive growth opportunity in front of you how do you see the product portfolio evolving expanding and I'm also interested in postcode with 19 you know no whiteboards no face-to-face contact not at least not for a while and how you're kind of managing through that but but how can we expect the product portfolio to expand over time what can you share with us so one of the given how pervasive identity has become and given how not just broad but at the same time deep it is there are multiple different places or product portfolio >> and a number of different places were thinking about right so one is you mentioned today we play in workforce identity and customer identity but we haven't even begun to talk about how we might play in consumer right one of the one of the biggest perk matter is consumers and consumers protecting their own identity so often an employee is not using their identity to lock the seals ports and you have an attack on a company and offered an employee actually logging into their Gmail their personal Gmail or their personal or some personal website that bank and they get and their credential get compromised in their fluency impossible so the more protective the more directly consumers the more we indirectly protect both enterprises from work from an employer as well as a customer perspective howdy we're an enterprise company so it doesn't mean that we are going to go direct to consumer there are ways to make employees more secure by what the director calls were so that's one the second thing is managing identities I think we've as the number of applications as the number of technologies are proliferate managing and an employee's life cycle who that governing that the life cycle is not administering etc is also fully stock also becoming very very challenging it was all well and good we'll never can ask and you were on that that's not true anymore an average company uses I think close to 200 applications and then if you broaden back to other resources like infrastructure there's a lot lock more so how do you actually build automated systems that based on the employee status based on their rule based on the project they're on provides them the right access for the right amount of time the third thing you mentioned is and you should pass on this initially but this is the there's this concept of zero security right and the perimeters disappeared how do you provide security so if you look at the industry at large today there are tons of different security vendors trying to provide security at each point if you talk to any see-saw out there it's really really hard to cobble all of this together and one of the things we were trying to do is we're trying to figure out how with our partners we can build a silly end-to-end solution for n - n zero trust for our customers so that's that's another area that the of the product portfolio we're pushing and then finally with the whole digital transformation and customer identity yes more and more companies want their customers to go back online yes more and more customers convenience of being able to interact online with Billy if you think about it the world has changed dramatically over the last three years with privacy laws with things like gdpr CCP etc how do you actually manage your customers obviously you actually manage their content how do you ensure that while you're using all this data from across these apps that we talked about here you and you're using for the first benefit how do you make sure that the minister private is secure and and how do you ensure your customers that's another major area that I think our customers are asking us for helping and so those are areas or so that you should be a big signature the next two to three years some of it will be through partnership that's generally that high-level directions we're headed in wealthy you so much for coming on the key on the key and sharing the product roadmap and some other details about the great company really interested in watching its continued ascendancy good luck in the marketplace and thank you for watching everybody this is Dave Villante you conversations we'll see you next time [Music]

(electronic music) >> From Santa Clara, California in the heart of Silicon Valley, its theCUBE. Covering Altitude 2020, brought to you by Aviatrix. (electronic music) >> Female pilot: Good morning, ladies and gentlemen, this is your captain speaking, we will soon be taking off on our way to altitude. (upbeat music) Please keep your seat belts fastened and remain in your seat. We will be experiencing turbulence, until we are above the clouds. (thunder blasting) (electronic music) (seatbelt alert sounds) Ladies and gentlemen, we are now cruising at altitude. Sit back and enjoy the ride. (electronic music) >> Female pilot: Altitude is a community of thought leaders and pioneers, cloud architects and enlightened network engineers, who have individually and are now collectively, leading their own IT teams and the industry. On a path to lift cloud networking above the clouds. Empowering enterprise IT to architect, design and control their own cloud network, regardless of the turbulent clouds beneath them. It's time to gain altitude. Ladies and gentlemen, Steve Mullaney, president and CEO of Aviatrix. The leader of multi-cloud networking. (electronic music) (audience clapping) >> Steve: All right. (audience clapping) Good morning everybody, here in Santa Clara as well as to the millions of people watching the livestream worldwide. Welcome to Altitude 2020, all right. So, we've got a fantastic event, today, I'm really excited about the speakers that we have today and the experts that we have and really excited to get started. So, one of the things I wanted to share was this is not a one-time event. This is not a one-time thing that we're going to do. Sorry for the Aviation analogy, but, you know, Sherry Wei, aviatrix means female pilot so everything we do has an aviation theme. This is a take-off, for a movement. This isn't an event, this is a take-off of a movement. A multi-cloud networking movement and community that we're inviting all of you to become part of. And why we're doing that, is we want to enable enterprises to rise above the clouds, so to speak and build their network architecture, regardless of which public cloud they're using. Whether it's one or more of these public clouds. So the good news, for today, there's lots of good news but this is one good news, is we don't have any PowerPoint presentations, no marketing speak. We know that marketing people have their own language. We're not using any of that, and no sales pitches, right? So instead, what are we doing? We're going to have expert panels, we've got Simon Richard, of Gartner here. We've got ten different network architects, cloud architects, real practitioners that are going to share their best practices and their real world experiences on their journey to the multi-cloud. So, before we start, everybody know what today is? In the U.S., it's Super Tuesday. I'm not going to get political, but Super Tuesday there was a bigger, Super Tuesday that happened 18 months ago. And Aviatrix employees know what I'm talking about. Eighteen months ago, on a Tuesday, every enterprise said, "I'm going to go to the cloud". And so what that was, was the Cambrian explosion, for cloud, for the enterprise. So, Frank Cabri, you know what a Cambrian explosion is. He had to look it up on Google. 500 million years ago, what happened, there was an explosion of life where it went from very simple single-cell organisms to very complex, multi-cell organisms. Guess what happened 18 months ago, on a Tuesday, I don't really know why, but every enterprise, like I said, all woke up that day and said, "Now I'm really going to go to cloud" and that Cambrian explosion of cloud meant that I'm moving from a very simple, single cloud, single-use case, simple environment, to a very complex, multi-cloud, complex use case environment. And what we're here today, is we're going to go undress that and how do you handle those, those complexities? And, when you look at what's happening, with customers right now, this is a business transformation, right? People like to talk about transitions, this is a transformation and it's actually not just a technology transformation, it's a business transformation. It started from the CEO and the Boards of enterprise customers where they said, "I have an existential threat to the survival of my company." If you look at every industry, who they're worried about is not the other 30-year-old enterprise. What they're worried about is the three year old enterprise that's leveraging cloud, that's leveraging AI, and that's where they fear that they're going to actually wiped out, right? And so, because of this existential threat, this is CEO led, this is Board led, this is not technology led, it is mandated in the organizations. We are going to digitally transform our enterprise, because of this existential threat and the movement to cloud is going to enable us to go do that. And so, IT is now put back in charge. If you think back just a few years ago, in cloud, it was led by DevOps, it was led by the applications and it was, like I said, before the Cambrian explosion, it was very simple. Now, with this Cambrian explosion, an enterprise is getting very serious and mission critical. They care about visibility, they care about control, they care about compliance, conformance, everything, governance. IT is in charge and that's why we're here today to discuss that. So, what we're going to do today, is much of things but we're going to validate this journey with customers. >> Steve: Did they see the same thing? We're going to validate the requirements for multi-cloud because, honestly, I've never met an enterprise that is not going to be multicloud. Many are one cloud today but they all say, " I need to architect my network for multiple clouds", because that's just what, the network is there to support the applications and the applications will run in whatever cloud it runs best in and you have to be prepared for that. The second thing is, is architecture. Again, with IT in charge, you, architecture matters. Whether its your career, whether its how you build your house, it doesn't matter. Horrible architecture, your life is horrible forever. Good architecture, your life is pretty good. So, we're going to talk about architecture and how the most fundamental and critical part of that architecture and that basic infrastructure is the network. If you don't get that right, nothing works, right? Way more important than compute. Way more important than storage. Network is the foundational element of your infrastructure. Then we're going to talk about day two operations. What does that mean? Well day one is one day of your life, where you wire things up they do and beyond. I tell everyone in networking and IT -- it's every day of your life. And if you don't get that right, your life is bad forever. And so things like operations, visibility, security, things like that, how do I get my operations team to be able to handle this in an automated way because it's not just about configuring it in the cloud, it's actually about how do I operationalize it? And that's a huge benefit that we bring as Aviatrix. And then the last thing we're going to talk and it's the last panel we have, I always sayyou can't forget about the humans, right? So all this technology, all these things that we're doing, it's always enabled by the humans. At the end of the day, if the humans fight it, it won't get deployed. And we have a massive skills gap, in cloud and we also have a massive skills shortage. You have everyone in the world trying to hire cloud network architects, right? There's just not enough of them going around. So, at Aviatrix, we said as leaders do, "We're going to help address that issue and try to create more people." We created a program, what we call the ACE Program, again, aviation theme, it stands for Aviatrix Certified Engineer. Very similar to what Cisco did with CCIEs where Cisco taught you about IP networking, a little bit of Cisco, we're doing the same thing, we're going to teach network architects about multicloud networking and architecture and yeah, you'll get a little bit of Aviatrix training in there, but this is the missing element for people's careers and also within their organizations. So we're going to go talk about that. So, great, great event, great show. We're going to try to keep it moving. I next want to introduce, my host, he is the best in the business, you guys have probably seen him multiple, many times, he is the co-CEO and co founder of theCUBE, John Furrier. (audience clapping) (electronic music) >> John: Okay, awesome, great speech there, awesome. >> Yeah. >> I totally agree with everything you said about the explosion happening and I'm excited, here at the heart of silicon valley to have this event. It's a special digital event with theCUBE and Aviatrix, where we're live-streaming to, millions of people, as you said, maybe not a million. >> Maybe not a million. (laughs) Really to take this program to the world and this is really special for me, because multi-cloud is the hottest wave in cloud. And cloud-native networking is fast becoming the key engine, of the innovations, so we got an hour and a half of action-packed programming. We have a customer panel. Two customer panels. Before that Gartner's going to come out, talk about the industry. We have global system integrators, that will talk about, how their advising and building these networks and cloud native networking. And then finally the ACE's, the Aviatrix Certified Engineers, are going to talk more about their certifications and the expertise needed. So, let's jump right in, let's ask, Simon Richard to come on stage, from Gartner. We'll kick it all off. (electronic music) (clapping) >> John: Hi, can I help you. Okay, so kicking things off, getting started. Gartner, the industry experts on cloud. Really kind of more, cue your background. Talk about your background before you got to Gartner? >> Simon: Before being at Gartner, I was a chief network architect, of a Fortune 500 company, that with thousands of sites over the world and I've been doing everything in IT from a C programmer, in the 90, to a security architect, to a network engineer, to finally becoming a network analyst. >> So you rode the wave. Now you're covering the marketplace with hybrid cloud and now moving quickly to multi-cloud, is really what everyone is talking about. >> Yes. >> Cloud-native's been discussed, but the networking piece is super important. How do you see that evolving? >> Well, the way we see Enterprise adapting, cloud. The first thing you do about networking, the initial phases they either go in a very ad hoc way. Is usually led by none IT, like a shadow IT, or application people, sometime a DevOps team and it just goes as, it's completely unplanned. They create VPC's left and right with different account and they create mesh to manage them and they have Direct Connect or Express Route to any of them. So that's the first approach and on the other side. again within our first approach you see what I call, the lift and shift. Where we see like enterprise IT trying to, basically replicate what they have in a data center, in the Cloud. So they spend a lot of time planning, doing Direct Connect, putting Cisco routers and F5 and Citrix and any checkpoint, Palo Alto device, that in a sense are removing that to the cloud. >> I got to ask you, the aha moment is going to come up a lot, in one our panels, is where people realize, that it's a multi-cloud world. I mean, they either inherit clouds, certainly they're using public cloud and on-premises is now more relevant than ever. When's that aha moment? That you're seeing, where people go, "Well I got to get my act together and get on this cloud." >> Well the first, right, even before multi-cloud. So there is two approach's. The first one, like the adult way doesn't scare. At some point IT has to save them, 'cause they don't think about the tools, they don't think about operation, they have a bunch of VPC and multiple cloud. The other way, if you do the lift and shift way, they cannot take any advantages of the cloud. They lose elasticity, auto-scaling, pay by the drink. All these agility features. So they both realize, okay, neither of these ways are good, so I have to optimize that. So I have to have a mix of what I call, the cloud native services, within each cloud. So they start adapting, like all the AWS Construct, Azure Construct or Google Construct and that's what I call the optimal phase. But even that they realize, after that, they are all very different, all these approaches different, the cloud are different. Identities is constantly, difficult to manage across clouds. I mean, for example, anybody who access' accounts, there's subscription, in Azure and GCP, their projects. It's a real mess, so they realized, well I don't really like constantly use the cloud product and every cloud, that doesn't work. So I have, I'm going multi-cloud, I like to abstract all of that. I still want to manage the cloud from an EPI point of view, I don't necessarily want to bring my incumbent data center products, but I have to do that and in a more EPI driven cloud environment. >> So, the not scaling piece that you where mentioning, that's because there's too many different clouds? >> Yes. >> That's the least they are, so what are they doing? What are they, building different development teams? Is it software? What's the solution? >> Well, the solution is to start architecting the cloud. That's the third phase. I called that the multi-cloud architect phase, where they have to think about abstraction that works across cloud. Fact, even across one cloud it might not scale as well, If you start having like ten thousand security agreement, anybody who has that doesn't scale. You have to manage that. If you have multiple VPC, it doesn't scale. You need a third-party, identity provider. In variously scales within one cloud, if you go multiple cloud, it gets worse and worse. >> Steve, weigh in here. What's your thoughts? >> I thought we said this wasn't going to be a sales pitch for Aviatrix. (laughter) You just said exactly what we do, so anyway, that's a joke. What do you see in terms of where people are, in that multi-cloud? So, like lot of people, you know, everyone I talk to, started at one cloud, right, but then they look and then say okay but I'm now going to move to Azure and I'm going to move to... (trails off) Do you see a similar thing? >> Well, yes. They are moving but there's not a lot of application, that uses three cloud at once, they move one app in Azure, one app in AWS and one app in Google. That's what we see so far. >> Okay, yeah, one of the mistakes that people think, is they think multi-cloud. No one is ever going to go multi-cloud, for arbitrage. They're not going to go and say, well, today I might go into Azure, 'cause I get a better rate on my instance. Do you agree? That's never going to happen. What I've seen with enterprise, is I'm going to put the workload in the app, the app decides where it runs best. That may be Azure, maybe Google and for different reasons and they're going to stick there and they're not going to move. >> Let me ask you guys-- >> But the infrastructure, has to be able to support, from a networking team. >> Yes. >> Be able to do that. Do you agree with that? >> Yes, I agree. And one thing is also very important, is connecting to the cloud, is kind of the easiest thing. So, the wide area network part of the cloud, connectivity to the cloud is kind of simple. >> Steve: I agree. >> IP's like VPN, Direct Connect, Express Route. That's the simple part, what's difficult and even the provisioning part is easy. You can use Terraform and create VPC's and Vnet's across your three cloud provider. >> Steve: Right. >> What's difficult is that they choose the operation. So we'll define day two operation. What does that actually mean? >> Its just the day to day operations, after you know, the natural, lets add an app, lets add a server, lets troubleshoot a problem. >> Something changes, now what do you do? >> So what's the big concerns? I want to just get back to the cloud native networking, because everyone kind of knows what cloud native apps are. That's been the hot trend. What is cloud native networking? How do you guys, define that? Because that seems to be the hardest part of the multi-cloud wave that's coming, is cloud native networking. >> Well there's no, you know, official Gartner definition but I can create one on the spot. >> John: Do it. (laughter) >> I just want to leverage the Cloud Construct and the cloud EPI. I don't want to have to install, like a... (trails off) For example, the first version was, let's put a virtual router that doesn't even understand the cloud environment. >> Right. If I have if I have to install a virtual machine, it has to be cloud aware. It has to understand the security group, if it's a router. It has to be programmable, to the cloud API. And understand the cloud environment. >> And one thing I hear a lot from either CSO's, CIO's or CXO's in general, is this idea of, I'm definitely not going API. So, its been an API economy. So API is key on that point, but then they say. Okay, I need to essentially have the right relationship with my suppliers, aka you called it above the clouds. So the question is... What do I do from an architectural standpoint? Do I just hire more developers and have different teams, because you mentioned that's a scale point. How do you solve this problem of, okay, I got AWS, I got GCP, or Azure, or whatever. Do I just have different teams or do I just expose EPI's? Where is that optimization? Where's the focus? >> Well, I think what you need, from a network point of view is a way, a control plane across the three clouds. And be able to use the API's of the cloud, to build networks but also to troubleshoot them and do day to day operation. So you need a view across the three clouds, that takes care of routing, connectivity. >> Steve: Performance. >> John: That's the Aviatrix plugin, right there. >> Steve: Yeah. So, how do you see, so again, your Gartner, you see the industry. You've been a network architect. How do you see this this playing out? What are the legacy incumbent client server, On Prem networking people, going to do? >> Well they need to.. >> Versus people like a Aviatrix? How do you see that playing out? >> Well obviously, all the incumbents, like Arista, Cisco, Juniper, NSX. >> Steve: Right. >> They want to basically do the lift and shift part, they want to bring, and you know, VMware want to bring in NSX on the cloud, they call that "NSX everywhere" and Cisco want to bring in ACI to the cloud, they call that "ACI Anywhere". So, everyone's.. (trails off) And then there's CloudVision from Arista, and Contrail is in the cloud. So, they just want to bring the management plane, in the cloud, but it's still based, most of them, is still based on putting a VM in them and controlling them. You extend your management console to the cloud, that's not truly cloud native. >> Right. >> Cloud native you almost have to build it from scratch. >> We like to call that cloud naive. >> Cloud naive, yeah. >> So close, one letter, right? >> Yes. >> That was a big.. (slurs) Reinvent, take the T out of Cloud Native. It's Cloud Naive. (laughter) >> That went super viral, you guys got T-shirts now. I know you're loving that. >> Steve: Yeah. >> But that really, ultimately, is kind of a double-edged sword. You can be naive on the architecture side and ruleing that. And also suppliers or can be naive. So how would you define who's naive and who's not? >> Well, in fact, their evolving as well, so for example, in Cisco, it's a little bit more native than other ones, because there really is, "ACI in the cloud", you can't really figure API's out of the cloud. NSX is going that way and so is Arista, but they're incumbent, they have their own tools, its difficult for them. They're moving slowly, so it's much easier to start from scratch. Even you, like, you know, a network company that started a few years ago. There's only really two, Aviatrix was the first one, they've been there for at least three or four years. >> Steve: Yeah. >> And there's other one's, like Akira, for example that just started. Now they're doing more connectivity, but they want to create an overlay network, across the cloud and start doing policies and things. Abstracting all the clouds within one platform. >> So, I got to ask you. I interviewed an executive at VMware, Sanjay Poonen, he said to me at RSA last week. Oh, there'll only be two networking vendors left, Cisco and VMware. (laughter) >> What's you're response to that? Obviously when you have these waves, these new brands that emerge, like Aviatrix and others. I think there'll be a lot of startups coming out of the woodwork. How do you respond to that comment? >> Well there's still a data center, there's still, like a lot, of action on campus and there's the wan. But from the cloud provisioning and cloud networking in general, I mean, they're behind I think. You know, you don't even need them to start with, you can, if you're small enough, you can just keep.. If you have AWS, you can use the AWS construct, they have to insert themselves, I mean, they're running behind. From my point of view. >> They are, certainly incumbents. I love the term Andy Jess uses at Amazon web services. He uses "Old guard, new guard", to talk about the industry. What does the new guard have to do? The new brands that are emerging. Is it be more DevOp's oriented? Is it NetSec ops? Is it NetOps? Is it programmability? These are some of the key discussions we've been having. What's your view, on how you see this programmability? >> The most important part is, they have to make the network simple for the Dev teams. You cannot make a phone call and get a Vline in two weeks anymore. So if you move to the cloud, you have to make that cloud construct as simple enough, so that for example, a Dev team could say, "Okay, I'm going to create this VPC, but this VPC automatically associates your account, you cannot go out on the internet. You have to go to the transit VPC, so there's lot of action in terms of, the IAM part and you have to put the control around them to. So to make it as simple as possible. >> You guys, both. You're the CEO of Aviatrix, but also you've got a lot of experience, going back to networking, going back to the, I call it the OSI days. For us old folks know what that means, but, you guys know what this means. I want to ask you the question. As you look at the future of networking, you hear a couple objections. "Oh, the cloud guys, they got networking, we're all set with them. How do you respond to the fact that networking's changing and the cloud guys have their own networking. What's some of the paying points that's going on premises of these enterprises? So are they good with the clouds? What needs... What are the key things that's going on in networking, that makes it more than just the cloud networking? What's your take on it? >> Well as I said earlier. Once you could easily provision in the cloud, you can easily connect to the cloud, its when you start troubleshooting applications in the cloud and try to scale. So that's where the problem occurred. >> Okay, what's your take on it. >> And you'll hear from the customers, that we have on stage and I think what happens is all the clouds by definition, designed to the 80-20 rule which means they'll design 80% of the basic functionality. And then lead to 20% extra functionality, that of course every Enterprise needs, to leave that to ISV's, like Aviatrix. Because why? Because they have to make money, they have a service and they can't have huge instances, for functionality that not everybody needs. So they have to design to the common and that, they all do it, right? They have to and then the extra, the problem is, that Cambrian explosion, that I talked about with enterprises. That's what they need. They're the ones who need that extra 20%. So that's what I see, there's always going to be that extra functionality. In an automated and simple way, that you talked about, but yet powerful. With the up with the visibility and control, that they expect of On Prem. That kind of combination, that Yin and the Yang, that people like us are providing. >> Simon I want to ask you? We're going to ask some of the cloud architect, customer panels, that same question. There's pioneer's doing some work here and there's also the laggards who come in behind their early adopters. What's going to be the tipping point? What are some of these conversations, that the cloud architects are having out there? Or what's the signs, that they need to be on this, multi-cloud or cloud native networking trend? What are some of the signal's that are going on in the environment? What are some of the thresholds? Are things that are going on, that they can pay attention to? >> Well, once they have the application on multiple cloud and they have to get wake up at two in the morning, to troubleshoot them. They'll know it's important. (laughter) So, I think that's when the rubber will hit the road. But, as I said, it's easier to prove, at any case. Okay, it's AWS, it's easy, user transit gateway, put a few VPC's and you're done. And you create some presents like Equinox and do a Direct Connect and Express Route with Azure. That looks simple, its the operations, that's when they'll realize. Okay, now I need to understand! How cloud networking works? I also need a tool, that gives me visibility and control. But not only that, I need to understand the basic underneath it as well. >> What are some of the day in the life scenarios. you envision happening with multi-cloud, because you think about what's happening. It kind of has that same vibe of interoperability, choice, multi-vendor, 'cause they're multi-cloud. Essentially multi-vendor. These are kind of old paradigms, that we've lived through with client server and internet working. What are some of the scenarios of success, that might be possible? Will be possible, with multi-cloud and cloud native networking. >> Well, I think, once you have good enough visibility, to satisfy your customers, not only, like to, keep the service running and application running. But to be able to provision fast enough, I think that's what you want to achieve. >> Simon, final question. Advice for folks watching on the Livestream, if they're sitting there as a cloud architect or CXO. What's your advice to them right now, in this market, 'cause obviously, public cloud check, hybrid cloud, they're working on that. That gets on premises done, now multi-cloud's right behind it. What's your advice? >> The first thing they should do, is really try to understand cloud networking. For each of their cloud providers and then understand the limitations. And, is what the cloud service provider offers enough? Or you need to look to a third party, but you don't look at a third party to start with. Especially an incumbent one, so it's tempting to say "I have a bunch of F5 experts", nothing against F5. I'm going to bring my F5 in the Cloud, when you can use an ELB, that automatically understand eases and auto scaling and so on. And you understand that's much simpler, but sometimes you need your F5, because you have requirements. You have like iRules and that kind of stuff, that you've used for years. 'cause you cannot do it. Okay, I have requirement and that's not met, I'm going to use Legacy Star and then you have to start thinking, okay, what about visibility control, above the true cloud. But before you do that you have to understand the limitations of the existing cloud providers. First, try to be as native as possible, until things don't work, after that you can start thinking of the cloud. >> Great insight, Simon. Thank you. >> That's great. >> With Gartner, thank you for sharing. (electronic music) >> Welcome back to ALTITUDE 2020. For the folks in the live stream, I'm John Furrier, Steve Mullaney, CEO of Aviatrix. For our first of two customer panels with cloud network architects, we've got Bobby Willoughby, AEGON Luis Castillo from National Instruments and David Shinnick with FactSet. Guys, welcome to the stage for this digital event. Come on up. (audience clapping) (upbeat music) Hey good to see you, thank you. Customer panel, this is my favorite part. We get to hear the real scoop, we get the Gardener giving us the industry overview. Certainly, multi-cloud is very relevant, and cloud-native networking is a hot trend with the live stream out there in the digital events. So guys, let's get into it. The journey is, you guys are pioneering this journey of multi-cloud and cloud-native networking and are soon going to be a lot more coming. So I want to get into the journey. What's it been like? Is it real? You've got a lot of scar tissue? What are some of the learnings? >> Absolutely. Multi-cloud is whether or not we accept it, as network engineers is a reality. Like Steve said, about two years ago, companies really decided to just bite the bullet and move there. Whether or not we accept that fact, we need to not create a consistent architecture across multiple clouds. And that is challenging without orchestration layers as you start managing different tool sets and different languages across different clouds. So it's really important to start thinking about that. >> Guys on the other panelists here, there's different phases of this journey. Some come at it from a networking perspective, some come in from a problem troubleshooting, what's your experiences? >> From a networking perspective, it's been incredibly exciting, it's kind of once in a generational opportunity to look at how you're building out your network. You can start to embrace things like infrastructure as code that maybe your peers on the systems teams have been doing for years, but it just never really worked on-prem. So it's really exciting to look at all the opportunities that we have and all of the interesting challenges that come up that you get to tackle. >> And effects that you guys are mostly AWS, right? >> Yeah. Right now though, we are looking at multiple clouds. We have production workloads running in multiple clouds today but a lot of the initial work has been with Amazon. >> And you've seen it from a networking perspective, that's where you guys are coming at it from? >> Yup. >> Awesome. How about you? >> We evolve more from a customer requirement perspective. Started out primarily as AWS, but as the customer needed more resources from Azure like HPC, Azure AD, things like that, even recently, Google analytics, our journey has evolved into more of a multi-cloud environment. >> Steve, weigh in on the architecture because this is going to be a big conversation, and I wanted you to lead this section. >> I think you guys agree the journey, it seems like the journey started a couple of years ago. Got real serious, the need for multi-cloud, whether you're there today. Of course, it's going to be there in the future. So that's really important. I think the next thing is just architecture. I'd love to hear what you, had some comments about architecture matters, it all starts, every enterprise I talked to. Maybe talk about architecture and the importance of architects, maybe Bobby. >> From architecture perspective, we started our journey five years ago. >> Wow, okay. >> And we're just now starting our fourth evolution over network architect. And we call it networking security net sec, versus just as network. And that fourth-generation architecture should be based primarily upon the Palo Alto Networks and Aviatrix. Aviatrix to new orchestration piece of it. But that journey came because of the need for simplicity, the need for a multi-cloud orchestration without us having to go and do reprogramming efforts across every cloud as it comes along. >> I guess the other question I also had around architecture is also... Luis maybe just talk about it. I know we've talked a little bit about scripting, and some of your thoughts on that. >> Absolutely. So for us, we started creating the network constructs with cloud formation, and we've stuck with that for the most part. What's interesting about that is today, on-premise, we have a lot of automation around how we provision networks, but cloud formation has become a little bit like the new manual for us. We're now having issues with having to automate that component and making it consistent with our on-premise architecture and making it consistent with Azure architecture and Google cloud. So, it's really interesting to see companies now bring that layer of abstraction that SD-WAN brought to the wound side, now it's going up into the cloud networking architecture. >> Great. So on the fourth generation, you mentioned you're on the fourth-gen architecture. What have you learned? Is there any lessons, scratch issue, what to avoid, what worked? What was the path that you touched? >> It's probably the biggest lesson there is that when you think you finally figured it out, you haven't. Amazon will change something, Azure change something. Transit Gateway is a game-changer. And listening to the business requirements is probably the biggest thing we need to do upfront. But I think from a simplicity perspective, like I said, we don't want to do things four times. We want to do things one time, we want be able to write to an API which Aviatrix has and have them do the orchestration for us. So that we don't have to do it four times. >> How important is architecture in the progression? Is it do you guys get thrown in the deep end, to solve these problems, are you guys zooming out and looking at it? How are you guys looking at the architecture? >> You can't get off the ground if you don't have the network there. So all of those, we've gone through similar evolutions, we're on our fourth or fifth evolution. I think about what we started off with Amazon without Direct Connect Gateway, without Transit Gateway, without a lot of the things that are available today, kind of the 80, 20 that Steve was talking about. Just because it wasn't there doesn't mean we didn't need it. So we needed to figure out a way to do it, we couldn't say, "Oh, you need to come back to the network team in a year, and maybe Amazon will have a solution for it." We need to do it now and evolve later and maybe optimize or change the way you're doing things in the future. But don't sit around and wait, you can't. >> I'd love to have you guys each individually answer this question for the live streams that comes up a lot. A lot of cloud architects out in the community, what should they be thinking about the folks that are coming into this proactively and, or realizing the business benefits are there? What advice would you guys give them on architecture? What should be they'd be thinking about, and what are some guiding principles you could share? >> So I would start with looking at an architecture model that can spread and give consistency to the different cloud vendors that you will absolutely have to support. Cloud vendors tend to want to pull you into using their native tool set, and that's good if only it was realistic to talk about only one cloud. But because it doesn't, it's super important to talk about, and have a conversation with the business and with your technology teams about a consistent model. >> And how do I do my day one work so that I'm not spending 80% of my time troubleshooting or managing my network? Because if I'm doing that, then I'm missing out on ways that I can make improvements or embrace new technologies. So it's really important early on to figure out, how do I make this as low maintenance as possible so that I can focus on the things that the team really should be focusing on? >> Bobby, your advice there, architecture. >> I don't know what else I can add to that. Simplicity of operations is key. >> So the holistic view of day two operations you mentioned, let's can jump in day one as you're getting stuff set up, day two is your life after. This is kind of of what you're getting at, David. So what does that look like? What are you envisioning as you look at that 20-mile stair, out post multi-cloud world? What are some of the things that you want in the day two operations? >> Infrastructure as code is really important to us. So how do we design it so that we can start fit start making network changes and fitting them into a release pipeline and start looking at it like that, rather than somebody logging into a router CLI and troubleshooting things in an ad hoc nature? So, moving more towards a dev-ops model. >> You guys, anything to add on that day two? >> Yeah, I would love to add something. In terms of day two operations you can either sort of ignore the day two operations for a little while, where you get your feet wet, or you can start approaching it from the beginning. The fact is that the cloud-native tools don't have a lot of maturity in that space and when you run into an issue, you're going to end up having a bad day, going through millions and millions of logs just to try to understand what's going on. That's something that the industry just now is beginning to realize it's such a big gap. >> I think that's key because for us, we're moving to more of an event-driven or operations. In the past, monitoring got the job done. It's impossible to monitor something that is not there when the event happens. So the event-driven application and then detection is important. >> Gardner is all about the cloud-native wave coming into networking. That's going to be a serious thing. I want to get your guys' perspective, I know you have each different views of how you come into the journey and how you're executing. And I always say the beauty's in the eye of the beholder and that applies to how the network's laid out. So, Bobby, you guys do a lot of high-performance encryption, both on AWS and Azure. That's a unique thing for you. How are you seeing that impact with multi-cloud? >> That's a new requirement for us too, where we have an increment to encrypt. And then if you ever get the question, should I encrypt, should I not encrypt? The answer is always yes. You should encrypt when you can encrypt. For our perspective, we need to migrate a bunch of data from our data centers. We have some huge data centers, and getting that data to the cloud is a timely expense in some cases. So we have been mandated, we have to encrypt everything, leave in the data center. So we're looking at using the Aviatrix insane mode appliances to be able to encrypt 10, 20 gigabits of data as it moves to the cloud itself. >> David, you're using Terraform, you've got FireNet, you've got a lot of complexity in your network. What do you guys look at the future for your environment? >> So many exciting that we're working on now as FireNet. So for our security team that obviously have a lot of knowledge base around Palo Alto, and with our commitments to our clients, it's not very easy to shift your security model to a specific cloud vendor. So there's a lot of SOC 2 compliance and things like that were being able to take some of what you've worked on for years on-prem and put it in the cloud and have the same type of assurance that things are going to work and be secure in the same way that they are on-prem, helps make that journey into the cloud a lot easier. >> And Louis, you guys got scripting, you got a lot of things going on. What's your unique angle on this? >> Absolutely. So for disclosure, I'm not an Aviatrix customer yet. (laughs) >> It's okay, we want to hear the truth, so that's good. Tell us, what are you thinking about? What's on your mind? >> When you talk about implementing a tool like this, it's really just really important to talk about automation focus on value. When you talk about things like encryption and things like so you're encrypting tunnels and encrypting the path, and those things should be second nature really. When you look at building those back-ends and managing them with your team, it becomes really painful. So tools like Aviatrix that add a lot automation it's out of sight, out of mind. You can focus on the value, and you don't have to focus on this. >> So I got to ask you guys. I see Aviatrix was here, they're supplier to this sector, but you guys are customers. Everyone's pitching your stuff, people knock on you, "Buy my stuff." How do you guys have that conversation with the suppliers, like the cloud vendors and other folks? What's it like? We're API all the way? You've got to support this? What are some of your requirements? How do you talk to and evaluate people that walk in and want to knock on your door and pitch you something? What's the conversation like? >> It's definitely API driven. We definitely look at the API structure that the vendors provide before we select anything. That is always first of mine and also, what problem are we really trying to solve? Usually, people try to sell or try to give us something that isn't really valuable, like implementing a Cisco solution on the cloud doesn't really add a lot of value, that's where we go. >> David, what's your conversation like with suppliers? Do you have a certain new way to do things? As it becomes more agile, essentially networking, and getting more dynamic, what are some of the conversations with either in commits or new vendors that you're having? What do you require? >> Ease of use is definitely high up there. We've had some vendors come in and say, "Hey, when you go to set this up, "we're going to want to send somebody on-site." And they're going to sit with you for a day to configure it. And that's a red flag. Well, wait a minute, do we really, if one of my really talented engineers can't figure it out on his own, what's going on there and why is that? Having some ease of use and the team being comfortable with it and understanding it is really important. >> Bobby, how about you? Old days was, do a bake-off and the winner takes all. Is it like that anymore? What's evolving? Bake-off last year for but still win. But that's different now because now when you get the product, you can install the product in AWS and Azure, have it up running in a matter of minutes. So the key is that can you be operational within hours or days instead of weeks? But do we also have the flexibility to customize it, to meet your needs? Because you don't want to be put into a box with the other customers when you have needs that are past their needs. >> I can almost see the challenge that you guys are living, where you've got the cloud immediate value, depending how you can roll up any solutions, but then you might have other needs. So you've got to be careful not to buy into stuff that's not shipping. So you're trying to be proactive and at the same time, deal with what you got. How do you guys see that evolving? Because multi-cloud to me is definitely relevant, but it's not yet clear how to implement across. How do you guys look at this baked versus future solutions coming? How do you balance that? >> Again, so right now, we're taking the ad hoc approach and experimenting what the different concepts of cloud are and really leveraging the native constructs of each cloud. But there's a breaking point for sure. You don't get to scale this like someone said, and you have to focus on being able to deliver, developers their sandbox or their play area for the things that they're trying to build quickly. And the only way to do that is with some consistent orchestration layer that allows you to-- >> So you expect a lot more stuff to becoming pretty quickly in that area. >> I do expect things to start maturing quite quickly this year. >> And you guys see similar trend, new stuff coming fast? >> Yeah. Probably the biggest challenge we've got now is being able to segment within the network, being able to provide segmentation between production, non-production workloads, even businesses, because we support many businesses worldwide and isolation between those is a key criteria there. So the ability to identify and quickly isolate those workloads is key. So the CIOs that are watching are saying, "Hey, take that hill, do multi-cloud." And then you have the bottoms up organization, "Pause, you're like off a little bit, it's not how it works." What is the reality in terms of implementing as fast as possible? Because the business benefits are clear, but it's not always clear on the technology how to move that fast. What are some of the barriers, what are the blockers, what are the enablers? >> I think the reality is that you may not think you're multi-cloud, but your business is. So I think the biggest barrier there is understanding what the requirements are and how best to meet those requirements in a secure manner. Because you need to make sure that things are working from a latency perspective that things work the way they did and get out of the mind shift that it was a tier-three application and the data center, it doesn't have to be a tier-three application in the cloud. So, lift and shift is not the way to go. >> Scale is a big part of what I see is the competitive advantage by these clouds and used to be proprietary network stacks in the old days, and then open systems came, that was a good thing. But as cloud has become bigger, there's an inherent lock-in there with the scale. How do you guys keep the choice open? How are you guys thinking about interoperability? What are some of the conversations that you guys are having around those key concepts? >> When we look at from a networking perspective, it's really key for you to just enable all the class to be able to communicate between them. Developers will find a way to use the cloud that best suits their business needs. And like you said, it's whether you're in denial or not, of the multi-cloud fact that your company is in already that's it becomes really important for you to move quickly. >> Yeah. And a lot of it also hinges on how well is the provider embracing what that specific cloud is doing? So, are they swimming with Amazon or Azure and just helping facilitate things, and they're doing the heavy lifting API work for you? Or are they swimming upstream and they're trying to hack it all together in messy way? And so that helps you stay out of the lock-in because there, if they're using Amazon native tools to help you get where you need to be, it's not like Amazon is going to release something in the future that completely makes you have designed yourself into a corner. So the closer, more than cloud-native they are, the more, the easier it is to deploy. >> Which also need to be aligned in such a way that you can take advantage of those cloud-native technologies. Will it make sense? TGW is a gamechanger in terms of cost and performance. So to completely ignore that, would be wrong. But if you needed to have encryption, TGW is not encrypted, so you need to have some type of Gateway to do the VPN encryption. So, the Aviatrix tool will give you the beauty of both worlds. You can use TGW or the Gateway. Real quick on the last minute we have, I want to just get a quick feedback from you guys. I hear a lot of people say to me, "Hey, pick the best cloud for the workload you got, then figure out multicloud behind the scenes." Do you guys agree with that? Do I go more to one cloud across the whole company or this workload works great on AWS, that workload works great on this. From a cloud standpoint, do you agree with that premise, and then when is multi-cloud stitching altogether? >> From an application perspective, it can be per workload, but it can also be an economical decision, certain enterprise contracts will pull you in one direction to add value, but the network problem is still the same. >> It doesn't go away. >> You don't want to be trying to fit a square into a round hall. If it works better on that cloud provider, then it's our job to make sure that service is there and people can use it. >> I agree, you just need to stay ahead of the game, make sure that the network infrastructure is there, security is available and is multi-cloud capable. >> At the end of the day, you guys are just validating that it's the networking game now. Cloud storage, compute check, networking is where the action is. Awesome. Thanks for your insights guys, appreciate you coming on the panel. Appreciate it, thanks. (upbeat music) >> John: Our next customer panel, got great another set of cloud network architects, Justin Smith with Zuora, Justin Brodley with EllieMae and Amit Utreja with Coupa. Welcome to stage. (audience applauds) (upbeat music) >> All right, thank you. >> How are ya? >> Thank you. Thank You. >> Hey Amit. How are ya? >> Did he say it right? >> Yeah. >> Okay he's got all the cliff notes from the last session, welcome back. Rinse and repeat. We're going to go into the hood a little bit. And I think they nailed what we've been reporting, we've been having this conversation around, networking is where the action is because that's at the end of the day you got to move packet from A to B and you got workloads exchanging data. So it's really killer. So let's get started. Amit, what are you seeing as the journey of multicloud as you go under the hood and say, "Okay, I got to implement this. "I have to engineer the network, "make it enabling, make it programmable, "make it interoperable across clouds." That almost sounds impossible to me. What's your take? >> Yeah, it seems impossible but if you are running an organization which is running infrastructure as a code it is easily doable. Like you can use tools out there that's available today, you can use third party products that can do a better job. But put your architecture first, don't wait. Architecture may not be perfect, put the best architecture that's available today and be agile, to iterate and make improvements over the time. >> We get to Justin's over here, so I have to be careful when I point a question to Justin, they both have the answer. Okay, journeys, what's the journey been like? Is there phases, We heard that from Gardner, people come into multicloud and cloud native networking from different perspectives? What's your take on the journey, Justin? >> Yeah, from our perspective, we started out very much focused on one cloud and as we've started doing acquisitions, we started doing new products to the market, the need for multicloud becomes very apparent, very quickly for us. And so having an architecture that we can plug and play into and be able to add and change things as it changes is super important for what we're doing in the space. >> Justin, your journey. >> Yes. For us, we were very ad hoc oriented and the idea is that we were reinventing all the time, trying to move into these new things and coming up with great new ideas. And so rather than it being some iterative approach with our deployments that became a number of different deployments. And so we shifted that toward and the network has been a real enabler of this. There's one network and it touches whatever cloud we want it to touch, and it touches the data centers that we need it to touch, and it touches the customers that we needed to touch. Our job is to make sure that the services that are available in one of those locations are available in all of the locations. So the idea is not that we need to come up with this new solution every time, it's that we're just iterating on what we've already decided to do. >> Before we get the architecture section, I want to ask you guys a question? I'm a big fan of let the app developers have infrastructure as code, so check. But having the right cloud run that workload, I'm a big fan of that, if it works great. But we just heard from the other panel, you can't change the network. So I want to get your thoughts, what is cloud native networking? And is that the engine really, that's the enabler for this multicloud trend? What's you guys take? We'll start with Amit, what do you think about that? >> Yeah, so you're going to have workloads running in different clouds and the workloads would have affinity to one cloud or other. But how you expose that it's a matter of how you are going to build your networks. How you're going to run security. How you're going to do egress, ingress out of it so -- >> You said networking is the big problem to solve. >> Yes. >> What's the solution? What's the key pain points and problem statement? >> The key pain point for most companies is how do you take your traditionally on premise network and then blow it out to the cloud in a way that makes sense. You have IP conflicts, you have IP space, you have public IPs on premise as well as in the cloud. And how do you kind of make sense of all of that? And I think that's where tools like Aviatrix make a lot of sense in that space. >> From our side, it's really simple. It's a latency, it's bandwidth and availability. These don't change whether we're talking about cloud or data center, or even corporate IT networking. So our job when these all of these things are simplified into like, S3, for instance and our developers want to use those. We have to be able to deliver that and for a particular group or another group that wants to use just just GCP resources. We have to support these requirements and these wants, as opposed to saying, "Hey, that's not a good idea." No, our job is to enable them not to disable them. >> Do you guys think infrastructure is code? Which I love that, I think that's the future in this. We even saw that with DevOps. But as you start getting the networking, is it getting down to the network portion where its network as code? Because storage and compute working really well, we're seeing all Kubernetes on service mesh trend. Network has code, reality is it there? Is it still got work to do? >> It's absolutely there, you mentioned net DevOps and it's very real. In Coupa we build our networks through terraform and not only just terraform, build an API so that we can consistently build VNets and VPC all across in the same way. >> So you guys are doing it? >> Yup. And even security groups. And then on top and Aviatrix comes in, we can peer the networks bridge all the different regions through code. >> Same with you guys. >> Yeah. >> What do you think about this? >> Everything we deploy is done with automation and then we also run things like Lambda on top to make changes in real time, we don't make manual changes on our network. In the data center, funny enough, it's still manual but the cloud has enabled us to move into this automation mindset. And all my guys, that's what they focus on is bringing, now what they're doing in the cloud into the data center, which is kind of opposite of what it should be or what it used to be. >> It's full DevOps then? >> Yes. >> For us, it was similar on-prem is still somewhat very manual, although we're moving more and more to ninja and terraform type concepts. But everything in the production environment is code, confirmation terraform code and now coming into the data center same (mumbles). >> So I just wanted to jump in Justin Smith, one of the comment that you made, because it's something that we always talk about a lot is that the center of gravity of architecture used to be an on-prem and now it's shifted in the cloud. And once you have your strategic architecture, what do you do? You push that everywhere. So what you used to see at the beginning of cloud was pushing the architecture on-prem into cloud. Now, I want to pick up on what you said, do you others agree that the center of gravity is here, I'm now pushing what I do in the cloud back into on-prem? And then so first that and then also in the journey, where are you at from zero to 100 of actually in the journey to cloud? Are you 50% there, are you 10%? Are you evacuating data centers next year? Where are you guys at? >> Yeah, so there's there's two types of gravity that you typically are dealing with, with the migration. First is data, gravity and your data set, and where that data lives. And then the second is the network platform that wraps all that together. In our case, the data gravity solely mostly on-prem but our network is now extending out to the app tier, it's going to be in cloud. Eventually, that data, gravity will also move to cloud as we start getting more sophisticated but in our journey, we're about halfway there. About halfway through the process, we're taking a handle of lift and shift and -- >> Steve: And when did that start? >> We started about three years ago. >> Okay, okay. >> Well for Coupa it's a very different story. It started from a garage and 100% on the cloud. So it's a business plan management platform, software as a service run 100% on the cloud. >> That was was like 10 years ago, right? >> Yes. >> Yeah. >> You guys are riding the wave of the architecture. Justin I want to ask you, Zuora, you guys mentioned DevOps. Obviously, we saw the huge observability wave, which essentially network management for the cloud, in my opinion. It's more dynamic, but this is about visibility. We heard from the last panel you don't know what's being turned on or turned off from a services standpoint, at any given time. How is all this playing out when you start getting into the DevOps down (mumbles)? >> This is the big challenge for all of us is visibility. When you talk transport within a cloud, very interestingly we we have moved from having a backbone that we bought, that we own, that would be data center connectivity. Zuora's a subscription billing company, so we want to support the subscription mindset. So rather than going and buying circuits and having to wait three months to install and then coming up with some way to get things connected and resiliency and redundancy. My backbone is in the cloud. I use the cloud providers interconnections between regions to transport data across and so if you do that with their native solutions, you do lose visibility. There are areas in that that you don't get, which is why controllers and having some type of management plane is a requirement for us to do what we're supposed to do and provide consistency while doing it. >> Great conversation. I loved what you said earlier latency, bandwidth, I think availability were your top three things. Guys SLA, just do ping times between clouds it's like, you don't know what you're getting for round trip time. This becomes a huge kind of risk management, black hole, whatever you want to call it, blind spot. How are you guys looking at the interconnect between clouds? Because I can see that working from ground to cloud on per cloud but when you start dealing with multiclouds workloads, SLAs will be all over the map, won't they just inherently. How do you guys view that? >> Yeah, I think we talked about workload and we know that the workloads are going to be different in different clouds, but they're going to be calling each other. So it's very important to have that visibility, that you can see how data is flowing at what latency and what availability is there and our authority needs to operate on that. >> So use the software dashboard, look at the times and look at the latency -- >> In the old days, Strongswan Openswan you try to figure it out, in the new days you have to figure out. >> Justin, what's your answer to that because you're in the middle of it? >> Yeah, I think the key thing there is that we have to plan for that failure, we have to plan for that latency in our applications. If certain things are tracking in your SLI, certain things are planning for and you loosely coupled these services in a much more microservices approach. So you actually can handle that kind of failure or that type of unknown latency and unfortunately, the cloud has made us much better at handling exceptions in a much better way. >> You guys are all great examples of cloud native from day one. When did you have the tipping point moment or the epiphany of saying a multiclouds real, I can't ignore it, I got to factor that into all my design principles and everything you're doing? Was there a moment or was it from day one? >> There are two reasons, one was the business. So in business, there were some affinity to not be in one cloud or to be in one cloud and that drove from the business side. So as a cloud architect our responsibility was to support that business. Another is the technology, some things are really running better in, like if you're running Dotnet workload or your going to run machine learning or AI so that you would have that preference of one cloud over other. >> Guys, any thoughts on that? >> That was the bill that we got from AWS. That's what drives a lot of these conversations is the financial viability of what you're building on top of. This failure domain idea which is fairly interesting. How do I solve our guarantee against a failure domain? You have methodologies with back end direct connects or interconnect with GCP. All of these ideas are something that you have to take into account but that transport layer should not matter to whoever we're building this for. Our job is to deliver the frames and the packets, what that flows across, how you get there? We want to make that seamless. And so whether it's a public internet API call or it's a back end connectivity through direct connect, it doesn't matter. It just has to meet a contract that you've signed with your application, folks. >> Yeah, that's the availability piece. >> Justin, your thoughts on that, any comment on that? >> So actually multiclouds become something much more recent in the last six to eight months, I'd say. We always kind of had a very much an attitude of like moving to Amazon from our private cloud is hard enough, why complicate it further? But the realities of the business and as we start seeing, improvements in Google and Azure and different technology spaces, the need for multicloud becomes much more important. As well as our acquisition strategies are matured, we're seeing that companies that used to be on premise that we typically acquire are now very much already on a cloud. And if they're on a cloud, I need to plug them into our ecosystem. And so that's really changed our multicloud story in a big way. >> I'd love to get your thoughts on the clouds versus the clouds, because you compare them Amazon's got more features, they're rich with features. Obviously, the bills are high to people using them. But Google's got a great network, Google's networks pretty damn good And then you got Azure. What's the difference between the clouds? Where do they fall? Where do they peak in certain areas better than others? What are the characteristics, which makes one cloud better? Do they have a unique feature that makes Azure better than Google and vice versa? What do you guys think about the different clouds? >> Yeah, to my experience, I think the approach is different in many places. Google has a different approach very DevOps friendly and you can run your workloads with your network can span regions. But our application ready to accept that. Amazon is evolving. I remember 10 years back Amazon's network was a flat network, we would be launching servers in 10.0.0/8, right. And then the VPCs came out. >> We'll have to translate that to English for the live feed. Not good. So the VPCs concept came out, multi account came out, so they are evolving. Azure had a late start but because they have a late start, they saw the pattern and they have some mature setup on the network. >> They've got around the same price too. >> I think they're all trying to say they're equal in their own ways. I think they all have very specific design philosophies that allow them to be successful in different ways and you have to kind of keep that in mind as you architect your own solution. For example, Amazon has a very regional affinity, they don't like to go cross region in their architecture. Whereas Google is very much it's a global network, we're going to think about as a global solution. I think Google also has advantage that it's third to market and so has seen what Azure did wrong, it seeing what AWS did wrong and it's made those improvements and I think that's one of their big advantage. >> They got great scale too. Justin thoughts on the cloud. >> So yeah, Amazon built from the system up and Google built from the network down. So their ideas and approaches are from a global versus original, I agree with you completely that is the big number one thing. But the if you look at it from the outset, interestingly, the inability or the ability for Amazon to limit layer to broadcasting and what that really means from a VPC perspective, changed all the routing protocols you can use. All the things that we had built inside of a data center to provide resiliency and make things seamless to users, all of that disappeared. And so because we had to accept that at the VPC level, now we have to accept that at the WAN level. Google's done a better job of being able to overcome those things and provide those traditional network facilities to us. >> Just a great panel, we could go all day here, it's awesome. So I heard, we will get to the cloud native naive questions. So kind of think about what's naive and what's cloud, I'll ask that next but I got to ask you I had a conversation with a friend he's like, "WAN is the new LAN?" So if you think about what the LAN was at a data center, WAN is the new LAN, cause you keep talking about the cloud impact? So that means ST-WAN, the old ST-WAN kind of changing. There's a new LAN. How do you guys look at that? Because if you think about it, what LANs were for inside a premises was all about networking, high speed. But now when you take the WAN and make it, essentially a LAN, do you agree with that? And how do you view this trend? Is it good or bad or is it ugly? What you guys take on this? >> Yeah, I think it's a thing that you have to work with your application architects. So if you are managing networks and if you're a server engineer, you need to work with them to expose the unreliability that it would bring in. So the application has to handle a lot of the difference in the latencies and the reliability has to be worked through the application there. >> LAN, WAN, same concept is that BS? Can you give some insight? >> I think we've been talking about for a long time the erosion of the edge. And so is this just a continuation of that journey we've been on for last several years. As we get more and more cloud native and we talked about API's, the ability to lock my data in place and not be able to access it really goes away. And so I think this is just continuation. I think it has challenges. We start talking about WAN scale versus LAN scale, the tooling doesn't work the same, the scale of that tooling is much larger. and the need to automation is much, much higher in a WAN than it wasn't a LAN. That's why you're seeing so much infrastructure as code. >> Yeah. So for me, I'll go back again to this, it's bandwidth and its latency that define those two LAN versus WAN. But the other thing that's comes up more and more with cloud deployments is whereas our security boundary and where can I extend this secure aware appliance or set of rules to protect what's inside of it. So for us, we're able to deliver VRFs or route forwarding tables for different segments wherever we're at in the world. And so they're trusted to talk to each other but if they're going to go to someplace that's outside of their network, then they have to cross the security boundary, where we enforce policy very heavily. So for me, there's it's not just LAN, WAN it's how does environment get to environment more importantly. >> That's a great point in security, we haven't talked it yet but that's got to be baked in from the beginning, this architecture. Thoughts on security, how you guys are dealing with it? >> Yeah, start from the base, have app to app security built in. Have TLS, have encryption on the data at transit, data at rest. But as you bring the application to the cloud and they're going to go multicloud, talking to over the internet, in some places, well have app to app security. >> Our principles day, security is day zero every day. And so we always build it into our design, build into our architecture, into our applications. It's encrypt everything, it's TLS everywhere. It's make sure that that data is secure at all times. >> Yeah, one of the cool trends at RSA, just as a side note was the data in use encryption piece, which is homomorphic stuff was interesting. Alright guys, final question. We heard on the earlier panel was also trending at re:Invent, we think the T out of cloud native, it spells cloud naive. They have shirts now, Aviatrix kind of got this trend going. What does that mean to be naive? To your peers out there watching the live stream and also the suppliers that are trying to supply you guys with technology and services, what's naive look like and what's native look like? When is someone naive about implementing all this stuff? >> So for me, because we are in 100% cloud, for us its main thing is ready for the change. And you will find new building blocks coming in and the network design will evolve and change. So don't be naive and think that it's static, evolve with the change. >> I think the biggest naivety that people have is that well, I've been doing it this way for 20 years, I've been successful, it's going to be successful in cloud. The reality is that's not the case. You got to think some of the stuff a little bit differently and you need to think about it early enough, so that you can become cloud native and really enable your business on cloud. >> Yeah for me it's being open minded. Our industry, the network industry as a whole, has been very much I'm smarter than everybody else and we're going to tell everybody how it's going to be done. And we fell into a lull when it came to producing infrastructure and so embracing this idea that we can deploy a new solution or a new environment in minutes as opposed to hours, or weeks or months in some cases, is really important in and so >> - >> It's naive being closed minded, native being open minded. >> Exactly. For me that was a transformative kind of where I was looking to solve problems in a cloud way as opposed to looking to solve problems in this traditional old school way. >> All right, I know we're at a time but I got to asked one more question, so you guys so good. Give me a quick answer. What's the BS language when you, the BS meter goes off when people talk to you about solutions? What's the kind of jargon that you hear, that's the BS meter going off? What are people talking about that in your opinion you here you go, "That's total BS?" What triggers you? >> So that I have two lines out of movies if I say them without actually thinking them. It's like 1.21 gigawatts are you out of your mind from Back to the Future right? Somebody's giving you all these wiz bang things. And then Martin Maul and Michael Keaton in Mr Mom when he goes to 220, 221, whatever it takes. >> Yeah. >> Those two right there, if those go off in my mind where somebody's talking to me, I know they're full of baloney. >> So a lot of speeds and feeds, a lot of speeds and feeds a lot of -- >> Just data. Instead of talking about what you're actually doing and solutioning for. You're talking about, "Well, it does this this this." Okay to 220, 221. (laughter) >> Justin, what's your take? >> Anytime I start seeing the cloud vendors start benchmarking against each other. Your workload is your workload, you need to benchmark yourself. Don't listen to the marketing on that, that's just awful. >> Amit, what triggers you in the BS meter? >> I think if somebody explains to you are not simple, they cannot explain you in simplicity, then it's all bull shit. >> (laughs) That's a good one. Alright guys, thanks for the great insight, great panel. How about a round of applause to practitioners. (audience applauds) (upbeat music) >> John: Okay, welcome back to Altitude 2020 for the digital event for the live feed. Welcome back, I'm John Furrier with theCUBE with Steve Mullaney, CEO Aviatrix. For the next panel from Global System Integrated, the folks who are building and working with folks on their journey to multicloud and cloud-native networking. We've got a great panel, George Buckman with DXC and Derrick Monahan with WWT, welcome to the stage. (Audience applauds) >> Hey >> Thank you >> Groovy spot >> All right (upbeat music) >> Okay, you guys are the ones out there advising, building, and getting down and dirty with multicloud and cloud-native networking, we just heard from the customer panel. You can see the diversity of where people come in to the journey of cloud, it kind of depends upon where you are, but the trends are all clear, cloud-native networking, DevOps, up and down the stack, this has been the main engine. What's your guys' take of this journey to multicloud? What do you guys think? >> Yeah, it's critical, I mean we're seeing all of our enterprise customers enter into this, they've been through the migrations of the easy stuff, ya know? Now they're trying to optimize and get more improvements, so now the tough stuff's coming on, right? They need their data processing near where their data is. So that's driving them to a multicloud environment. >> Yeah, we've heard some of the Edge stuff, I mean, you guys are-- >> Exactly. >> You've seen this movie before, but now it's a whole new ballgame, what's your take? Yeah, so, I'll give you a hint, our practice is not called the cloud practice, it's the multicloud practice, and so if that gives you a hint of how we approach things. It's very consultative. And so when we look at what the trends are, like a year ago. About a year ago we were having conversations with customers, "Let's build a data center in the cloud. Let's put some VPCs, let's throw some firewalls, let's put some DNS and other infrastructure out there and let's hope it works." This isn't a science project. What we're starting to see is customers are starting to have more of a vision, we're helping with that consultative nature, but it's totally based on the business. And you've got to start understanding how lines of business are using the apps and then we evolve into the next journey which is a foundational approach to-- >> What are some of the problems some of your customers are solving when they come to you? What are the top things that are on their mind, obviously the ease of use, agility, all that stuff, what specifically are they digging into? >> Yeah, so complexity, I think when you look at a multicloud approach, in my view is, network requirements are complex. You know, I think they are, but I think the approach can be, "Let's simplify that." So one thing that we try to do, and this is how we talk to customers is, just like you simplify in Aviatrix, simplifies the automation orchestration of cloud networking, we're trying to simplify the design, the plan, and implementation of the infrastructure across multiple workloads, across multiple platforms. And so the way we do it, is we sit down, we look at not just use cases, not just the questions we commonly anticipate, we actually build out, based on the business and function requirements, we build out a strategy and then create a set of documents, and guess what? We actually build it in a lab, and that lab that we platform rebuilt, proves out this reference architectural actually works. >> Absolutely, we implement similar concepts. I mean, they're proven practices, they work, right? >> But George, you mentioned that the hard part's now upon us, are you referring to networking, what specifically were you getting at there when you said, "The easy part's done, now the hard part?" >> So for the enterprises themselves, migrating their more critical apps or more difficult apps into the environments, ya know, we've just scratched the surface, I believe, on what enterprises are doing to move into the cloud, to optimize their environments, to take advantage of the scale and speed to deployment and to be able to better enable their businesses. So they're just now really starting to-- >> So do you guys see what I talked about? I mean, in terms of that Cambrian explosion, I mean, you're both monster system integrators with top fortune enterprise customers, you know, really rely on you for guidance and consulting and so forth, and deploy their networks. Is that something that you've seen? I mean, does that resonate? Did you notice a year and a half ago all of a sudden the importance of cloud for enterprise shoot up? >> Yeah, I mean, we're seeing it now. >> Okay. >> In our internal environment as well, ya know, we're a huge company ourselves, customer zero, our internal IT, so, we're experiencing that internally and every one of our other customers as well. >> So I have another question and I don't know the answer to this, and a lawyer never asks a question that you don't know the answer to, but I'm going to ask it anyway. DXC and WWT, massive system integrators, why Aviatrix? >> Great question, Steve, so I think the way we approach things, I think we have a similar vision, a similar strategy, how you approach things, how we approach things, at World Wide Technology. Number one, we want a simplify the complexity. And so that's your number one priority. Let's take the networking, let's simplify it, and I think part of the other point I'm making is we see this automation piece as not just an after thought anymore. If you look at what customers care about, visibility and automation is probably at the top three, maybe the third on the list, and I think that's where we see the value. I think the partnership that we're building and what I get excited about is not just putting yours and our lab and showing customers how it works, it's co-developing a solution with you. Figuring out, "Hey, how can we make this better?" >> Right >> Visibility is a huge thing, just in security alone, network everything's around visibility. What automation do you see happening, in terms of progression, order of operations, if you will? What's the low hanging fruit? What are people working on now? What are some of the aspirational goals around when you start thinking about multicloud and automation? >> So I wanted to get back to his question. >> Answer that question. >> I wanted to answer your question, you know, what led us there and why Aviatrix. You know, in working some large internal IT projects, and looking at how we were going to integrate those solutions, you know, we like to build everything with recipes. Network is probably playing catch-up in the DevOps world but with a DevOps mindset, looking to speed to deploy, support, all those things, so when you start building your recipe, you take a little of this, a little of that, and you mix it all together, well, when you look around, you say, "Wow, look, there's this big bag of Aviatrix. "Let me plop that in. That solves a big part "of my problems that I had, the speed to integrate, "the speed to deploy, and the operational views "that I need to run this." So that was what led me to-- >> John: So how about reference architectures? >> Yeah, absolutely, so, you know, they came with a full slate of reference architectures already out there and ready to go that fit our needs, so it was very easy for us to integrate those into our recipes. >> What do you guys think about all the multi-vendor inter-operability conversations that have been going on? Choice has been a big part of multicloud in terms of, you know, customers want choice, they'll put a workload in the cloud if it works, but this notion of choice and interoperability has become a big conversation. >> It is, and I think that our approach, and that's the way we talk to customers is, "Let's speed and de-risk that decision making process, "and how do we do that?" Because interoperability is key. You're not just putting, it's not just a single vendor, we're talking, you know, many many vendors, I mean think about the average number of cloud applications a customer uses, a business, an enterprise business today, you know, it's above 30, it's skyrocketing and so what we do, and we look at it from an interoperability approach is, "How do things inter-operate?" We test it out, we validate it, we build a reference architecture that says, "These are the critical design elements, "now let's build one with Aviatrix "and show how this works with Aviatrix." And I think the important part there, though, is the automation piece that we add to it and visibility. So I think the visibility is what I see lacking across industry today. >> In cloud-native that's been a big topic. >> Yep >> Okay, in terms of Aviatrix, as you guys see them coming in, they're one of the ones that are emerging and the new brands emerging with multicloud, you've still got the old guard encumbered with huge footprints. How are customers dealing with that kind of component in dealing with both of them? >> Yeah, I mean, we have customers that are ingrained with a particular vendor and you know, we have partnerships with many vendors. So our objective is to provide the solution that meets that client. >> John: And they all want multi-vendor, they all want interoperability. >> Correct. >> All right, so I got to ask you guys a question while we were defining Day-2 operations. What does that mean? You guys are looking at the big business and technical components of architecture, what does Day-2 operations mean, what's the definition of that? >> Yeah, so I think from our perspective, with my experience, we, you know, Day-2 operations, whether it's not just the orchestration piece in setting up and let it automate and have some, you know, change control, you're looking at this from a Day-2 perspective, "How do I support this ongoing "and make it easy to make changes as we evolve?" The cloud is very dynamic. The nature of how fast it's expanding, the number features is astonishing. Trying to keep up to date with the number of just networking capabilities and services that are added. So I think Day-2 operations starts with a fundamental understanding of building out supporting a customer's environments, and making the automation piece easy from a distance, I think. >> Yeah and, you know, taking that to the next level of being able to enable customers to have catalog items that they can pick and choose, "Hey I need this network connectivity "from this cloud location back to this on-prem." And being able to have that automated and provisioned just simply by ordering it. >> For the folks watching out there, guys, take a minute to explain as you guys are in the trenches doing a lot of good work. What are some of the engagements that you guys get into? How does that progress? What happens there, they call you up and say, "Hey I need some multicloud," or you're already in there? I mean, take us through how someone can engage to use a global SI, they come in and make this thing happen, what's the typical engagement look like? >> Derrick: Yeah, so from our perspective, we typically have a series of workshops in the methodology that we kind of go along the journey. Number one, we have a foundational approach. And I don't mean foundation meaning the network foundation, that's a very critical element, we got to factor in security and we got to factor in automation. So when you think about foundation, we do a workshop that starts with education. A lot of times we'll go in and we'll just educate the customer, what is VPC sharing? You know, what is a private link in Azure? How does that impact your business? We have customers that want to share services out in an ecosystem with other customers and partners. Well there's many ways to accomplish that. Our goal is to understand those requirements and then build that strategy with them. >> Thoughts George, on-- >> Yeah, I mean, I'm one of the guys that's down in the weeds making things happen, so I'm not the guy on the front line interfacing with the customers every day. But we have a similar approach. We have a consulting practice that will go out and apply their practices to see what those-- >> And when do you parachute in? >> Yeah, when I parachute in is, I'm on the back end working with our offering development leads for networking, so we understand and are seeing what customers are asking for and we're on the back end developing the solutions that integrate with our own offerings as well as enable other customers to just deploy quickly to meet their connectivity needs. So the patterns are similar. >> Right, final question for you guys, I want to ask you to paint a picture of what success looks like. You don't have to name customers, you don't have to get in and reveal who they are, but what does success look like in multicloud as you paint a picture for the folks here and watching on the live stream, if someone says, "Hey I want to be multicloud, I got to to have my operations Agile, I want full DevOps, I want programmability and security built in from Day-zero." What does success look like? >> Yeah, I think success looks like this, so when you're building out a network, the network is a harder thing to change than some other aspects of cloud. So what we think is, even if you're thinking about that second cloud, which we have most of our customers are on two public clouds today, they might be dabbling in it. As you build that network foundation, that architecture, that takes in to consideration where you're going, and so once we start building that reference architecture out that shows, this is how to approach it from a multicloud perspective, not a single cloud, and let's not forget our branches, let's not forget our data centers, let's not forget how all this connects together because that's how we define multicloud, it's not just in the cloud, it's on-prem and it's off-prem. And so collectively, I think the key is also is that we provide them an HLD. You got to start with a high level design that can be tweaked as you go through the journey but you got to give it a solid structural foundation, and that networking which we think, most customers think as not the network engineers, but as an after thought. We want to make that the most critical element before you start the journey. >> George, from your seat, how does success look for you? >> So, you know it starts out on these journeys, often start out people not even thinking about what is going to happen, what their network needs are when they start their migration journey to the cloud. So I want, success to me looks like them being able to end up not worrying about what's happening in the network when they move to the cloud. >> Steve: Good point. >> Guys, great insight, thanks for coming on and sharing. How about a round of applause for the global system integrators? (Audience applauds) (Upbeat music) >> The next panel is the AVH certified engineers, also known as ACEs. This is the folks that are certified, they're engineering, they're building these new solutions. Please welcome Toby Foss from Informatica, Stacey Lanier from Teradata, and Jennifer Reed with Viqtor Davis to the stage. (upbeat music) (audience cheering) (panelists exchanging pleasantries) >> You got to show up. Where's your jacket Toby? (laughing) You get it done. I was just going to rib you guys and say, where's your jackets, and Jen's got the jacket on. Okay, good. >> Love the Aviatrix, ACEs Pilot gear there above the Clouds. Going to new heights. >> That's right. >> So guys Aviatrix aces, I love the name, think it's great, certified. This is all about getting things engineered. So there's a level of certification, I want to get into that. But first take us through the day in the life of an ACE, and just to point out, Stacy is a squad leader. So he's, he's like a-- >> Squadron Leader. >> Squadron Leader. >> Yeah. >> Squadron Leader, so he's got a bunch of ACEs underneath him, but share your perspective a day in the Life. Jennifer, we'll start with you. >> Sure, so I have actually a whole team that works for me both in the North America, both in the US and in Mexico. So I'm eagerly working to get them certified as well, so I can become a squad leader myself. But it's important because one of the critical gaps that we've found is people having the networking background because you graduate from college, and you have a lot of computer science background, you can program you've got Python, but networking in packets they just don't get. So, just taking them through all the processes that it's really necessary to understand when you're troubleshooting is really critical. Because you're going to get an issue where you need to figure out where exactly is that happening on the network, Is my issue just in the VPCs? Is it on the instance side is a security group, or is it going on prem? This is something actually embedded within Amazon itself? I mean, I troubleshot an issue for about six months going back and forth with Amazon, and it was the VGW VPN. Because they were auto scaling on two sides, and we ended up having to pull out the Cisco's, and put in Aviatrix so I could just say, " okay, it's fixed," and actually helped the application teams get to that and get it solved. But I'm taking a lot of junior people and getting them through that certification process, so they can understand and see the network, the way I see the network. I mean, look, I've been doing this for 25 years when I got out. When I went in the Marine Corps, that's what I did, and coming out, the network is still the network. But people don't get the same training they got in the 90s. >> Was just so easy, just write some software, and they were, takes care of itself. I know, it's pixie dust.  >> I'll come back to that, I want to come back to that, the problem solved with Amazon, but Toby. >> I think the only thing I have to add to that is that it's always the network's fault. As long as I've been in networking, it's always been the network's fault. I'm even to this day, it's still the network's fault, and part of being a network guy is that you need to prove when it is and when it's not your fault. That means you need to know a little bit about 100 different things, to make that work. >> Now you got a full stack DevOps, you got to know a lot more times another hundred. >> Toby: And the times are changing, yeah. >> This year the Squadron Leader and get that right. What is the Squadron Leader firstly? Describe what it is. >> I think is probably just leading on the network components of it. But I think, from my perspective, when to think about what you asked them was, it's about no issues and no escalations. So of my day is like that, I'm happy to be a squadron leader. >> That is a good outcome, that's a good day. >> Yeah, sure, it is. >> Is there good days? You said you had a good day with Amazon? Jennifer, you mentioned the Amazon, and this brings up a good point, when you have these new waves come in, you have a lot of new things, new use cases. A lot of the finger pointing it's that guy's problem , that girl's problems, so how do you solve that, and how do you get the Young Guns up to speed? Is there training, is it this where the certification comes in? >> This is where the certifications really going to come in. I know when we got together at Reinvent, one of the questions that we had with Steve and the team was, what should our certification look like? Should we just be teaching about what AVH troubleshooting brings to bear, but what should that be like? I think Toby and I were like, No, no, no, no. That's going a little too high, we need to get really low because the better someone can get at actually understanding what's actually happening in the network, and where to actually troubleshoot the problem, how to step back each of those processes. Because without that, it's just a big black box, and they don't know. Because everything is abstracted, in Amazon and in Azure and in Google, is abstracted, and they have these virtual gateways, they have VPNs, that you just don't have the logs on, is you just don't know. So then what tools can you put in front of them of where they can look? Because there are full logs. Well, as long as they turned on the flow logs when they built it, and there's like, each one of those little things that well, if they'd had decided to do that, when they built it, it's there. But if you can come in later to really supplement that with training to actual troubleshoot, and do a packet capture here, as it's going through, then teaching them how to read that even. >> Yeah, Toby, we were talking before we came on up on stage about your career, you've been networking all your time, and then, you're now mentoring a lot of younger people. How is that going? Because the people who come in fresh they don't have all the old war stories, like they don't talk about it, There's never for, I walk in bare feet in the snow when I was your age, I mean, it's so easy now, right, they say. What's your take on how you train the young People. >> So I've noticed two things. One is that they are up to speed a lot faster in generalities of networking. They can tell you what a network is in high school level now, where I didn't learn that til midway through my career, and they're learning it faster, but they don't necessarily understand why it's that way here. Everybody thinks that it's always slash 24 for a subnet, and they don't understand why you can break it down smaller, why it's really necessary. So the ramp up speed is much faster for these guys that are coming in. But they don't understand why and they need some of that background knowledge to see where it's coming from, and why is it important, and that's old guys, that's where we thrive. >> Jennifer, you mentioned you got in from the Marines, it helps, but when you got into networking, what was it like then and compare it now? Because most like we heard earlier static versus dynamic Don't be static is like that. You just set the network, you got a perimeter. >> Yeah, no, there was no such thing. So back in the day, I mean, we had Banyan vines for email, and we had token ring, and I had to set up token ring networks and figure out why that didn't work. Because how many of things were actually sharing it. But then actually just cutting fiber and running fiber cables and dropping them over shelters to plug them in and all crap, they swung it too hard and shattered it and now I got to figure eight Polish this thing and actually should like to see if it works. I mean, that was the network , current cat five cables to run an Ethernet, and then from that I just said, network switches, dumb switches, like those were the most common ones you had. Then actually configuring routers and logging into a Cisco router and actually knowing how to configure that. It was funny because I had gone all the way up, I was the software product manager for a while. So I've gone all the way up the stack, and then two and a half, three years ago, I came across to work with Entity group that became Viqtor Davis. But we went to help one of our customers Avis, and it was like, okay, so we need to fix the network. Okay, I haven't done this in 20 years, but all right, let's get to it. Because it really fundamentally does not change. It's still the network. I mean, I've had people tell me, Well, when we go to containers, we will not have to worry about the network. And I'm like, yeah, you don't I do. >> And that's within programmability is a really interesting, so I think this brings up the certification. What are some of the new things that people should be aware of that come in with the Aviatrix A certification? What are some of the highlights? Can you guys share some of the highlights around the certifications? >> I think some of the importance is that it doesn't need to be vendor specific for network generality or basic networking knowledge, and instead of learning how Cisco does something, or how Palo Alto does something, We need to understand how and why it works as a basic model, and then understand how each vendor has gone about that problem and solved it in a general. That's true in multicloud as well. You can't learn how Cloud networking works without understanding how AWS and Azure and GCP are all slightly the same but slightly different, and some things work and some things don't. I think that's probably the number one take. >> I think having a certification across Clouds is really valuable because we heard the global s eyes as you have a business issues. What does it mean to do that? Is it code, is it networking? Is it configurations of the Aviatrix? what is, he says,the certification but, what is it about the multiCloud that makes it multi networking and multi vendor? >> The easy answer is yes, >> Yes is all of us. >> All of us. So you got to be in general what's good your hands and all You have to be. Right, it takes experience. Because every Cloud vendor has their own certification. Whether that's SOPs and advanced networking and event security, or whatever it might be, yeah, they can take the test, but they have no idea how to figure out what's wrong with that system. The same thing with any certification, but it's really getting your hands in there, and actually having to troubleshoot the problems, actually work the problem, and calm down. It's going to be okay. I mean, because I don't know how many calls I've been on or even had aviators join me on. It's like, okay, so everyone calm down, let's figure out what's happening. It's like, we've looked at that screen three times, looking at it again is not going to solve that problem, right. But at the same time, remaining calm but knowing that it really is, I'm getting a packet from here to go over here, it's not working, so what could be the problem? Actually stepping them through those scenarios, but that's like, you only get that by having to do it, and seeing it, and going through it, and then you get it. >> I have a question, so, I just see it. We started this program maybe six months ago, we're seeing a huge amount of interest. I mean, we're oversubscribed on all the training sessions. We've got people flying from around the country, even with Coronavirus, flying to go to Seattle to go to these events where we're subscribed, is that-- >> A good emerging leader would put there. >> Yeah. So, is that something that you see in your organizations? Are you recommending that to people? Do you see, I mean, I'm just, I guess I'm surprised or not surprised. But I'm really surprised by the demand if you would, of this MultiCloud network certification because there really isn't anything like that. Is that something you guys can comment on? Or do you see the same things in your organization? >> I see from my side, because we operate in a multiCloud environments that really helps and some beneficial for us. >> Yeah, true. I think I would add that networking guys have always needed to use certifications to prove that they know what they know. >> Right. >> It's not good enough to say, Yeah, I know IP addresses or I know how a network works. A couple little check marks or a little letters body writing helps give you validity. So even in our team, we can say, Hey, we're using these certifications to know that you know enough of the basics and enough of the understandings, that you have the tools necessary, right. >> I guess my final question for you guys is, why an ACE certification is relevant, and then second part is share with the live stream folks who aren't yet ACE certified or might want to jump in to be aviatrix certified engineers. Why is it important, so why is it relevant and why should someone want to be a certified aviatrix certified engineer? >> I think my views a little different. I think certification comes from proving that you have the knowledge, not proving that you get a certification to get an army there backwards. So when you've got the training and the understanding and you use that to prove and you can, like, grow your certification list with it, versus studying for a test to get a certification and have no understanding of it. >> Okay, so that who is the right person that look at this and say, I'm qualified, is it a network engineer, is it a DevOps person? What's your view, a little certain. >> I think Cloud is really the answer. It's the, as we talked like the edges getting eroded, so is the network definition getting eroded? We're getting more and more of some network, some DevOps, some security, lots and lots of security, because network is so involved in so many of them. That's just the next progression. >> Do you want to add something there? >> I would say expand that to more automation engineers, because we have those now, so I probably extend it beyond this one. >> Jennifer you want to? >> Well, I think the training classes themselves are helpful, especially the entry level ones for people who may be "Cloud architects" but have never done anything in networking for them to understand why we need those things to really work, whether or not they go through to eventually get a certification is something different. But I really think fundamentally understanding how these things work, it makes them a better architect, makes them better application developer. But even more so as you deploy more of your applications into the Cloud, really getting an understanding, even from people who have traditionally done Onprem networking, they can understand how that's going to work in Cloud. >> Well, I know we've got just under 30 seconds left. I want to get one more question then just one more, for the folks watching that are maybe younger than, that don't have that networking training. From your experiences each of you can answer why should they know about networking, what's the benefit? What's in it for them? Motivate them, share some insights of why they should go a little bit deeper in networking. Stacy, we'll start with you, we'll go then. >> I'll say it's probably fundamental, right? If you want to deliver solutions, networking is the very top. >> I would say if you, fundamental of an operating system running on a machine, how those machines start together is a fundamental changes, something that start from the base and work your way up. >> Jennifer? >> Right, well, I think it's a challenge. Because you've come from top down, now you're going to start looking from bottom up, and you want those different systems to cross-communicate, and say you've built something, and you're overlapping IP space, note that that doesn't happen. But how can I actually make that still operate without having to re IP re platform. Just like those challenges, like those younger developers or assistant engineers can really start to get their hands around and understand those complexities and bring that forward in their career. >> They get to know then how the pipes are working, and they're got to know it--it's the plumbing. >> That's right, >> They got to know how it works, and how to code it. >> That's right. >> Awesome, thank you guys for great insights, ACE Certified Engineers, also known as ACEs, give them a round of applause. (audience clapping) (upbeat music) >> Thank you, okay. All right, that concludes my portion. Thank you, Steve Thanks for having me. >> John, thank you very much, that was fantastic. Everybody round of applause for John Furrier. (audience applauding) Yeah, so great event, great event. I'm not going to take long, we got lunch outside for the people here, just a couple of things. Just to call the action, right? So we saw the ACEs, for those of you out of the stream here, become a certified, right, it's great for your career, it's great for not knowledge, is fantastic. It's not just an aviator's thing, it's going to teach you about Cloud networking, MultiCloud networking, with a little bit of aviatrix, exactly like the Cisco CCIE program was for IP network, that type of the thing, that's number one. Second thing is learning, right? So there's a link up there to join the community. Again like I started this, this is a community, this is the kickoff to this community, and it's a movement. So go to community.avh.com, starting a community of multiCloud. So get get trained, learn. I'd say the next thing is we're doing over 100 seminars across the United States and also starting into Europe soon, we will come out and we'll actually spend a couple hours and talk about architecture, and talk about those beginning things. For those of you on the livestream in here as well, we're coming to a city near you, go to one of those events, it's a great way to network with other people that are in the industry, as well as to start alone and get on that MultiCloud journey. Then I'd say the last thing is, we haven't talked a lot about what Aviatrix does here, and that's intentional. We want you leaving with wanting to know more, and schedule, get with us and schedule a multi hour architecture workshop session. So we sit down with customers, and we talk about where they're at in that journey, and more importantly, where they're going, and define that end state architecture from networking, computer, storage, everything. Everything you've heard today, everybody panel kept talking about architecture, talking about operations. Those are the types of things that we solve, we help you define that canonical architecture, that system architecture, that's yours. So many of our customers, they have three by five, plotted lucid charts, architecture drawings, and it's the customer name slash Aviatrix, network architecture, and they put it on their whiteboard. That's the most valuable thing they get from us. So this becomes their 20 year network architecture drawing that they don't do anything without talking to us and look at that architecture. That's what we do in these multi hour workshop sessions with customers, and that's super, super powerful. So if you're interested, definitely call us, and let's schedule that with our team. So anyway, I just want to thank everybody on the livestream. Thank everybody here. Hopefully it was it was very useful. I think it was, and Join the movement, and for those of you here, join us for lunch, and thank you very much. (audience applauding) (upbeat music)

(upbeat music) >> From the Silicon Angle Media office in Boston, Massachusetts, it's theCube. Now, here's your host, Stu Miniman. >> Hi, I'm Stu Miniman, and welcome to the first interview of theCube in our Boston area studio for 2020. And to help me kick it off, Jeremy Daly who is the host of Serverless Chats as well as runs the Serverless Day Boston. Jeremy, saw you at reInvent, way back in 2019, and we'd actually had some of the people in the community that were like hey, "I think you guys like actually live and work right near each other." >> Right. >> And you're only about 20 minutes away from our office here, so thanks so much for making the long journey here, and not having to get on a plane to join us here. >> Well, thank you for having me. >> All right, so as Calvin from Calvin and Hobbes says, "It's a new decade, but we don't have any base on the moon, "we don't have flying cars that general people can use, "but we do have serverless." >> And our robot vacuum cleaners. >> We do have robot vacuum cleaners. >> Which are run by serverless, as a matter of fact. >> A CUBE alum on the program would be happy that we do get to mention there. So yeah, you know serverless there are things like the iRobot, as well as Alexa, or some of the things that people, you know usually when I'm explaining to people what this is, and they don't understand it, it's like, Oh, you've used Alexa, well those are the functions underneath, and you think about how these things turn on, and off, a little bit like that. But maybe, we don't need to get into the long ontological discussion or everything, but you know you're a serverless hero, so you know give us a little bit, what your hearing from people, what are some of the exciting use cases out there, and you know where serverless is being used in that maturity today. >> Yeah, I mean well, so the funny thing about serverless and the term serverless itself, and I do not want to get into a long discussion about this, obviously. I actually wrote a post last year that was called stop calling everything serverless, because basically people are calling everything serverless. So it really, what it, what I look at it as, is something where, it just makes it really easy for developers to abstract away that back end infrastructure, and not having to worry about setting up Kubernetes, or going through the process of setting up virtual machines and installing software is just, a lot of that stuff is kind of handled for you. And I think that is enabled, a lot of companies, especially start-ups is a huge market for serverless, but also enterprises. Enabled them to give more power to their developers, and be able to look at new products that they want to build, new services they want to tackle or even old services that they need to, you know that may have some stability issues or things like long running ETL tasks, and other things like that, that they found a way to sort of find the preferal edges of these monolithic applications or these mainframes that they are using and find ways to run very small jobs, you know using functions as a server, something like that. And so, I see a lot of that, I think that is a big use case. You see a lot of large companies doing. Obviously, people are building full fledged applications. So, yes, the web facing user application, certainly a thing. People are building API's, you got API Gateway, they just released the new HEDP API which makes it even faster. To run those sort of things, this idea of cold starts, you know in AWS trying to get rid of all that stuff, with the new VPC networking, and some of the things they are doing there. So you have a lot of those type of applications that people are building as well. But it really runs the gambit, there are things all across the board that you can do, and pretty much anything you can do with the traditional computing environment, you can do with a serverless computing environment. And obviously that's focusing quite a bit on the functions as a service side of things, which is a very tiny part of serverless, if you want to look at it, you know sort of the broader picture, this service full or managed services, type approach. And so, that's another thing that you see, where you used to have companies setting up you know, mySQL databases and clusters trying to run these things, or even worse, Cassandra rings, right. Trying to do these things and manage this massive amount of infrastructure, just so that they could write a few records to a database and read them back for their application. And that would take months sometimes, for them to get it setup and even more time to try to keep running them. So this sort of revolution of managed services and all these things we get now, whether that the things like managed elastic search or elastic search cloud doing that stuff for you, or Big Table and Dynamo DB, and Manage Cassandra, whatever those things are. I'm just thinking a lot easier for developers to just say hey, I need a database, and okay, here it is, and I don't have to worry about the infrastructure at all. So, I think you see a lot of people, and a lot of companies that are utilizing all of these different services now, and essentially are no longer trying to re-invent the wheel. >> So, a couple of years ago, I was talking to Andy Jassy, at an interview with theCube, and he said, "If I was to build AWS today, "I would've built it on serverless." And from what I've seen over the last two or three years or so, Amazon is rebuilding a lot of there servers underneath. It's very interesting to watch that platform changing. I think it's had some ripple effect dynamics inside the company 'cause Amazon is very well known for their two pizza teams and for all of their products are there, but I think it was actually in a conversation with you, we're talking about in some ways this new way of building things is, you know a connecting fabric between the various groups inside of Amazon. So, I love your view point that we shouldn't just call everything serverless, but in many ways, this is a revolution and a new way of thinking about building things and therefore, you know there are some organizational and dynamical changes that happen, for an Amazon, but for other people that start using it. >> Yeah, well I mean I actually was having a conversation with a Jay Anear, whose one of the product owners for Lambda, and he was saying to me, well how do we sell serverless. How do we tell people you know this is what the next way to do things. I said, just, it's the way, right. And Amazon is realized this, and part of the great thing about dog fooding your own product is that you say, okay I don't like the taste of this bit, so we're going to change it to make it work. And that's what Amazon has continued to do, so they run into limitations with serverless, just like us early adopters, run into limitations, and they say, we'll how do we make it better, how do we fix it. And they have always been really great to listening to customers. I complain all the time, there's other people that complain all the time, that say, "Hey, I can't do this." And they say, "Well what if we did it this way, and out of that you get things like Lambda Destinations and all different types of ways, you get Event Bridge, you get different ways that you can solve those problems and that comes out of them using their own services. So I think that's a huge piece of it, but that helps enable other teams to get past those barriers as well. >> Jeremy, I'm going to be really disappointed if in 2020, I don't see a T-shirt from one of the Serverless Days, with the Mandalorian on it, saying, "Serverless, this is the way." Great, great, great marketing opportunity, and I do love that, because some of the other spaces, you know we're not talking about a point product, or a simple thing we do, it is more the way of doing things, it's just like I think about Cybersecurity. Yes, there are lots of products involved here but, you know this is more of you know it's a methodology, it needs to be fully thought of across the board. You know, as to how you do things, so, let's dig in a little bit. At reInvent, there was, when I went to the serverless gathering, it was serverless for everyone. >> Serverless for everyone, yes. >> And there was you know, hey, serverless isn't getting talked, you know serverless isn't as front and center as some people might think. They're some people on the outside look at this and they say, "Oh, serverless, you know those people "they have a religion, and they go so deep on this." But I thought Tim Wagner had a really good blog post, that came out right after reInvent, and what we saw is not only Amazon changing underneath the way things are done, but it feel that there's a bridging between what's happening in Kubernetes, you see where Fargate is, Firecracker, and serverless and you know. Help us squint through that, and understand a little bit, what your seeing, what your take was at reInvent, what you like, what you were hoping to see and how does that whole containerization, and Kubernetes wave intersect with what we're doing with serverless? >> Yeah, well I mean for some reason people like Kubernetes. And I honestly, I don't think there is anything wrong with it, I think it's a great container orchestration system, I think containers are still a very important part of the workloads that we are putting into a cloud, I don't know if I would call them cloud native, exactly, but I think what we're seeing or at least what I'm seeing that I think Amazon is seeing, is they're saying people are embracing Kubernetes, and they are embracing containers. And whether or not containers are ephemeral or long running, which I read a statistic at some point, that was 63% of containers, so even running on Kubernetes, or whatever, run for less than 10 minutes. So basically, most computing that's happening now, is fairly ephemeral. And as you go up, I think it's 15 minutes or something like that, I think it's 70% or 90% or whatever that number is, I totally got that wrong. But I think what Amazon is doing is they're trying to basically say, look we were trying to sell serverless to everyone. We're trying to sell this idea of look managed services, managed compute, the idea that we can run even containers as close to the metal as possible with something like Fargate which is what Firecracker is all about, being able to run virtual machines basically, almost you know right on the metal, right. I mean it's so close that there's no level of abstraction that get in the way and slow things down, and even though we're talking about milliseconds or microseconds, it's still something and there's efficiencies there. But I think what they looked at is, they said look at we are not Apple, we can't kill Flash, just because we say we're not going to support it anymore, and I think you mention this to me in the past where the majority of Kubernetes clusters that were running in the Public Cloud, we're running in Amazon anyways. And so, you had using virtual machines, which are great technology, but are 15 years old at this point. Even containerization, there's more problems to solve there, getting to the point where we say, look you want to take this container, this little bit of code, or this small service and you want to just run this somewhere. Why are we spinning up virtual containers. Why are we using 15 or 10 year old technology to do that. And Amazon is just getting smarter about it. So Amazon says hay, if we can run a Lambda function on Firecracker, and we can run a Fargate container on Firecracker, why can't we run, you know can we create some pods and run some pods for Kubernetes on it. They can do that. And so, I think for me, I was disappointed in the keynotes, because I don't think there was enough serverless talk. But I think what they're trying to do, is there trying to and this is if I put my analyst hat on for a minute. I think they're trying to say, the world is at Kubernetes right now. And we need to embrace that in a way, that says we can run your Kubernetes for you, a lot more efficiently and without you having to worry about it than if you use Google or if you use some other cloud provider, or if you run on-prem. Which I think is the biggest competitor to Amazon is still on-prem, especially in the enterprise world. So I see them as saying, look we're going to focus on Kubernetes, but as a way that we can run it our way. And I think that's why, Fargate and Kubernetes, or the Kubernetes for Fargate, or whatever that new product is. Too many product names at AWS. But I think that's what they are trying to do and I think that was the point of this, is to say, "Listen you can run your Kubernetes." And Claire Legore who showed that piece at the keynote, Vernor's keynote that was you know basically how quickly Fargate can scale up Kubernetes, you know individual containers, Kubernetes, as opposed to you know launching new VM's or EC2 instances. So I thought that was really interesting. But that was my overall take is just that they're embracing that, because they think that's where the market is right now, and they just haven't yet been able to sell this idea of serverless even though you are probably using it with a bunch of things anyways, at least what they would consider serverless. >> Yeah, to part a little bit from the serverless for a second. Talk about multi-cloud, it was one of the biggest discussions, we had in 2019. When I talk to customers that are using Kubernetes, one of the reasons that they tell me they're doing it, "Well, I love Amazon, I really like what I'm doing, "but if I needed to move something, it makes it easier." Yes, there are some underlying services I would have to re-write, and I'm looking at all those. I've talked to customers that started with Kubernetes, somewhere other than Amazon, and moved it to Amazon, and they said it did make my life easier to be able to do that fundamental, you know the container piece was easy move that piece of it, but you know the discussion of multi-cloud gets very convoluted, very easily. Most customers run it when I talk to them, it's I have an application that I run, in a cloud, sometimes, there's certain, you know large financials will choose two of everything, because that's the way they've always done things for regulation. And therefore they might be running the same application, mirrored in two different clouds. But it is not follow the sun, it is not I wake up and I look at the price of things, and deploy it to that. And that environment it is a little bit tougher, there's data gravity, there's all these other concerns. But multi-cloud is just lots of pieces today, more than a comprehensive strategy. The vision that I saw, is if multi-cloud is to be a successful strategy, it should be more valuable than the sum of its pieces. And I don't see many examples of that yet. What do you see when it comes to multi-cloud and how does that serverless discussion fit in there? >> I think your point about data gravity is the most important thing. I mean honestly compute is commoditized, so whether your running it in a container, and that container runs in Fargate or orchestrated by Kubernetes, or runs on its own somewhere, or something's happening there, or it's a fast product and it's running on top of K-native or it's running in a Lambda function or in an Azure function or something like that. Compute itself is fairly commoditized, and yes there's wiring that's required for each individual cloud, but even if you were going to move your Kubernetes cluster, like you said, there's re-writes, you have to change the way you do things underneath. So I look at multi-cloud and I think for a large enterprise that has a massive amount of compliance, regulations and things like that they have to deal with, yeah maybe that's a strategy they have to embrace, and hopefully they have the money and tech staff to do that. I think the vast majority of companies are going to find that multi-cloud is going to be a completely wasteful and useless exercise that is essentially going to waste time and money. It's so hard right now, keeping up with everything new that comes out of one cloud right, try keeping up with everything that comes out of three clouds, or more. And I think that's something that doesn't make a lot of sense, and I don't think you're going to see this price gauging like we would see with something. Probably the wrong term to use, but something that we would see, sort of lock-in that you would see with Oracle or with Microsoft SQL, some of those things where the licensing became an issue. I don't think you're going to see that with cloud. And so, what I'm interested in though in terms of the term multi-cloud, is the fact that for me, multi-cloud really where it would be beneficial, or is beneficial is we're talking about SaaS vendors. And I look at it and I say, look it you know Oracle has it's own cloud, and Google has it's own cloud, and all these other companies have their own cloud, but so does Salesforce, when you think about it. So does Twilio, even though Twilio runs inside AWS, really its I'm using that service and the AWS piece of it is abstracted, that to me is a third party service. Stripe is a third-party service. These are multi-cloud structure or SaaS products that I'm using, and I'm going to be integrating with all those different things via API's like we've done for quite some time now. So, to me, this idea of multi-cloud is simply going to be, you know it's about interacting with other products, using the right service for the right job. And if your duplicating your compute or you're trying to write database services or something like that that you can somehow share with multiple clouds, again, I don't see there being a huge value, except for a very specific group of customers. >> Yeah, you mentioned the term cloud-native earlier, and you need to understand are you truly being cloud-native or are you kind of cloud adjacent, are you leveraging a couple of things, but you're really, you haven't taken advantage of the services and the promise of what these cloud options can offer. All right, Jeremy, 2020 we've turned the calendar. What are you looking at, you know you're planning, you got serverless conference, Serverless Days-- >> Serverless Days Boston. >> Boston, coming up-- >> April 6th in Cambridge. >> So give us a little views to kind of your view point for the year, the event itself, you got your podcast, you got a lot going on. >> Yeah, so my podcast, Serverless Chats. You know I talk to people that are in the space, and we usually get really really technical. So if you're a serverless geek or you like that kind of stuff definitely listen to that. But yeah, but 2020 for me though, this is where I see what is happened to serverless, and this goes back to my "Stop calling everything serverless" post, was this idea that we keep making serverless harder. And so, as a someone whose a serverless purist, I think at this point. I recognize and it frustrates me that it is so difficult now to even though we're abstracting away running that infrastructure, we still have to be very aware of what pieces of the infrastructure we are using. Still have setup the SQS Queue, still have to setup Event Bridge. We still have to setup the Lambda function and API gateways and there's services that make it easier for us, right like we can use a serverless framework, or the SAM framework, or ARCH code or architect framework. There's a bunch of these different ones that we can use. But the problem is that it's still very very tough, to understand how to stitch all this stuff together. So for me, what I think we're going to see in 2020, and I know there is hints for this serverless framework just launched their components. There's other companies that are doing similar things in the space, and that's basically creating, I guess what I would call an abstraction as a service, where essentially it's another layer of abstraction, on top of the DSL's like Terraform or Cloud Formation, and essentially what it's doing is it's saying, "I want to launch an API that does X-Y-Z." And that's the outcome that I want. Understanding all the best practices, am I supposed to use Lambda Destinations, do I use DLQ's, what should I throttle it at? All these different settings and configurations and knobs, even though they say that there's not a lot of knobs, there's a lot of knobs that you can turn. Encapsulating that and being able to share that so that other people can use it. That in and of itself would be very powerful, but where it becomes even more important and I think definitely from an enterprise standpoint, is to say, listen we have a team that is working on these serverless components or abstractions or whatever they are, and I want Team X to be able to use, I want them to be able to launch an API. Well you've got security concerns, you've got all kinds of things around compliance, you have what are the vetting process for third-party libraries, all that kind of stuff. If you could say to Team X, hey listen we've got this component, or this piece of, this abstracted piece of code for you, that you can take and now you can just launch an API, serverless API, and you don't have to worry about any of the regulations, you don't have to go to the attorneys, you don't have to do any of that stuff. That is going to be an extremely powerful vehicle for companies to adopt things quickly. So, I think that you have teams now that are experimenting with all of these little knobs. That gets very confusing, it gets very frustrating, I read articles all the time, that come out and I read through it, and this is all out of date, because things have changed so quickly and so if you have a way that your teams, you know and somebody who stays on top of the learning this can keep these things up to date, follow the most, you know leading practices or the best practices, whatever you want to call them. I think that's going to be hugely important step from making it to the teams that can adopt serverless more quickly. And I don't think the major cloud vendors are doing anything in this space. And I think SAM is a good idea, but basically SAM is just a re-write of the serverless framework. Whereas, I think that there's a couple of companies who are looking at it now, how do we take this, you know whatever, this 1500 line Cloud Formation template, how do we boil that down into two or three lines of configuration, and then a little bit of business logic. Because that's where we really want to get to. It's just we're writing business logic, we're no where near there right now. There's still a lot of stuff that has to be done, around configuration and so even though it's nice to say, hey we can just write some business logic and all the infrastructure is handled for us. The infrastructure is handled for us, if we configure it correctly. >> Yeah, really remind me some of the general thread we've been talking about, Cloud for a number of years is, remember back in the early days, is cloud is supposed to be inexpensive and easy to use, and of course in today's world, it isn't either of those things. So serverless needs to follow those threads, you know love some of those view points Jeremy. I want to give you the final word, you've got your Serverless Day Boston, you got your podcast, best way to get in touch with you, and keep up with all you're doing in 2020. >> Yeah, so @Jeremy_daly on Twitter. I'm pretty active on Twitter, and I put all my stuff out there. Serverless Chats podcast, you can just find, serverlesschats.com or any of the Pod catchers that you use. I also publish a newsletter that basically talks about what I'm talking about now, every week called Off by None, which is, collects a bunch of serverless links and gives them some IoPine on some of them, so you can go to offbynone.io and find that. My website is jeremydaly.com and I blog and keep up to date on all the kind of stuff that I do with serverless there. >> Jeremy, great content, thanks so much for joining us on theCube. Really glad and always love to shine a spotlight here in the Boston area too. >> Appreciate it. >> I'm Stu Miniman. You can find me on the Twitter's, I'm just @Stu thecube.net is of course where all our videos will be, we'll be at some of the events for 2020. Look for me, look for our co-hosts, reach out to us if there's an event that we should be at, and as always, thank you for watching theCube. (upbeat music)