AWS re:Invent 2018: autonomous DevSecOps: five steps to a self-driving cloud

Disclaimer: Automated Transcript

All right well good evening and thanks everyone for coming out I know it's halfway through reinvent we're all pretty much exhausted hopefully not still too hungover from last night so we can pick it up again tonight but appreciate some banging sometime with me um what we're going to talk about today is five steps towards a self-driving cloud if you expect me to drive a car around the stage you're in the wrong room I won't be doing that what we'll be talking about instead is how you can automate your cloud services to wrap your developers and your application teams giving them a lot of freedom while keeping it safe for your organization we're really trying to work out how to speed this up how to make it go faster how to make it go easier and how to really keep it secure as we move with more and more speed so I'm Nathan Wallace and mostly this founder and CEO of turbot we spend our entire life thinking about this problem working with all sorts of large organizations on it and prior to that I was actually in one of those large organizations trying to solve it at scale you can listen to me because here I've done cloud formation stacks running those accidentally deleting the VPC underneath me while on the server inside it you could listen to me because I've had to sit in front of the VP of security of a large organization explaining why that one little window server that was not inside the network even became insecure and someone hacked it because someone did a stupid password and then that became a new reputation risk for us so I've been through those sorts of problems and thought about

It deeply works with our team on that and felt that pain very very acutely and hopefully we can all work together to ever avoid it more in the future so we're gonna talk about today is really what does it mean to get towards a cloud that is truly automated how do we get there what are the challenges on the way what does it you where are we now and all the different things we're doing whether it's you know infrastructure is code etc because we're making good progress but there is a long way to go and I just want to talk about that a bit frame that problem help everybody think about how you're tackling it and how much more there is to do but how much progress we've made and that will really come down to the concept of governance and how you can think about providing safety around your teams and that acceleration of them or if you are one of those teams how you can convince the rest of your organization to give you that freedom and it really will be safe and secure so as I've moved to cloud away from our traditional data center everything changed it become quite difficult and different how we have to manage that environment we try to pretend it's the same all all the time just because you know it's easier to describe so yeah it's the same just a bit faster and all that but it really has changed the requirements on us and made life a lot more difficult in a bunch of ways in particular it's just so much more agile we know this we're here look at the new features coming up this week there is so much going on here at such an incredible pace that you have to work out how you're going to embrace this free organization and ride this rocket you can't create services in competition with it you will get beaten right you have to think about how you're going to do that faster and embrace these things at speed the second thing is and this is often uncomfortable statement but application teams really control the infrastructure now infrastructure has become part of the app whether it's auto scaling or whether it's you know running a large function that does something creating storage locations moving those things around applications control the infrastructure that's how they can manage their costs that's how they do things so quickly right it's no longer we give them a big fat server and here with one capex and leave it there for five years right what it is now is a world of constantly changing we have to work out how to empower our application teams with that in a way where they can do it faster and more safely the second thing or point is that we thought that agility we still need to keep some control.

What even more challenging those expectations have gone through the roof you imagine not having encrypted data now but in traditional data center that was you know hard to the point of being acceptable you didn't have it you have to meet those expectations the new service comes out you have to implement it otherwise you're behind and then if you get stuck you're in trouble right so you've got to work out how you're going to meet those constantly evolving expectations and they are high and getting higher and that is a fan plastic thing but it's not easy to keep up with it's a lot to learn I'm sure most of your brains are feeling fairly fried at this point after days of sessions already in announcements but as we have all that jelly of the infrastructure we also have to work out and make it real time so don't only do we have higher expectations but we have to be able to do it instantly when they create things they have to be done immediately we can't review it if we have to have a meeting about it it's not agile anymore we lost cloud right there 10 minutes over between the six-week server like we used to have.

We've got to think about how to do that in real time and frankly that means it's got to be software you have to move your operations towards software manual processes will always slow you down to the point where you've killed the agility and it's really tough to think about that that means launching a new server has to go from the point of choosing the server getting the hardware being provisioned coming up getting hardened being patched and made available to the user to log in within minutes otherwise it's not cloud right and that's the same for all those different parts whether it's storage planters functions etc now to be able to achieve that level of speed and control the only way we're going to get there is with clear consistent repeatable patterns clear architectures architectures that tie together all those pieces so that we get to the 10-minute server although you know five-minute lambda or whatever you want to call if you have to get approval for that I am roll that your wrapping around that then you are too slow so we've got to constantly think about how that whole architecture works together to deliver that goal for the user what's exciting about that though is as we've empowered those application teams given them that level of control we no longer have to play whack-a-mole or tickets or have their project managers yelling at our project managers working out how we're going to get stuff to live it on time we can just sit there and do it instantly and that creates a whole new level of collaboration and partnership between your teams that is very transformative when you're no longer a block or a man you've got to do that it's more of a how can we do that together conversation everybody starts moving more quickly right Security's now at the table working with you yeah seems our thinking about it you're developers are there and you can learn and evolve through those new services together there's no other way you'll get there how could a cloud team be expert in all of them right and application teams need that level of support so really it has changed the way we have to function the organization we call it DevOps right we work out how to do that together but we think a really fundamental part of it is automating that governance layer because that's what enables it to happen in the real time that we need.

So what does it mean to have a self-driving cloud what does a future vision of that look like right so let's think about a real self-driving car and start to draw some analogies hopefully would stretch it too far it'll make sense the first thing that we usually take for granted when we think about self-driving cars we all know that's an incredibly hard problem right everybody's struggling whether people are putting humans back in those cars to make sure they're safe right as recently as yesterday right but basically with cars we kind of take for granted that the rules and regulations are pretty well-defined stop signs traffic lights essentially we don't really even really worry about that compare that to the world of infrastructure how well-defined are your rules and regulations okay there's the NIST 853 there's CIOs guidelines there's PCI there's hippo that's GXP you can choose which one of those you care about now generally the same but they're also all pretty wordy they're not totally specific right and each organization has different things you need to do within that if you try and make all of your applications meet the most compliant I think you slow yourself down the point of doing nothing so working out how we're going to define those rules and regulations and a sense of pattern is actually a really hard on self problem that we happen to have as we think about a self-driving cloud it's one we normally take for granted of course once we have that we want to lay out various infrastructure roads bridges this is the stuff we're used to doing today we get pretty excited about our automation and it is really cool stuff I mean I was talking to a customer yesterday they're using you Athena with s3 with all those glue services they're doing you searching seven billion transactions for five seconds and the kind of annoyed it's not a bit faster right that's what we take for granted for infrastructure now and it's available to us but we've got to work out how to build it where the roads gonna go what type of bridges do we want right what's our patterns of traffic of course once that's up there's operating conditions well I have a direct connect but it's very through a router and someone back ODE through the wire you know there's all that sort of stuff affecting the way we're operating and we need to still make sure it's safe enough functioning correctly so we have to trout the struggle with that challenge by the way that's what a lot of software because of thinking about is their primary challenge well we can do it but it's hard in the snow right that's actually just want another one of ours after we already had to solve things like rules and regulations etc

There's the application itself which you know we can announce near call the car for the purpose of this conversation and then there's also two sensors in that environment what's the status of the traffic what's the status of my car what else is going on in the environment the next one is the ops we think of that as software-defined operations how can we empower that car with that self-driving unit that capability so the application knows how to move forward it's operating an infrastructure environment that's starting to look after itself of course we're not in there alone there's all the other applications in the environment yeah we all know what we're doing but all of the people work and we've probably don't right and then there's also the actors in bad actors good actors other actors in the environment constantly trying to attack or make trouble for us we've got to work out how to deal with all of that in real time meanwhile in the middle of all that's the poor lonely driver or operations team trying to get through avoid the potholes make it work and hopefully that's where our software-defined operations can really speed them up of course the the wrench we throw into it is that we're not have static roads that everybody else did we don't have a few car manufacturers making really cool things we say to the developers lay your roads build your cars do it yourself right so we've not only taken a hard undefined problem with all those different components we've said to these people going Hut's build what you'd like let's see where you end up innovate do infrastructure as code stand something up in the console it'll be amazing so they're running around like maniacs doing that and we're not only trying to automate how they're driving on the roads we're trying to automate how they're actually building the roads so that leaves us with a whole bunch of work that we've had to do and the question is where are we now how much progress are we making on this problem we framed it it's a big one I think it's a very worthwhile goal but where are we so here we go back to you know the standard for self-driving cars again just gives us a nice framework to be able to talk through and think about right so we all started with a level of no automation

We click around a bit in the console we think about what we're doing we hope that it comes together frankly that's where most of us starting club and it's an incredible thing I mean the power of creating those VB sees all those networks for the first time it is mind-blowing after you used to wiring up servers and all that stuff in the background or data centers or a big building buildings digging holes we have so much power there because what's now in the console effectively its automated behind us but for our purposes is it really is just you know sense of automation we do a bunch of checking and stuff on that right but there's no water mated remediation right oh yeah you've got a pothole there it's like okay I've still got a drive around it I still got to fix it right so we're doing basic good things these are amazing things but they're just the start they are monitored by humans they're executed by humans and the decisions are made by humans so they're inherently slow once we get beyond that we've just got tools like CloudFormation terraform ansible puppet choose whichever one you like but basically what we're able to do with those who start defining infrastructure is code laying out a path forward but what are those tools doing they're saying please human tell me exactly what you want please human tell me when to execute oops I don't roll back in the face of errors please human correct me right so these are done on decisions by humans they're executed by a human at a time and then they go through that way for this I apologize for this for those ones they're executing by the system we're telling what to do in us doing it I got that wrong so they're moving through that way service catalogs are similar they're great blueprints they accelerate some stuff but they're still very manual tell me what to do when we've gone even further though we've got these amazing things events flowing through running lamda triggers and capabilities like that so at this point we're starting at the point where it's being monitored by the system and it's being executed by the system I still could define this though as human decision because typically they're very fine-grained quite hardwired yeah and they have a lot of fixed nature to them as they get deployed because they're hard to do a lot of flexibility so we've got to some partial autonomy making good progress once we jump below the next line that we're getting to a place where the automated system is making more improving more and more of the changes so we no longer have to have someone deciding what to do all the time auto-scaling.

I think is a beautiful example of this so is it getting busy what's my threshold that's my threshold I'm going to keep adding more capability more capacity right scale up to meet it then I'll scale back down the system is monitoring the system is executing and the system's making their decision according to rules but the system is making decisions for what to do right and now we're getting more and more predictive in that type of scaling so the rules are less and less yet more and more fuzzy and the system's taking more and more responsibility but it's still only applies to some modes easy to servers containers maybe some dynamo right we're gradually building up that capability but it's quite living and quite restricted now what we've often focused on at Tobin and others are starting to do is basically God railing how do we build more and more and more of these rules how do we think about that whole set of rules and regulations and automate the entire suite if for example we're at 1600 policies now right that is a lot of stuff taking all of those different standards and starting to document those and define those is a huge complex task with a lot of interaction right but those guardrails are really now starting to define okay in this situation I'm looking for this event I'm looking for this configuration I'm going to take this action automatically remediate it because that is my policy posture I don't mind how big your server is or what it is but it's going to be patched I don't even necessarily mind if you're running red hat or a bun too but it's going to be patched it's going to be hardened and when you log into it you'll get definitely going to be active in my directory those guardrails give us more and more modes of operation with more and more complex cases that don't have to be as your predefined or as you know specific they go much more flexible to be honest though we're still really in a place where we're thinking mostly about the infrastructure but the applications really need to start thinking about how they're going to be more autonomous in their operation of themselves right and we're doing that a bit with orders killing and stuff like that but yeah what is the state of my data what is the state of this how do I run tests on myself in real time in production how do I got around myself making sure that I'm in good shape and continuing to improve and we think that's more and more what full autonomy would look like how to teach them to do that of course it's incredibly complex thing so five levels autonomy above the level of none right these are the steps of the journey we're on and I think we're making great progress but we're also still very very early we're still very very directive in what we want things to happen because of that we're soften slow to respond at those levels and it makes it expensive to manage we're not killing the ticket we're responding the tickets and dealing with those tickets and resolving those tickets we never want to see those tickets again we want automation to take care of that for us checking is a good thing but it's not sufficient right we've got to get out of human review of those and getting to ok this problem happened this is what I'm going to do well we often see happen in these environments is level 1 level 2 well we're going to outsource our level 1 to outsource our level 1 we have to have a playbook right if it's a well-defined playbook we go through it half the time they playbook ends up saying please call the app team.

So we need to work out a way to take more and more of those decisions without having to ask right and the only other space Lister that you can clean up the temp drive can I reboot the server without asking right we can do more and more of that through automation humans slow it down agility is the key so we've got it - more and more of that one of our challenge is the infrastructure as code is it's very very fast to get started but it's hard to maintain ongoing you have to be very very structured you have to tell it what to do all the time right you have to tell exactly what to do when to do it you can't change it out-of-band it may be it electric drift but it's very very difficult to do it in a way where it's constantly ensuring it so that brings us to the concept of governance and how do we think about bringing all of that together the first thing we believe in a world of governance is we have to give freedom freedom to our application teams freedom to our developers the second thing is we've got to wrap them with appropriate rules and regulations to keep everybody safe give them infrastructure to make them faster easier things that will accelerate what we're trying to do and finally protect them the first thing is you absolutely have to give self service to these teams you cannot if they have to have console access they have to have API access you can limit their permissions yeah but you can need to give me really run infrastructures code they have to have the native ability to run those tools if you startups tracking them you start slowing them down it's okay to accelerate them with your better patterns all right but it's not okay to abstract them away if you they have to use a blueprint they slow down it's less flexibility that could be a good accelerator it's a good should it's not a great must you don't want to say to them you have to use infrastructure as code that's it's a good thing to use infrastructure as code they should want to use it but if they never have console access and they have to do it through that method that's just another abstraction and it's incredibly complex to work out how to do it if you have no chance to experiment or learn by actually making mistakes and doing it so it's really really critical to think about how you're going to enable them to use those different tools that is what the cloud provides them otherwise they could do the cloud training they come back to your more automated environment and they're like I can't do anything right and and you don't have a cloud anymore you do not want to centralize major pieces of functionality the clouds delivering all these services to you in a repeatable way our code databases as many thousands as you want in different things containers rolled out repeatable automated patterns are a powerful thing that you can do now but if you try to bring all that together into one service you're slowing it down you become the bottleneck ride the rocket of the cloud leverage it as it keeps growing to do that you have to adopt a multi account architecture create isolation around each of these different teams do not bring them all together we're seeing more and more services and patterns supporting this model now most of our customers run tens or hundreds of accounts breaking things up their organization is out there running thousands it's a very very clear blast radius there are challenges with networking and stuff like that but it is so many advantages that it is really a model worth adopting.

if you start normally you start with one you're working in if you're a few people working in an account then you start moving that some others in because the killer looks pretty cool you get a bit of a shared house of course then you start bitching over who did what to the fridge or where the costs are coming from so then often we'll wrench back the other way and do a hosted thing where we're going to control everything and we'll do it together but of course that slows everybody down everybody feels a bit awkward you got the bad I'm calling the corner slowing making it hard so you really got to think about how can we get to multi-tenancy embrace the multi-tenancy of the cloud to your advantage creating all of those different spaces for your developers to work while providing a central core set of infrastructure and services that they can share from a rules and regulations point of view as I mentioned before there are so many standards they generally aligned but they're all slightly different they're generally your directive but they're not exactly telling you how to do it even just naming your service can be a hard problem as you move to the cloud and they suddenly become firm yeah ephemeral so getting all of those rules and regulations worked out and defined is a massively challenging problem you know one that we actually spend a huge amount of our time working through how do you group them into appropriate standards that keep repeating approved is this thing allowed to exist in this region is this instance type allowed to be used right active is this thing still being used or is it an IP address that's no longer in service should it be cleaned up and taken away backup or data protection how long does security need you to keep it how do those compliance need you to keep it how long there's an application team want you to keep it and how do we line all that up in a set of rules across all the different services configuration does this thing meet exactly the specification we want for it right encryption at rest and in transit right logging in order we have so many different things here.

We're working through just the name of every server the name of every subnet the way that those things should be tagged the way they should be laid out what should be your IP space every single one of these decisions to reach a world of automation has to be well defined well documented and implemented through automation every single one of those processes piece of papers we just have in the background is coming forward to the world of automation right so we have a lot to work through here and it's a you know a number of tasks to go through at about one of the ways we tackle that problem is by thinking about a policy engine and having a set of rules that play down through the environment so this is an example of an s3 bucket encryption at rest policy which is set high up to just say hey for everything under this point we should enforce the use of Amazon SSE for the encryption of course we then have exceptions there's the account where we really need to use kms so I should rule can be made to override a higher level should rule it was a recommendation hey you know you really should use sse but you don't have to write this account said okay i really want to use KMS they could have said i want to use nothing right but a lower level rule can override you know should rule can override a should rule so then we have the idea that you really really have to have requirements so actually i didn't mean you should use it what I really meant was you have to use it and if you don't want to you need to get permission from a core team we expect every bucket in our environment to be encrypted unless a security team has improved it that's a must rule or required rule required rules of course beat recommendations but you still need exceptions so you can have a requirement that overrides are an exception overriding their higher level must rule and of course that can go further down where for one bucket you can override that again so we think that as you get through all those rules and those definitions it's really really important to understand that you have to be able to support of robust system of exceptions we happen to do through a policy engine others choose to use your version control code or different stuff like that.

But you have to support exceptions or your infrastructure worlds no not the other scale to the what the cloud requires from an infrastructure point of view laying out that basic nature of the cloud you can use things like landing zones they give you a good basis for you how your configuration should work how your login buckets should work how you want to set up your accounts they're an accelerator just like we mentioned before infrastructure as code or terraform they're laying out that basic infrastructure for you at to what we believe there's way more than that in terms of how you have to define patterns that will scale to help you work one of the things we do and try to define a common language around is the permissions model how do we work out how to handle those 3,000 Amazon permissions that are growing everywhere how do we do that in a way where we're setting certain accounts with a certain amount of permission to use different services and the way we do that is by breaking it up into a hierarchy so that you can grant this user a certain level of access we've defined a standard language there encourage you to take a similar approach super user owner admin standard language that works everywhere so you can have repeatable conversations every conversation ends up referring to a JSON document life is going to be pretty slow particularly after they get wild cut it down the next thing is that we like to do that by service so all of Amazon combining different things or Amazon s3 so we end up with definitions like AWS s3 admin ed of assisi to operator standard language that we understand what it means and it works across the environment what we then do is apply that through the hierarchy so you can have cloud teams that have that permission across all the different services all the different accounts or you can delegate authority to your sub teams it's really really important that you can delegate access so that they can have that self service that we spoke about earlier now whatever model you choose might be slightly different to this one but the really really critical point is that a key part of providing infrastructures of those teams is having clear language clear definitions that work at scale in your organization right work across different environments you know different services all sorts of things so

we use the same model for Linux permissions Linux admin Linux user same language right different also different services the next thing we really tackled as an infrastructure definition point of view is networking so traditionally we think about public now go to a private network it said what we analyzed that even more aware actually there are eight subnet types that really matter and map the through the newest here's the properties that is how we define them it comes down to what's their route to the Internet what's their route to the internet what's their route to AWS which is kind of internet but we can generally treat it a little special and then how does the route tables get set up with the IP space and stuff like that so I'm just going to break those down a little bit and give into the sort of detail that matters as you talk through it so an isolated subnet really has no connectivity or anything kind of nonsensical but NU'EST 853 likes to define what these are so yeah you do them for completeness of course then you can have a restricted subnet which basically means no internet access many organizations work that way and you want to have a good definition where all the traffic is coming back to your intranet again standard language talking through the different parts private subnet means you can come back for other we're happening but get still get to the internet a limited subnet will have access through private endpoints out to AWS limited with peering okay now our things can talk without hair pinning public we flip back the other way so now it's the outward facing no access to internal and that sets us up to do a DMZ which is public and internal facing now we have a private one which is routing the traffic internally but accepting traffic from the outside is a DMZ that's actually one of the more common patterns once you're going at external it's more complex direct access now so now we talk straight out near the internet rather than coming back hair pinning all the time and direct via the public IP you can even have for HPC workloads are completely independent subnets set now all that combines to give you a V PC peering with independent and direct subnets there's all sorts of building blocks there that we just went through creating that now that common language though is really setting us up for the types of conversations where someone comes in it's like okay I need to use AWS for my service it's like ok what what network do you need I need a DMZ and we know what that means it's not I have a network definition you know terraform stuff was something that then has to get run once hopefully nobody changes it out-of-band right at tipo what we do is we guardrail every single one of these things that they have drift detection if even one route gets changed since a it's ten seconds later it has changed back because once you have these types of definitions you need to make sure that they're constantly and always true they're not just true at the point of deployment but they're true ongoing that's what an autonomous cloud looks like is when it's constantly holding that position it's the same as like hardening a server the golden image right it's great until one person logs in with route and then you really don't know much anymore it's the same for your infrastructure you need to constantly enforce it over and over and over again make sure that that drift is always corrected

so the way you create that protection in the environment is through real-time guardrails and a high level basically that looks like you're getting events from things like SNS moving those two SKS queue applying your context and your policy rules to it so you can make decisions about what to do and then automatically enforcing those in the environment and of course these audit trails so we know what change happened and how things went.

So what I thought I'd do is show you a little bit about how that works for us and what that can actually mean in that environment so Tobal what we do is actually break up the account so each user can log in and see their specific account I might see two you might see another couple production accounts might be separate but each user can see their particular environment and that's how we restart the restrict access but you want your users to go straight into the Amazon console to take their actions single click all tied back to an identity system from your directory structure when they do that they can use the console to take actions for example we can do the classic near s3 and just create something like a bucket so we've all done that before we've created there's three buckets what's cool though is that now it's watching and it's going to detect that event and now guardrails are going to start to apply to keep it safe and make sure that it's you're in compliance with our policy rules for the environment so if we go look at that bucket over time it's going to start picking up the different policies and properties it's already picked up the access logging I didn't set that that happened automatically in the background it's already picked up tagging if i refresh again hopefully it's got some more versions being turned on there fall encryptions there so if I go into the logging I see it's logging to our best practice bucket that set up in the background of the environment our users didn't have to be experts in that if they're junior developers they may make this cycle not know if they're a senior developer they're not wasting their time doing it because it's automated to policy in addition we can stop ourselves from being able to change that okay I'm not allowed to disable logging that's a sensible restriction because we're enforcing it right so we prevent wherever you can but sometimes you can't prevent so you have to detect and correct now that's great for security right and you know that's an obvious use case troller stupid automation goes so far beyond that right setting tagging for example to bring down cost centers and all sorts of different information we want in that environment about who created when it happened stuff like that just best practices that we normally would say to people where you have to tag it right and check for you can automate all of this so then I have to worry about it you know your environment is in control we come back to turbot and head into the account we can start to see that it picked it up and it recorded all the different things happening in the seem to be including the differences we can go to the controls tab floor actually we're good for that booked in and we can see in the controls all the different things it's just check for that bucket was the cross account on what happened was the bucket approved to exists right this is the standard language we're talking about a moment ago and we can see things like the tagging and here what we're actually doing is recording that change over time we think this is critical visibility into what changed otherwise people start to think that it just changed underneath with no knowledge you can work out different ways to give that visibility this is how we choose to do it you can see that we raised the alarm saying that tagging wasn't correct and then we went and automatically fixed it and then we've immediately closed the alarm that all happened within the same unit this is a ticket we never had to deal with call automation dealt with it for us right for each one of those you really want to record what happened you need to know the event that triggered.

It you need to record how you made the decision right and what decision you made so the security compliance are happy with that but also developers can understand what is going on it's things change around them if you don't tell people what's happening as you change it through automation they lose trust to implement those controls so it has to be done in accordance with that policy engine so for us that's where the policies tie in so you can set policies for example like the tagging one right which has a template for different tag pulling in stuff from the account ID or stuff like that but many of the policies you actually want just a lot simpler and more human because Jason is difficult to do was for example in force enabled tutor bot logs so what we saw there was the real-time creation of something that was automatically configured to meet the requirements we need as an organization we didn't have to think about it we'd have to worry about it that's s3 that's simple doing this across every networking every route every uc2 server every instance what's the name of every single thing that's where the rules and regulations piece comes in and the scale becomes very very large if you're starting to write a few templates if you're starting to write a few infrastructures code pieces if you're starting and why are a few lambda functions pause for a minute and think about the scale that you're about to tackle and the real time size you're about to have to handle with that think about where you're going with that DevOps over time so you can start to think about the tooling you'll need to really make it work at scale I mentioned before the permissions piece so what we do there is really bring in those permissions down through the hierarchy so you can start to add grants by simply searching that ad system and then assigning permissions like whether it's a dog us you know a CMC other namings consistent consistent naming is critical here right so if people can really understand what's going on we like to focus on things too like automatic expiration of rights why do I need continuous rights in places like production so if we think about that automated world we talked about the challenge of getting from no automation or now today we're doing some scripts and we have some checking we're starting to do some basic functions right if we can get to that world of full automation what we're starting to a lock is a whole massive amount of speed right safety that we have you know beyond what we ever saw before more accessibility your productivity of your junior developers will go up massively your senior developers are better able to do things accessibility means more people can write this stuff because they're not going to make mistakes or their mistakes are cut and guarded and then we have a breadth of coverage beyond anything that we're close to because once we're getting those tools and reusing them more and more every account benefits from it and the depth of thought we can put into each one is very very powerful and a level beyond what we could expect any single application team to go to so to summarize you're in a world that is both complex and real-time that's way more than you've ever had before got to work out how to deal with it the second thing is that there are really five levels or autonomy to think about we're basically hovering between zero to two right now right in most organizations think about how you're going to break out of that and get to the next level and finally we believe the way to path towards that is governance thinking through how to give freedom to those application teams how to define all those hundreds and hundreds of rules and regulations in a consistent manner to automate them you have to understand them more deeply than you ever did when they're on a document or someone's head set up that protection for those teams and the infrastructure to really empower and drive them forward and enable them and finally that's that's to drive education as they learn more and more from how it worked what went wrong what to do next that creates that positive feedback loop where you can go drill them enough to let them experiment new things as exceptions so you can learn together and then keep going around okay so that's everything I wanted to cover I'm happy to take questions if anyone would like to ask one and thank you very much for your time [Applause]

If you need any assistance, let us know in our Slack community #guardrails channel. If you are new to Turbot, connect with us to learn more!