>> Announcer: Live from Las Vegas, it's theCUBE, covering ServiceNow Knowledge 2018. Brought to you by ServiceNow. >> Hello everyone and welcome back to theCube's live coverage of ServiceNow Knowledge 18 here in Las Vegas. I'm your host Rebacca Knight along with my co-host Dave Vellante, and we are theCube. We are the leader in live tech coverage. We're joined by Sean Caron. He is the principal architect of Linium, at Linium. Thanks so much for coming on theCube again, you're welcome back. >> My second time, and thank you very much for the opportunity. I've really been looking forward to it all week. >> Awesome, Good to have you back. >> We love to hear that. So tell us about Linium and what you do as principal architect. >> Sure, so we are a gold services and sales partner of ServiceNow. Been in the ServiceNow space for about nine years total. And we specialize in helping organizations do digital transformations. So they want to take the platform and really get maximum value from that and that's both a technology discussion, but it's also a organizational change discussion, and you know can be a process discussion. All those kind of things are things that we help our customers with. >> We've been talking a lot about the technology but the organizational change is really what fascinates me. Can you tell, can you just talk about a lot of the organizational change challenges that customers are facing, and they come to you. >> You've got it right. So we've been in this business for 18 years. We started out as a Peregrine partner and also HP, when HP acquired Peregrine, and we noticed that we would get specs from customers and we would nail it. It would be a perfect technical delivery and then six months later when you talk to the customer, they weren't using the product. They didn't get any value from the investment that they made. So we started to engineer a process and we do that around, you know we look at the structure. Where is this project going to land? What's the structure around it? Who supports it? What's your culture? Do you have a culture of dedication to accuracy or customer service? If you don't have those kind of things, we can help build those in your organization. And of course that also gets to helping you find talent, right. So if you need the right people, we can help with that process. Helping you define business best practice process for your organization. Those are all things we work with customers every day and frankly we don't do technology projects. We only do a project where we know when we deliver the technology that that structure will be there to catch it and get value from it. >> So you were recently acquired by Ness Digital Engineering, >> Correct >> Which is really an interesting name for a company. Tell us more about the motivation for that acquisition and how things have changed, and what the future looks like. >> So for the first 17 years of our business we were a privately held company and we grew organically, and we did a great job at that. I mean we became several hundred employees across the U.S. and a couple in AMIA, and a couple in Canada. But to really take the next step right, we saw, we had a vision of what we wanted to do, to take that next step was going to require an equity investment of some type. So we started probably about this time last year, talking to organizations. Ness was one of the first ones that we met and it became immediately apparent that they were a great fit for us. So they have about, well with us about 4,000 people across the world. They're not a billion dollar company right. So their culture is very similar to our culture. They do digital engineering projects, industrial scale, you know hard core grade digital engineering projects, and they tend to focus on platforms that are front of the business, so customer touching. They own the platform under Standard & Poor's right, so they built that. So Standard Poor's ratings, all that information flows in, they do the ratings based on that. That's something they built. PayPal, they do a lot of work in the payments industry. But they didn't really do much on the backend right. The operations that keep all the lights on and obviously that's a great fit for Linium, where we would come in with the ServiceNow platform and help them with that process. So that really worked out well. It was a great fit for us. >> So how do you guys compete? What's your difference relative to, you've been here a while in this ecosystem. It's started to get crowded. How do you, what's your secret sauce? How do you guys compete? >> So our goal is always to try and stay 12 months ahead of where ServiceNow is going. In the past couple of years, that really has been around user experience. Really designing experiences with the platform that are intuitive, that don't require a lot of training, that allow people to approach the platform and get value from it very quickly. Whether that's end users, or our customer's customers. Those kind of things, really, and that's in our DNA. That's a big part of what we do is design these experiences and do them in a way that really help our customers get value. I would say, you know looking forward, so the buzzword that we've heard around here this week is DevOps right, and we see, and one of the things that Ness does very well is DevOps engineering. I think next year will be the knowledge of DevOps. It will be what everybody's talkin' about. ServiceNow will have a lot more throw-weight in that space. So really that's where we're going. We're helping people get that continuous integration, continuous deployment process using ServiceNow as a foundation. >> CJ Desai laid out the roadmap in more detail than I had seen publicly anyway, and we were talking to him and he said, "Look the motivation really came from the ecosystem." You know obviously the customers as well, but the ecosystem as well, wanted better visibility on what was coming, because you guys have to plan for that. You're tryin' to fill white space. You're tryin' to fill a vacuum. So I wondered if you could talk about that. It's a two-edged coin though right? I mean, but having that visibility has to be a godsend. >> Right and we found that when we are some number of months ahead of ServiceNow, we work very well with them. We, you know obviously, like any large ServiceNow partner, we're very plugged in to where they're going. Their roadmap sets our direction and the kind of things that we can do. But it enables conversations, especially DevOps, and user experience too, enabled conversations at new levels within the organization and that's a big differentiator for us. >> But so, what I'm trying to understand is you guys have to make a call on where to put your investments and your resources, and you don't want to, you've said a couple of times, you're ahead of ServiceNow by, let's say N months, six months, 12 months, 9 months, whatever it is. You don't want to develop something and put too much into something that they're just going to replace in a few months. >> Right. >> Dave: So how do you keep that innovation engine going on your end? >> That right, so it takes a lot of research. We have a person whose dedicated job at our organization is Chief Innovation Officer. She spends her entire day talking to customers, hearing what buzzwords are in the industry, looking and talking to ServiceNow, looking at where they're going. So how can we be positioned when ServiceNow gets there 'cause to deliver services, that's not an instant on right. If the technology shows up tomorrow in the next release, to be able to deliver services for that, you have to start well in advance to actually be able to do that, to understand the process, and the structure, and what's required. >> I see, okay so by being ahead of ServiceNow, what you mean is you're going to develop capabilities that plug in to their release when it hits. >> So that we can deliver to what they have, >> Not things that are duplicative, but things that are, add value when it hits. >> Yeah, I mean ServiceNow comes out with, let's say automated testing. That's something they want to really, they want to get into the automated testing market. That's a discipline. You can't be instant on with that and if you want to have credibility with customers, you have to have trained people. You've got to be six months ahead to be able to step into that world and get value from the platform. >> So take the DevOps example that we heard Pat Casey talk about yesterday. So you guys are preparing for that now obviously. >> Yes. >> And how will you go about it? How will that change your customers world? If can take us through an example. >> So obviously DevOps is, you know it's the big accelerator. It's the idea of we're going to do what we've always done and we're going to do it in timeframes that are minutes or hours, as opposed to weeks, or months, or even years right, so it's a big ramp up. So understanding how to put that in play is a big deal. If you're a startup, alright so one of the themes of DevOps is the two pizza team right. You should never have teams bigger than you can feed with a couple of pizzas. If you're a startup and you already got a two pizza team it's easy to do DevOps. You build it into your culture and away you go. But our customers, you know many of our customers, one we were talkin' about here, talking to here at the show, 130 year old firm and they want to do DevOps. So what's that on-ramp? How do you figure that out? One of our new colleagues from Ness, who has been in the DevOps world for a while says, "You know, it's all about unlearning stuff." Because in order to move into this world, you got to unlearn that old world. >> Well right, it is a mindset. >> It is, it's a culture. >> So how, and one that will be very tricky for a 130 year old firm that maybe doesn't order pizzas that often (chuckling) for it's team. So how do you do that? I mean that's a challenge. >> We're working diligently on having a roadmap to onboard DevOps into existing organizations. The secret really tends to be, start with a NET new project and introduce DevOps into those kind of projects. Build one, build two, build three now you've got a culture of DevOps and you can start then to do some of the unlearning and the retrofitting right. But it's very difficult. You can't really take an existing projects and transform how they do their work. Which is what DevOps is all about. >> No, but in a lot of the companies that I've talked to that have, you know hundred plus year old companies that want to do DevOps right. A lot of times, and I wonder if this has been your experience, it's the Ops guys learning Dev, as opposed to the Dev guys learning Ops. I mean the Dev guys like, "Yeah, yeah we can do infrastructure as code, that's fine", but then you've got all these Ops guys runnin' around. So it's a urgency to retrain the Ops guys, who are eager to learn, most of 'em. The ones that aren't probably in trouble. >> Will do something else. >> So I often joke about OpsDev versus DevOps. What's your experience? >> So I think the big difference is Ops guys are trained from the day they take that job to, you know shun failure right. Failure of a system is a big problem. In DevOps it's going to happen. Not only is it going to happen but the best DevOps practitioners create failure. >> Break stuff (laughing) >> Yeah, you know Netflix kind of has this famous program called Chaos Monkey, when it runs running, turn stuff off right, and how do you respond to that. And that's a big leap culturally and structurally for the Ops guys to get over that. You know the idea is we break stuff, but we learn from that, and not only do I learn from that, but I spread that knowledge across the organization. And that's where ServiceNow steps in right, because they know when things are broken, 'cause they're tied to monitoring, and they got this great knowledge capability to hook up the information we learn from how that broke. So what better testing could we have done so that we could have avoided that break? Or if it's a enforced break, what could we have learned about how to respond to that more quickly? You know the classic example is when AWS lost their east availability center and Netflix kept tickin' because they had lost their east availability center through Chaos Monkey a half a dozen times. >> Right >> It was old hat, and everybody else kind of went dark right. So that idea, and enabling that with the ServiceNow platform is a great opportunity. We really see ServiceNow as the context, the engine with all the knowledge about when things happen, how to fix them, and how to record the knowledge that you learn. >> Give us an example of a company, I mean you're talking about simple, streamlined, intuitive tech, no-training required, so give us some examples of some of the most creative uses. >> I'll give you a great example. So, we have a center in Atlanta. We have some folks in Atlanta. And of course if your in Atlanta, you love Chick-fil-a, and maybe if you're anywhere else you love Chick-fil-a. And they had an issue, which was they have franchisees, and their franchises are different from McDonald's, where you might have one franchisee at McDonald's that owns 200 restaurants. They have a lot of power, market power, and they don't share information with any other franchisee, 'cause that's differentiating for them. Chick-fil-a doesn't do that. The maximum number of restaurants you can own as a Chick-fil-a franchisee I believe is three. It's a number like that. So their franchisees are incented to talk to each other and share information. "Hey I found a better way to clean the ice cream machine", or something like that or to fix a problem. So they were looking to build a portal that they could use to both answer questions from the organization to the franchisees, but allow the franchisees to talk to each other. That kind of a thing has to be zero training right, because the people who are on that might be store managers, but it could be, you know the teenager who runs the point of sale terminal and is havin' a problem with that, so it's really got to be intuitive. So we spent a lot of time with them. We actually, it was we brought one of our designers, so we have UI, UX designers, experience designers, and we were in the sales meeting, and we're having a discussion about what they need, and he's kind of heads down typin' on his computer. And they're kind of lookin' at him like, what's up with this guy right, he's not payin' attention. >> He's designing the interface. >> These guys pay attention to everything. He's lookin' at the logo as we're walkin' in, the colors that are on the wall, the way they talk about themselves. So about an hour into the meeting we got a pause and he just kind of picks his head up and goes, "You mean like this?" And turned his computer around and he had a prototype that he built in the meeting of this really easy to use process. >> Very cool. >> Sean: So that was our intro to Chick-fil-a. >> Your sales guy must'a hated that. (hosts laughing) >> No, no, it was, I'll tell you what, so it was competitive, we have multiple competitors, who were going for that business, when he turned that computer around, the sale was done. >> Dave: Boom. >> We were done, right. They looked at that and said, This is, you know it's not perfect clearly, but this is what we need. >> This is the kind of company we want to work with. >> Exactly, well and that, you know part of that is there are partners in the ecosystem who come in and say, "We can do anything. "Tell us what you want." We are much more consultative and we'll come in and be prescriptive and say this is what you should do, and it's a differentiator for us. It's something we do differently. >> Well Sean that's a great note to end on. Thanks so much for coming on theCUBE again. >> It's been great, I really enjoyed my time. >> We'll look forward to having you back at Knowledge 19. >> Terrific, I will certainly be here. >> Great, I'm Rebecca Knight for Dave Vellante. We will have more of theCUBE's live coverage of ServiceNow Knowledge 18 in just a little bit. (electronic music)

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