>> Announcer: From San Francisco, it's theCUBE. Covering Red Hat Summit 2018 brought to you by Red Hat. >> Hello everyone and welcome back to see CUBE's exclusive coverage of Red Hat Summit 2018 live in San Francisco, California at Moscone West. I'm John Furrier, your cohost of theCUBE with John Troyer co-founder of Tech Reckoning advisory and community development firm. Our next two guests Mike Piech Vice President and General Manager of middleware at Red Hat and Mark Little, Vice President of Software Engineering for middleware at Red Hat. This is the stack wars right here. Guys thanks for coming back, good to see you guys again. >> Great to see you too. >> So we love Middleware because Dave Vellante and I and Stu always talk about like the real value is going to be created in abstraction layers. You're seeing examples of that all over the place but Kubernetes containers, multi-cloud conversations. Workload management and all these things are happening at these really cool abstraction layers. That's obviously you say global I say middleware but you know it's where the action is. So I got to ask you, super cool that you guys have been leading in there but the new stuff's happening. So let's just go review last year or was it this year? What's different this year, new things happening within the company? We see core OS' in there, you guys got OpenShift is humming along beautifully. What's new in the middleware group? >> There's a few things. I'll take one and then maybe Mike can think of another while I'm speaking but when we were here this time last year we were talking about functions as a service or server-less and we had a project of our own called Funktion with a K, between then and now the developer affinity around functions as a service has just grown. Lots of people are now using it and starting to use it in production. We did a review of what we were doing back then and looked around at other efforts that were in the market space and we decided actually we wanted to get involved with a large community of developers and try and move that in a direction that was pretty beneficial for everybody but clearly for ourselves. And we've decided, and we announced this publicly last year but we're now involved with a project called Apache OpenWhisk instead of Funktion. And OpenWhisk is a project that IBM originally kicked off. We got involved, it was tied very closely to cloud foundering so one of the first things that we've been doing is making it more Kubernetes native and allowing it to run on OpenShift. In fact we're making some announcements this week around our functions are service based on Apache OpenWhisk. But that's probably one of the bigger things that's changed in the last 12 months. >> I would just add to that that across the rest of the middleware portfolio which is as you know, a wide range of different technologies, different products, in our integration area we continue to push ahead with containerizing, putting the integration technologies in the containers, making it easier to basically connect the different components of applications and different applications to each other together through different integration paradigms whether it's messaging or more of a bus style. So with our Jboss Fuse and our AMQ we've made great progress in continuing to refine how those are invoked and consumed in the Openshift environment. Forthcoming very shortly, literally in the next week or two is our integration platform as a service based on the Fuse and AMQ technologies. In addition we've continued to charge ahead with our API management solution based on the technology we acquired from Threescale a couple of years ago. So that is coming along nicely, being very well adopted by our customers. Then further up the stack on the process automation front, so some of the business process management types of technologies we've continued to push ahead with containerizing and that was being higher up the stack and a little bit bigger a scale of technology was a little bit more complex in really setting it up for the containerized world but we've got our Process Automation 7.0 release coming out in the next few weeks. That includes some exciting new technology around case management, so really bringing all of those traditional middleware capabilities forward into the Cloud Native, containerized environment has been I would say the most significant focus of our efforts over the last year. >> Go ahead. >> Can you contextualize some of that a little bit for us? The OpenShift obviously a big topic of conversation here. You know the new thing that everyone's looking at and Kubernetes, but these service layers, these layers it takes to build an app still necessary, Jboss a piece of this stack is 17, 18 years old, right? So can you contextualize it a little bit for people thinking about okay we've got OpenStack on the bottom, we've got OpenShift, where does the middleware and the business process, how has that had to be modernized? And how are people, the Java developers, still fitting into the equation? >> Mark: So a lot of that contextualization can actually, if we go back about four or five years, we announced an initiative called Xpass which was to essentially take the rich middleware suite of products and capabilities we had, and decompose them into independently consumable services kind of like what you see when you look at AWS. They've got the simple queuing service, simple messaging service. We have those capabilities but in the past they were bundled together in an app server, so we worked to pull them apart and allow people to use them independently so if you wanted transactions, or you wanted security, you didn't have to consume the whole app server you actually had these as independent services, so that was Xpass. We've continued on that road for the past few years and a lot of those services are now available as part and parcel of OpenShift. To get to the developer side of things, then we put language veneers on top of those because we're a Java company, well at least middleware is, but there's a lot more than Java out there. There's a lot of people who like to use Pearl or PHP or JavaScript or Go, so we can provide language specific clients for them to interact. At the end of the day, your JavaScript developer who's using bulletproof, high performing messaging doesn't need to know that most of it is implemented in Java. It's just a complete opaque box to them in a way. >> John F: So this is a trend of microservices, this granularity concept of this decomposition, things that you guys are doing is to line up with what people want, work with services directly. >> Absolutely right, to give developers the entire spectrum of granularity. So they can basically architect at a granularity that's appropriate for the given part of their job they're working on it's not a one size fits all proposition. It's not like throw all the monoliths out and decompose every last workload into it's finest grain possible pieces. There's a time and a place for ultra-fine granularity and there's also a time and a place to group things together and with the way that we're providing our runtimes and the reference architectures and the general design paradigm that we're sort of curating and recommending for our customers, it really is all about, not just the right tool for the job but the right granularity for the job. >> It's really choice too, I mean people can choose and then based on their architecture they can manage it the way they want from a design standpoint. Alright I got to get your guys' opinion on something. Certainly we had a great week in Copenhagen last week, in Denmark, around CUBECon, Kubernetes conference, Cloud NativeCon, whatever it's called, they're called two things. There was a rallying cry around Kubernetes and really the community felt like that Linix moment or that TCPIP moment where people talk about standards but like when will we just do something? We got to get behind it and then differentiate and provide all kinds of coolness around it. Core defacto stand with Kubernetes is opening up all kinds of new creative license for developers, it's also bringing up an accelerated growth. Istio's right around the corner, Cubeflow have the cool stuff on how software's being built. >> Right. >> So very cool rallying cry. What is the rallying cry in middleware, in your world? Is there a similar impact going on and what is that? >> Yeah >> Because you guys are certainly affected by this, this is how software will be built. It's going to be orchestrated, composed, granularity options, all kinds of microservices, what's the rallying cry in the middleware? >> So I think the rallying cry, two years ago, at Summit we announced something called MicroProfile with IBM, with Tomitribe, another apps vendor, Piara and a few quite large Java user groups to try and do something innovative and microservices specific with Enterprise Java. It was incredibly successful but the big elephant in the room who wasn't involved in that was Oracle, who at the time was still controlling Java E and a lot of what we do is dependent on Java E, a lot of what other vendors who don't necessarily talk about it do is also dependent on Java E to one degree or another. Even Pivotal with Springboot requires a lot of core services like messaging and transactions that are defined in Java E. So two years further forward where we are today, we've been working with IBM and Oracle and others and we've actually moved, or in process of moving all of Java E away from the old process, away from a single vendor's control into the Eclipse Foundation and although that's going to take us a little while longer to do we've been on that path for about four or five months. The amount of buzz and interest in the community and from companies big and small who would never have got involved in Java E in the past is immense. We're seeing new people get involved with Eclipse Foundation, and new companies get involved with Eclipse Foundation on a daily basis so that they can get in there and start to innovate in Enterprise Java in a much more agile and interesting way than they could have done in the past. I think that's kind of our rallying call because like I said we're getting lots of vendors, Pivotal's involved, Fujitsu. >> John F: And the impact of this is going to be what? >> A lot more innovation, a lot quicker innovation and it's not going to be at the slow speed of standards it's going to be at the fast, upstream, open source innovative speed that we see in likes of Kubernetes. >> And Eclipse has got a good reputation as well. >> Yeah, the other significant thing here, in addition to the faster innovation is it's a way forward for all of that existing Java expertise, it's a way for some of the patterns and some of the knowledge that they have already to be applied in this new world of Cloud Native. So you're not throwing out all that and having to essentially retrain double digit millions of developers around the world. >> John F: It's instant developer actually and plus Java's a great language, it's the bulldozer of languages, it can move a lot, it does a lot of heavy lifting >> Yep. >> And there's a lot of developers out there. Okay, final question I know you guys got to go, thanks for spending the time on theCUBE, really appreciate certainly very relevant, middleware is key to the all the action. Lot of glue going on in that layers. What's going on at the show here for you guys? What's hot, what should people pay attention to? What should they look for? >> Mark: I'll give my take, what's hot is any talk to do with middleware >> (laughs) Biased. >> But kind of seriously we do have a lot of good stuff going on with messaging and Kafka. Kafka's really hot at the moment. We've just released our own project which is eventually going to become a product called Strimsy, integrated with OpenShift so it's coognative from the get-go, it's available now. We're integrating that with OpenWhisk, which we talked about earlier, and also with our own reactive async platform called Vertex, so there's a number of sessions on that and if I get a chance I'm hoping to say into one >> John F: So real quick though I mean streaming is important because you talk about granularity, people are going to start streaming services with service measures right around the corner, the notion of streaming asynchronously is going to be a huge deal >> Absolutely, absolutely. >> Mark: And tapping into that stream at any point in time and then pulling the plug and then doing the work based on that. >> Also real quick, Kubernetes, obviously the momentum is phenomenal in Cloud Native but becoming a first class citizen in the enterprise, still some work to do. Thoughts on that real quick? Would you say Kubernetes's Native, is it coming faster? Will it ever be, certainly I think it will be but. >> I think this is the year of Kubernetes and of enterprise Kubernetes. >> Mike: I mean you just look at the phenomenal growth of OpenShift and that in a way speaks directly to this point >> Mike, what's hot, what's hot? What are you doing at the show, what should we look at? I'd add to, I certainly would echo the points Mark made and in addition to that I would take a look at any session here on API management. Again within middleware the three-scale technology we acquired is still going gangbusters, the customers are loving that, finding it extremely helpful as they start to navigate the complexity of doing essentially distributive computing using containers and microservices, getting more disciplined about API management is of huge relevance in that world, so that would be the next thing I'd add. >> Congratulations guys, finally the operating system called the Cloud is taking over the world. It's basically distributed computer all connected together, it sounds like >> All that stuff we learned in the eighties right (laughs) >> It's a systems world, the middleware is changing the game, modern software construction of Apple cases all being done in a new way, looking at orchestration, server lists, service meshes all happening in real time, guys congratulations on the all the work and Red Hats. Be keeping it in the open, Java E coming around the corner as well, it's theCUBE bringing it out in the open here in San Francisco, I'm John Furrier with John Troyer we'll be back with more live coverage after this short break

>> Announcer: From Copenhagen, Denmark, it's theCUBE. Covering KubeCon and CloudNativeCon Europe 2018. Brought to you by the Cloud Native Computing Foundation and its ecosystem partners. >> Hello and welcome back to the live CUBE coverage here in Copenhagen, Denmark, for KubeCon 2018, Kubernetes European conference. This is theCUBE, I'm John Furrier, my co-host Lauren Cooney here with Adrian Cockcroft who is the Vice President of Cloud Architecture and Strategy for Amazon Web Services, AWS. CUBE alumni, great to see you, a legend in the industry, great to have you on board today. Thanks for coming on. >> Thanks very much. >> Quick update, Amazon, we were at AWS Summit recently, I was at re:Invent last year, it gets bigger and bigger just continue to grow. Congratulations on successful great earnings. You guys posted last week, just continuing to show the scale and leverage that the cloud has. So, again, nothing really new here, cloud is winning and the model of choice. So you guys are doing a great job, so congratulations. Open source, you're handling a lot of that now. This community here, is all about driving cloud standards. >> Adrian: Yeah. >> Your guys position on that is? Standards are great, you do what customers want, as Andy Jassy always says, what's the update? I mean, what's new since Austin last year? >> Yeah, well, it's been great to be back on had a great video of us talking at Austin, it's been very helpful to get the message out of what we're doing in containers and what the open source team that I lead has been up to. It's been very nice. Since then we've done quite a lot. We were talking about doing things then, which we've now actually done and delivered on. We're getting closer to getting our Kubernetes service out, EKS. We hired Bob Wise, he started with us in January, he's the general manager of EKS. Some of you may know Bob has been working with Kubernetes since the early days. He was on the CNCF board before he joined us. He's working very hard, they have a team cranking away on all the things we need to do to get the EKS service out. So that's been major focus, just get it out. We have a lot of people signed up for the preview. Huge interest, we're onboarding a lot of people every week, and we're getting good feedback from people. We have demos of it in the booth here this week. >> So you guys are very customer-centric, following you guys closely as you know. What's the feedback that you're hearing and what are you guys ingesting from an intelligence standpoint from the field. Obviously, a new constituent, not new, but a major constituent is open source communities, as well as paying enterprise customers? What's the feedback? What are you hearing? I would say beyond tire kicking, there's general interest in what Kubernetes has enabled. What's Amazon's view of that? >> Yeah, well, open source in general is always getting a larger slice of what people want to do. Generally, people are trying to get off of their enterprise solutions and evolving into an open source space and then you kind of evolve from that into buying it as a service. So that's kind of the evolution from one trend, custom or enterprise software, to open source to as a service. And we're standing up all of these tools as a service to make them easier to consume for people. Just, everybody's happy to do that. What I'm hearing from customers is that that's what they're looking for. They want it to be easy to use, they want it to scale, they want it to be reliable and work, and that's what we're good at doing. And then they want to track the latest moves in the industry and run with the latest technologies and that's what Kubernetes and the CNCF is doing, gathering together a lot of technologies. Building the community around it, just able to move faster than we'd move on our own. We're leveraging all of those things into what we're doing. >> And the status of EKS right now is in preview? And the estimated timetable for GA? >> In the next few months. >> Next few months. >> You know, get it out then right now it's running in Oregon, in our Oregon data center, so the previews are all happening there. That gets us our initial thing and then everyone go okay, we want to in our other regions, so we have to do that. So another service we have is Fargate, which is basically say just here's a container, I want to run it, you don't have to declare a node or an instance to run it first. We launched that at re:Invent, that's already in production obviously, we just rolled that out to four regions. That's in Virginia, Oregon, Dublin and Ohio right now. A huge interest in Fargate, it lets you simplify your deployments a little bit. We just posted a new blog post that we have an open source blog, you can find if you want to keep up with what's going on with the open source team at AWS. Just another post this morning and it's a first pass at getting Fargate to work with Kubernetes using Virtual Kubelet which is a project that was kicked off by, it's an experimental project, not part of the core Kubernetes system. But it's running on the side. It's something that Microsoft came up with a little while ago. So we now have, we're working with them. We did a pull request, they accepted it, so that team and AWS and a few other customers and other people in the community, working together to provide you a way to start up Fargate as the underlying layer for provisioning containers underneath Kubernetes as the API for doing you know the management of that. >> So who do you work with mostly when you're working in open source? Who do you partner with? What communities are you engaging with in particular? >> It's all over. >> All over? >> Wherever the communities are we're engaging with them. >> Lauren: Okay, any particular ones that stand out? >> Other than CNCF, we have a lot of engagement with Apache Hadoop ecosystem. A lot of work in data science, there's many, many projects in that space. In AI and machine learning, we've sponsored, we've spend a lot of time working with Apache MXNet, we were also working off with TensorFlow by Torch and Caffe and there's a lot, those are all open source frameworks so there's lots of contributions there. In the serverless arena, we have our own SAM service application model. We've been open sourcing more of that recently ourselves and we're working with various other people. Across these different groups there's different conferences you go to, there's different things we do. We just sponsored Rails Conference. My team sponsors and manages most of the open source conference events we go to now. We just did RAILCON, we're doing a Rust conference, soon I think, there's Python conferences. I forget when all these are. There's a massive calendar of conferences that we're supporting. >> Make sure you email us that that list, we're interested actually in looking at what the news and action is. >> So the language ones, AltCon's our flagship one, we'll be top-level sponsor there. When we get to the U.S., CubeCon in Seattle, it's right there, it's two weeks after re:Invent. It's going to be much easier to manage. When we go to re:Invent it's like everyone just wants to take that week off, right. We got a week for everyone to recover and then it's in the hometown. >> You still have that look in your eyes when we interviewed you in Austin you came down, we both were pretty exhausted after re:Invent. >> Yeah, so we announced a bunch of things on Wednesday and Thursday and I had to turn it into a keynote by Tuesday and get everyone to agree. That's what was going on, that was very compressed. We have more time and all of the engineering teams that really want to be at an event like this, were right in the hometown for a lot. >> What's it like workin' at Amazon, I got to ask you it since you brought it up. I mean and you guys run hard at Amazon, you're releasing stuff with a pace that's unbelievable. I mean, I get blown away every year. Almost seems like, inhuman that that you guys can run at that pace. And earnings, obviously, the business results speak for themselves, what's it like there? I mean, you put your running shoes on, you run a marathon every day. >> It's lots of small teams working relatively independently and that scales and that's something other engineering organizations have trouble with. They build hierarchies that slow down. We have a really good engineering culture where every time you start a new team, it runs at its own speed. We've shown that as we add more and more resources, more teams, they are just executing. In fact, their accelerated, they're building on top of other things. We get to build higher and higher level abstractions to layer into. Just getting easier and easier to build things. We're accelerating our pace of innovation there's no slowing down. >> I was telling Jassy they're going to write a Harvard Business School case study on a lot of the management practices, but certainly the impact on the business side with the model that you guys do. But I got to ask you, on the momentum side, super impressed with SageMaker. I predicted on theCUBE at AWS Summit that that will be the fastest growing service. It will overtake Aurora, I think that is currently on stage, presented as the fastest growing service. SageMaker is really popular. Updates there, its role in the community. Obviously, Kubernete's a good fit for orchestrating things. We heard about CubeFlow, is an interesting model. What's going on with SageMaker how is it interplaying with Kubernetes? >> People that want to run, if you're running on-premise, cluster of GPU enabled machines then CubeFlow is a great way of doing that. You're on TensorFlow, that manages your cluster, you run CubeFlow on top. SageMaker is running at very low scale and like a lot of things we do at AWS, what you need to run an individual cluster for any one customer is different from running a multi-tenant service. SageMaker sits on top of ECS and it's now one of the largest generators of traffic to ECS which is Amazon's horizontally scaled, multi-tenant, cluster management system, which is now doing hundreds of millions of container launches a week. That is continuing to grow. We see Kubernetes as it's a more portable abstraction. It has some more, different layers of API's and a big community around it. But for the heavy lifting of running tens of thousands of containers in for a single application, we're still at the level where ECS does that every day and Kubernetes that's kind of the extreme case, where a few people are pushing it. It'll gradually grow scale. >> It's evolution. >> There's an evolution here. But the interesting things are, we're starting to get some convergence on some of the interfaces. Like the interfacing at CNA, CNA is the way you do networking on containers and there is one way of doing that, that is shared by everybody through CNA. EKS uses it, BCS uses it and Kubernetes uses it. >> And the impact of customers is what for that? What's the impact? >> It means the networking structures you want to set up will be the same. And the capabilities and the interfaces. But what happens on AWS is because it has a direct plug-in, you can hook it up to our accelerated networking infrastructure. So, AWS's instances right now, we've offloaded most of the network traffic processing. You're running 25 gigabits of traffic, that's quite a lot of work even for a big CPU, but it's handled by the the Nitro plug-in architecture we have, this in our latest instance type. So if you talked a bit about that at re:Invent but what you're getting is enormous, complete hypervisor offload at the core machine level. You get to use that accelerated networking. You're plugging into that interface. But that, if you want to have a huge number of containers on a machine and you're not really trying to drive very high throughput, then you can use Calico and we support that as well. So, multiple different ways but all through the same thing, the same plug-ins on both. >> System portability. You mentioned some stats, what's the numbers you mentioned? How many containers you're launching a week, hundreds of thousands? On ECS, our container platform that's been out for a few years, so hundreds of millions a week. It's really growing very fast. The containers are taking off everywhere. >> Microservices growth is, again that's the architecture. As architecture is a big part of the conversation what's your dialogue with customers? Because the modern software architecture in cloud, looks a lot different than what it was in the three layered approach that used to be the web stack. >> Yeah, and I think to add to that, you know we were just talking to folks about how in large enterprise organizations, you're still finding groups that do waterfall development. How are you working to kind of bring these customers and these developers into the future, per se? >> Yeah, that's actually, I spend about half my time managing the open source team and recruiting. The other half is talking to customers about this topic. I spend my time traveling around the world, talking at summits and events like this and meeting with customers. There's lots of different problems slowing people down. I think you see three phases of adoption of cloud, in general. One is just speed. I want to get something done quickly, I have a business need, I want to do it. I want machines in minutes instead of months, right, and that speeds everything up so you get something done quickly. The second phase is where you're starting to do stuff at scale and that's where you need cloud native. You really need to have elastic services, you can scale down as well as up, otherwise, you just end up with a lot of idle machines that cost you too much and it's not giving you the flexibility. The third phase we're getting into is complete data center shutdown. If you look at investing in a new data center or data center refresh or just opening an AWS account, it really doesn't make sense nowadays. We're seeing lots of large enterprises either considering it or well into it. Some are a long way into this. When you shut down the data center all of the backend core infrastructure starts coming out. So we're starting to see sort of mainframe replacement and the really critical business systems being replaced. Those are the interesting conversations, that's one of the areas that I'm particularly interested in right now and it's leading into this other buzzword, if you like, called chaos engineering. Which is sort of the, think of it as the availability model for cloud native and microservices. We're just starting a working group at CNCF around chaos engineering, is being started this week. So you can get a bit involved in how we can build some standards. >> That's going to be at Stanford? >> It's here, I mean it's a working group. >> Okay, online. >> The CNCF working group, they are wherever the people are, right. >> So, what is that conversation when you talk about that mainframe kind of conversation or shut down data centers to the cloud. What is the key thing that you promote, up front, that needs to get done by the by the customer? I mean, obviously you have the pillars, the key pillars, but you think about microservices it's a global platform, it's not a lift and shift situation, kind of is, it shut down, but I mean not at that scale. But, security, identity, authentication, there's no perimeter so you know microservices, potentially going to scale. What are the things that you promote upfront, that they have to do up front. What are the up front, table stake decisions? >> For management level, the real problem is people problems. And it's a technology problem somewhere down in the weeds. Really, if you don't get the people structures right then you'll spend forever going through these migrations. So if you sort of bite the bullet and do the reorganization that's needed first and get the right people in the right place, then you move much faster through it. I say a lot of the time, we're way upstream of picking a technology, it's much more about understanding the sort of DevOps, Agile and the organizational structures for these more cellular based organizations, you know, AWS is a great example of that. Netflix are another good example of that. Capital One is becoming a good example of that too. In banking, they're going much faster because they've already gone through that. >> So they're taking the Amazon model, small teams. Is that your general recommendation? What's your general recommendation? >> Well, this is the whole point of microservices, is that they're built by these small teams. It's called Conway's law, which says that the code will end up looking like the team, the org structure that built it. So, if you set up a lots of small teams, you will end up with microservices. That's just the way it works, right. If you try to take your existing siloed architecture with your long waterfall things, it's very hard not to build a monolith. Getting the org structure done first is right. Then we get into kind of the landing zone thing. You could spend years just debating what your architecture should be and some people have and then every year they come back, and it's changing faster than they can decide what to do. That's another kind of like analysis paralysis mode you see some larger enterprises in. I always think just do it. What's the standard best practice, layout my accounts like this, my networks like this, my structures we call it landing zone. We get somebody up to speed incredibly quickly and it's the beaten path. We're starting to build automation around these on boarding things, we're just getting stuff going. >> That's great. >> Yeah, and then going back to the sort of chaos engineering kind of idea, one of the first things I should think you should put into this infrastructure is the disaster recovery automation. Because if that gets there before the apps do, then the apps learn to live with the chaos monkeys and things like that. Really, one of the first apps we installed at Netflix was Chaos Monkey. It wasn't added later, it was there when you arrived. Your app had to survive the chaos that was in the system. So, think of that as, it used to be disaster recovery was incredibly expensive, hard to build, custom and very difficult to test. People very rarely run through their disaster recovery testing data center fail over, but if you build it in on day one, you can build it automated. I think Kubernetes is particularly interesting because the API's to do that automation are there. So we're looking at automating injecting failure at the Kubernetes level and also injecting into the underlying machines that are running Good Maze, like attacking the control plane to make sure that the control plane recovery works. I think there's a lot we can do there to automate it and make it into a low-cost, productized, safe, reliable thing, that you do a lot. Rather than being something that everyone's scared of doing that. >> Or they bolted on after they make decisions and the retrofit, pre-existing conditions into a disaster recovery. Which is chaotic in and of itself. >> So, get the org chart right and then actually get the disaster recovery patterns. If you need something highly available, do that first, before the apps turn up. >> Adrian, thanks for coming on, chaos engineering, congratulations and again, we know you know a little about Netflix, you know that environment, and been big Amazon customer. Congratulations on your success, looking forward to keeping in touch. Thanks for coming on and sharing the AWS perspective on theCUBE. I'm John Furrier, Lauren Cooney live in Denmark for KubeCon 2018 part of the CNC at the Cloud Native Compute Foundation. We'll back with more live coverage, stay with us. We'll be right back. (upbeat music)