Practical Management of the new Shape of Applications With Chef Automate
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 45 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/34600 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Transformation (genetics)Network topologyChannel capacityFood energyData recoveryMetric systemChainCycle (graph theory)Boom (sailing)WhiteboardReal numberNeighbourhood (graph theory)State of matterBasis <Mathematik>Data managementProjective planeInheritance (object-oriented programming)AreaRight angleMetric systemFocus (optics)Video gameHand fanPhase transitionTerm (mathematics)Scaling (geometry)Information technology consultingLength of stayTransformation (genetics)Radical (chemistry)Forcing (mathematics)Multiplication signNumerical analysisGreatest elementTask (computing)Slide ruleCentralizer and normalizerSet theoryProduct (business)QuicksortMathematicsRow (database)Electronic mailing listDifferent (Kate Ryan album)Integrated development environmentParallel portTransportation theory (mathematics)Type theoryCASE <Informatik>Execution unitMereologyComplex (psychology)TelecommunicationSelf-organizationSoftware developerNP-hardGroup actionMassEnterprise architectureData structureField (computer science)Insertion lossOperator (mathematics)Universe (mathematics)Arithmetic meanCAN busBoolean algebraJSONXMLUML
07:12
Object (grammar)Hand fanDecision theoryMetric systemTransformation (genetics)Right angleMereologyDifferent (Kate Ryan album)AuthorizationHypermediaSelf-organizationSystem callVideoconferencing
08:36
Metric systemSoftware developerFrequencyArithmetic meanMathematicsBit rateSquare numberQuicksortTerm (mathematics)System callGroup actionSet theoryMereologyNumerical analysisState of matterMeasurementCategory of beingArithmetic progressionPatch (Unix)Software developerAuthorizationProduct (business)Process (computing)WordMultiplication signShared memoryAverageRow (database)Self-organizationMetric systemObject (grammar)Software crackingTraffic reportingKey (cryptography)SummierbarkeitNoise (electronics)Right angleConstraint (mathematics)Projective planeEntropie <Informationstheorie>Cohesion (computer science)Peer-to-peerSpacetimeWeb 2.0MathematicsPrice indexPoint (geometry)Interpreter (computing)Line (geometry)Form (programming)Position operatorRoutingFlagDecision theoryComputer configurationComputer animation
15:55
FrequencyMathematicsInformationMeasurementConstraint (mathematics)TheoryMathematical optimizationLocal ringBit rateSoftware testingPredictionHypothesisSelf-organizationPosition operatorMeasurementCurveRight angleNumerical analysisSoftware testingArithmetic progressionStatement (computer science)Different (Kate Ryan album)Error messageMereology10 (number)Metric systemBitTerm (mathematics)Direction (geometry)StatisticsCASE <Informatik>Decision theorySet theoryOperator (mathematics)Pattern languageConstraint (mathematics)Limit (category theory)Multiplication signRegular graphSoftware developerCuboidPrice indexFactory (trading post)HypothesisSeries (mathematics)TheoryQuicksortFeedbackData structureProduct (business)Figurate numberOrientation (vector space)MathematicsOrder (biology)Natural numberSound effectData recoveryFluxAxiom of choiceData managementPhysical systemTransformation (genetics)Bit rateWeb 2.0DeterminantSoftwareGoodness of fitShared memoryStack (abstract data type)
23:15
HypothesisCapability Maturity ModelChi-squared distributionInformationFocus (optics)Information securityRight angleSelf-organizationHypothesisComputing platformCohesion (computer science)InformationDifferent (Kate Ryan album)Insertion lossSoftware developerCycle (graph theory)Context awarenessVariety (linguistics)Software frameworkSoftware testingLengthDirection (geometry)Projective planeKey (cryptography)Axiom of choiceMathematicsSurfaceService (economics)Error messageInformation securityWeb pageOrder (biology)Level (video gaming)TrailPosition operatorFundamental theorem of algebraPhysical systemWordDivisorAreaAnalytic continuationStability theorySet theoryMetric systemCodeData managementRevision controlBasis <Mathematik>Bit rateState of matterTest-driven developmentFocus (optics)Numerical analysisView (database)Open sourceObject (grammar)Shift operatorDefault (computer science)ChecklistResultantWeightShape (magazine)AutomationWeb 2.0Client (computing)
30:35
AutomationSpacetimeSet theoryScaling (geometry)SpacetimeType theoryAxiom of choiceException handlingRevision controlMachine visionDefault (computer science)Service (economics)Cohesion (computer science)Right angleBuildingPressureMultiplication signTest-driven developmentSelf-organizationData managementMetric systemBitFlow separationAutomationCodeTransformation (genetics)Different (Kate Ryan album)SubsetOcean currentCycle (graph theory)Software testingBasis <Mathematik>Vulnerability (computing)Distribution (mathematics)Product (business)Fundamental theorem of algebraGroup actionPerspective (visual)Bit rateProgram flowchartComputer animation
33:37
JSONXML
Transcript: English(auto-generated)
00:05
This is the road more traveled a look at putting DevOps transformation back on the rails My name is George Miranda. I'm a Director of product marketing at chef. I've been at chef for about five years now And when I first started at chef, I was doing a lot of consulting and fieldwork
00:24
Which means that I've gotten to work with some of our largest and most successful customers in various phases of their DevOps transformation So it's been very interesting for me to see where they were when I first met them versus where they are today If you've hung out with me in the field and you've met me you probably know that
00:42
I'm a big fan of being an agent for change And if we haven't met each other What I'll say is that change is a constant theme in my life that extends well beyond just the scope of technology For example just in my time at chef I've lived in three different cities alone Let alone all my time on the road and I like to bounce around from place to place
01:00
To look at a lot of different settings. I Grew up in Los Angeles anybody here from SoCal One person. All right, cool. You're you're my people. You'll probably know where this story is going next But for everybody else, I'll say this Los Angeles is a very very dynamic city And the downtown area of Los Angeles has just undergone its own radical transformation initiative
01:26
When I was living in Los Angeles downtown, Los Angeles was known for this It was known as skid row Right, and it's not the sort of place you wanted to be after dark. I mean sure there was bustling daytime commerce Become 5 p.m. You cleared out of there because there's nothing but bad news
01:42
and there were some very tumultuous things going on in the city at the time and City leaders realized that the only way for Los Angeles to evolve and move forward was to radically change how their city was structured So the question the question became how do you drive change on this sort of scale? And la is a really massive enterprise, right
02:03
The scale of Los Angeles is about 13 million residents with an estimated 750 billion dollars of revenue, right? That's three-quarters of a trillion dollars That's a massive enterprise, but if you look at the state of downtown, Los Angeles today It's almost unrecognizable. It's completely transformed
02:22
Downtown LA is now known for being gallery row, right? It's a booming economy It attracts a set of diverse professionals from all over the globe to live there The beacon of creativity in the city is Center for Arts and Nightlife And there's a real estate boom going on in downtown Los Angeles. That is unlike anything that they've seen since the 1920s
02:41
So more growth than they've almost seen in over a century, right? Like how did they pull off that transformative magic and how do I get me some of that? It's mind-boggling in terms of complexity and scope because when you drive transformation you have to How you fundamentally transform every moving part of it and when it comes to a city like Los Angeles
03:03
Right, that means that you are coordinating the needs of a diverse set of groups with diverse goals, right? Whether they're real estate developers or investors right transportation merchants Big business employers right public safety environmental impact like the list just goes on and on and on
03:22
So how do you get? Transformation at the scale of Los Angeles, right? How are you able to push that throughout the entire organization? What do you do? Do you set up a very small focus task force that has? Maybe two visionaries on it and like a super sharp project manager with an amazing can-ban board Filter all chains through to them and then suddenly will drive this transformation throughout the city
03:44
Like no right like I see some smiles. That sounds ridiculous, right? It sounds even ludicrous to say out loud But if I talk about transforming a fortune 500 IT organization like I'm starting to see some nodding heads right like that Sounds about right because that's what we see many times
04:00
So why is the former? Absolutely ridiculous, but not the latter What lessons can we learn about DevOps transformation? Happening on that scale right? What can we learn about replicating these types of successes inside our own organizations? Here's What I found when I was getting ready for this talk
04:22
In my search I discovered that there are now cities around the world that are trying to replicate the same success as downtown Los Angeles and whether that's Domestic cities like Atlanta Savannah Nashville or international cities Bogota Delhi Copenhagen has done some really interesting things Cities are now trying to figure out how they drive wide-scale transformation
04:44
It was really eye-opening to me to see what some of the parallels were So cities that have successfully done this realize that they cannot be a central bottleneck for change Instead they need to decentralize expertise and make it clear what their priorities are So cities that successfully transform do it by setting up
05:03
Self-reinforcing cycles that start with identifying the right metrics The way to drive transformation through a three-quarters of a trillion dollar economy is to start by focusing on things like this So this slide is pretty interesting because the metrics at the top feed the outcomes at the bottom
05:20
and it's kind of surprising when you first look at some of these metrics like What the hell do one-way streets versus two-way streets have to do with vitality vibrancy and resiliency? Right and when you start to unpack it you see well one-way streets are really great for funneling traffic through a downtown area But they're really terrible for generating foot traffic, and if you don't have strong foot traffic
05:40
You're not gonna have strong retail in that neighborhood, and you need strong retail To drive neighborhood revenues if you have strong neighborhood revenues you can attract higher rent if you have higher rent prices you have developers that want to build more housing units To bring in more residents and feed the entire cycle and keep it going Right also that foot traffic creates a sense of neighborhood and community
06:02
And that's really necessary when you fall on hard economic times as neighborhoods inevitably do and you need to have some resiliency to make it through Right and then you support that Those behaviors with infrastructure in this case the way that people get around right by changing the way that people get around You create daily behaviors that force that reinforce the cycle and make those daily behaviors into habits
06:27
So that one seemingly arbitrary metric has a world of innovation attached to it when you start to Unpack what it means to actually deliver on that number So the way to succeed in DevOps transformation is to set up self reinforcing cycles in your own
06:45
organizations and you do that two ways one you start by identifying the right metrics that matter and Two you put in tools that reinforce the behaviors that you want to see on a daily basis Setting up those self reinforcing cycles the only way to scale communication and drive culture change
07:02
across a diverse set of teams with a diverse set of goals So that's what we're gonna talk about today, right we're gonna talk about metrics tools and the science of change oh And I almost forgot we're gonna do it with one more thing right so the title of this talk the road more traveled That's a Robert Frost reference right to the road less traveled
07:21
Do we have any any poetry fans or English majors literary geeks in the room like a couple folks all right anybody know? What's wrong with what I just said I think I heard it So the title the title of the talk is or sorry the title of poem is incorrect, right? It's not the road less traveled or the road more traveled is actually the road not taken
07:41
And I think the only thing that's mistaken more often than the name of that poem is the sentiment behind it right everybody know the poem That I mean two roads diverged in the woods, and I took the one less traveled by right so that poem when you read it The two roads are essentially the same like there's no discernible difference And it actually doesn't matter which one the author chooses
08:01
And so the car the poem is actually commentary about the stories that we tell ourselves to justify the decisions that we've made and So I see that happen a lot in transformation initiatives Which is you hear stories about some decisions that worked in one organization, but don't work in others And there's a lot of anecdotes that maybe potentially steers the wrong way so instead
08:21
We're going to take the road more traveled right which means we're going to look at empirical data We're gonna look at objective observations, and we're going to identify. What actually works in proven paths to success Sound like a deal Cool all right, so identifying the right metrics. I got this next part from dr. Nicole Forsgren if you're watching this talk hey, Nicole, what's up?
08:45
So Nicole used to work at chef she now works at Dora DevOps research and assessment And she's kind of my hero when it comes to the science of metrics, and how that shapes behaviors If you really want to get into it and dive deep I think she does a way better job than I ever could about how you science the crap out of DevOps
09:03
So she has some really wonderful talks on that I suggest looking them up if you want to go deep, but this next part is a really good summary And it comes from Eli Goldratt author of the goal And he writes this tell me how you measure me, and I will tell you how I will behave The breakdown is basically this right you should always measure the things that matter
09:24
Because that's how you communicate priorities Right if you don't measure it It probably doesn't matter right if you don't measure it don't expect anyone to do anything about it And in business this usually plays out because our incentives are tied to certain measurable goals I mean the most obvious example of this is in sales right you close a deal this certain way
09:45
And you get paid and so In business especially we tend to orient around behaving in ways that achieve our incentives So measures are important because they drive our behaviors But right individual measures have a way of maybe leading to unintended consequences if you just look at them in isolation
10:07
And so the example of that is this right if you define a metric that says we're gonna ship X new features to users every week Then you can expect that the behavior that you're going to get from that is That your developers are going to sprint to get X number of features into the release every Friday
10:22
Right and is that necessarily the right thing to do maybe right maybe X is the right number Maybe it isn't but it has an unintended consequence in that this might be letting or setting you up for a support nightmare Right maybe those features aren't fully ready to go, but the thing that matters is getting X number out there, right?
10:41
So maybe you deliver things that aren't fully baked or maybe you sprint to get those in at 5 p.m. Before everybody goes home, and then your options support teams are cleaning that up over the weekend, right? But hey like I got those features out like high-five bro. Good job, right metric achieved And so what happens is we inadvertently set up situations
11:02
Where people strive to deliver on those one metrics that we are that we've defined right or those few metrics. We've defined consequences be damned and Consequences aren't damned out of malice right consequences are damned because we're not measuring them right We didn't communicate that they're actually important and teams will optimize for their given constraints
11:22
Right so unintended consequences slipped through the cracks because we didn't decide to measure them or track them And because of that some organizations take the exact opposite approach, right? They'll go ahead and measure everything right and so if you if you do that And you go that route you have a way of creating a lot of noise from which it's very difficult to extract a signal
11:44
so the key is really to identify a small set of metrics That when taken together start creating a self reinforcing web of behaviors that shield you from unintended consequences And what I found that was astonishing when I started looking at how cities transform
12:02
Is that a number of cities that are now going down the transformational path? Managed to drive large-scale change with only about a dozen or so leading indicators and the metrics that drive behavior So the the state of DevOps report has been around for for about five years now, right?
12:21
2013 inclusive set 2017 is around the corner. So five years And from that data, we've learned a lot about how IT industry performance plays out And we've learned that there are certain measures around speed efficiency and risk that are correlated with how high-performing teams Leave the or lead the industry and kind of leave the rest of their peers behind
12:44
At chef what we've done is we've adopted this data along with data that we've collected from our own users To derive a set of metrics that could starts to create that cohesive web of practices And it looks like this, right? so we organize the data in a pretty easy to follow prescriptive path and
13:03
The categories are measures of speed efficiency and risk and you see metrics that define what high medium and low-performing Organizations look like now you might recognize some of this from the 2016 state of DevOps report and then you might recognize the rest as Some of the data Around findings that were in that report that chef has used in tandem with data that we know about our own users to derive some
13:26
quantifiable measures for those findings So there are a couple of things to note here and how the way that all comes together So those lines between high medium and low-performing organizations. Those aren't arbitrary It's not like somebody sat down and said hey This is what it means to be a high performer and this is what it means to be a medium performer
13:41
This isn't a prescription of the data It's an interpretation of what was there when you look at performance data points across the IT industry They just sort of naturally organize into these clumps with very large performance gaps between them, right? So that's what you're seeing a reflection of in the chart to the compliance automation data that we've gotten from the chef community
14:02
Follows those same distinctions and that should make that kind of stands to reason because three This is a cohesive web of practices when you start to deliver on one of these metrics it has a way of unpacking the others and bringing those practices with it and So going back to the city example, right? It's not that the number of open-air markets per square mile is what transforms your city
14:25
It's that measuring the number of open-air markets per square mile Signals that that's important, right? It lets diverse groups like investors developers You know permit issuers and merchants know that they should be working together to create livable spaces
14:43
So let's see how that plays out in technology terms, right? We're gonna take that one metric time from commit to deploy right So if you are an organization that does quarterly releases For example, this metric measures the average for every commit that you've had and how long it took to run in production
15:03
So if you release quarterly That means some commits were made months before it was deployed and maybe some months or some sorry some commits were made Minutes before deployment, right? But the only way that that's going to add up to an average that's measured in minutes is If you change how you develop features, right?
15:21
You have to start developing features in small batches, which means that you need to rethink your development process, right? Maybe you need to launch features dark behind a feature flag Until you have enough of them queued up in production that you can turn the whole thing on and if you change that development method Then you need to change how Development progress is measured and if you change how development progress is measured
15:44
Well, then you should probably change how your projects are managed And if you change how your projects are managed and you should rethink how objectives are set And if you're rethinking how objectives are set Then you're probably in a position to reanalyze how business decisions are made and fed through right?
16:00
And so now what you have is a situation where that one change in engineering rippled all the way through up to the executive stack and Affects everyone in between and aligns them in the same direction Right, that's what these metrics are for and that's why they're leading indicators of change And then once you're there right in order to keep that metric of being able to deliver
16:21
Changes to production in minutes. You probably need some sort of deployment pipeline So you start delivering on those metrics of speed and if you're deploying automatically You probably need a series of tests You start going down the path of test driven development if you weren't there already Which leads to delivering on measures of efficiency and risk and this is how this becomes
16:41
This self reinforcing web of behaviors that all have a way of reinforcing one another and the thing about these metrics Right is that they don't prescribe exactly which tool to use or which management method to follow right It decentralizes knowledge because it just conveys what the priorities are and
17:04
the priorities in this case are shipping software faster safer more reliably And it decentralizes the knowledge right because it communicates everyone what the goals are What the metrics are that they need to optimize for and what it does is to your teams that grants Autonomy it grants ownership. It grants them trust and it gives them direction to know what things you want them to deliver
17:28
Right, and so rather than defining tens of dozens or hundreds of metrics that prescribe everything along the way instead We focus only on those leading indicators that tell us we're moving in the right direction
17:42
So tell me how you measure me and I will tell you how I behave I like to take that a step further and say tell me what all the measures are and I will tell you how the Organization behaves I like to think that I'm clever and I came up with that But it turns out it's really just the theory of constraints So start with a holistic set of measurements and align interests across diverse teams
18:03
So that's great George, but like where do I take that? What do I do with that in my own organization? So I just take those metrics and focus only on those Maybe I mean they're a pretty good place to start but maybe you care about managing other things in your organization, right? Like maybe Managing WIP limits right work in progress is important to you because you know, that's how you maintain sanity on your development teams
18:25
Well, then what do you do? How do you work that in? Like what's the what are the indicators? You should be looking for in that regard so trial and error is Really useful when we don't know where we're going and I think there's very common advice in DevOps, which is experiment and fail quickly
18:43
And that's really good advice And in fact, that's great advice when developing software features and giving them to users and that's great advice in that respect Because you can do things like a B testing you can see which features are being used and which aren't But when we're talking about changing human behavior
19:00
That's a little bit of a slower process, right? The thing about failing quickly is that you have to be able to get feedback quickly That's the only way you know if it's exceeded or failed and when it comes to altering behaviors, right? First the behavior has to be understood and then it has to be implemented And then you have to wait a while to see whether or not that actually Had any effect and then maybe you realize that the behavior was actually not implemented correctly and you have to go back and iterate
19:24
Change the way that your teams work and that is fundamentally a slow process Those feedback loops are pretty long by nature And so you need to be really careful when you start going down that path, right? You need a little bit more than just hey Let's try it and see what works and this next part like this part isn't by the numbers
19:46
Because the numbers for why transformation fail are fuzzy at best And I think that's for a couple of reasons right either organizations don't fully understand Why things failed or they're still experimenting or two? I think sometimes organizations are a little reticent to share exactly why they failed and how they failed although DevOps right sharing is caring
20:05
There's no learning without sharing But what I will say right is that at chef we see this happen a lot right where people start experimenting down the path of What's going to work? This was referred to as DevOps awakening in the keynotes, right? So I reused that term here
20:21
But that part where teams start experimenting with trial and error to figure out how they take practices They've heard about and how those fit into their own organizations We like to call that the operating chasm, right? This is when folks that sometimes take the road less travel and decide hey, I'm gonna have that Can do determinism and just try to see if this thing works, right? I'm gonna try something different and
20:43
When you try something different, like maybe you build the flux capacitor Maybe you built the brainwave analyzer instead who knows right and we hear stories that go both ways But what's really common here is that when you get into that operational chasm what happens is you start? Thrashing on toolchain choices you start thrashing on workflow decisions, right?
21:02
Maybe started thrashing on organizational team structures, and it's very common to have a lot of failures because that's part of the trial and error process so this learning curve has some cliffs right and it's definitely easy to fall off into the chasm and Even though we don't understand why those failures occur You can definitely see that they occur in the data right the data reflects this and if you're looking at the chart earlier
21:23
There are these weird little stats for medium performers And so medium performers are basically DevOps awaken teams that started down the path of trial and error and if you look at their performance for Failure rates, right? They're higher than their low performing counterparts and when things fail They're not necessarily any faster at recovery than their low performing counterparts either
21:42
Right, like we see that when you start down that path, there's definitely a lot of potential to fall into that dip So what are you telling me George right? Are you telling me not to experiment? No, like I am not telling you that at all It's important to experiment, right? That's the only way that we learned and that's the only way that we go forward
22:02
But what I am saying is that we need to compensate for those very long feedback loops So we can avoid the potential pitfalls right and and in doing so that's where it's important to trust systems that we already know work So experimenting is basically the scientific method right and the scientific method works because we establish a hypothesis
22:26
Before we start the experiment, right and then we go ahead and start the experiment make some measures right and figure out whether or not it worked But if your experiment is going to run long it's important to make as sharp of a hypothesis as you can because you're gonna be living with this experiment for a long time and
22:45
the best hypotheses Start not only with an understanding of the world around you and what some of those patterns are in questions and luckily in DevOps I think we have a lot of empirical data and some very common patterns to follow But the best hypotheses also start with an understanding of your current empirical state, right?
23:04
Like how do you measure where you are today? Because that's the only way you can figure out like if it worked or not, right? What is the Delta? What is the difference you can't know where you're going if you don't know where you are, right? And so how exactly to gather that data and put together a really sharp Hypothesis is a little beyond the scope of this talk
23:20
but if you really want to get into it just like find me later and buy a beer and like Hey, let's chat But I will say this right When you start developing a hypothesis like this for hey, what's going to work in my organization? Don't just adopt a practice that you heard in a talk or something that you read it in a white paper, right? Or don't just adopt this new tool because you've know it works in other settings
23:43
You need to have a stronger filter around what the context is and how that will play out for your organization And it's really important to develop that but if you're just getting started right the question becomes well How do I develop a really good filter? So I'm going to turn to Nathan Harvey for this one who turned me on to the concept of shoe Hari
24:03
Shoe Hari is a portmanteau of three words shoe ha and ree It's a Japanese martial arts concept that starts with shoe, right? Which means whenever you're learning a new system or process start with the fundamentals, right? Follow the traditional wisdom and then once you've followed the traditional wisdom then you get to ha right once those
24:23
Basics are understood you can then break with tradition and forge your own path That leads to the ree right once you've done that then you can go you're in a place where you have mastered the art So if you're just getting started what I'm saying is follow the known path Right establish the basics and then you're in a better position
24:42
To start filtering context and figuring out which of those hypotheses will work for you or not So start by taking the road more traveled tools and behaviors, right? So we talked about how we align objectives across a number of teams by using metrics But how do we reinforce that on a day-to-day basis?
25:06
I love this quote from Adam Jacob, right the tools we use reinforce the behavior the behavior reinforces the tools So if you want to change behavior change your tools I like to take that a step further and say you can't change culture directly, but you can change behavior I certain tools enforce certain behaviors and those certain behaviors are what become your culture
25:26
And we kind of saw that play out in how two-way streets work Right, like you change daily habits of how people get around and eventually that leads you to a walkable culture It's the same thing in IT, right? the role of tools is Important in your choices, but that's not to say that tools should drive your choices, right? The key is to pick a set of tools
25:47
That make you work in ways by default that reinforce those desired behaviors Right and those desired behaviors should work in tandem with the metrics that you've identified So tools reinforce the behaviors The behaviors deliver on those metrics, right and those metrics are what shape your outcomes and that's kind of the way that it all comes together
26:07
So what are those tools? I think there's a detail that's pretty often missed whenever we talk about Chef Automate And that detail is the philosophy behind why Chef Automate is structured the way that it is
26:21
Chef Automate has the three open-source projects InSpec, Habitat, and of course Chef, right our namesake and those are all pretty flexible Automation frameworks that allow you to solve problems in a variety of different ways But Chef Automate, the commercial platform, is really opinionated about how those all come together
26:41
And it's really opinionated about how those all come together because as a platform the Design principle behind Chef Automate is to create a tool set that changes the daily behaviors of how your teams operate in Ways that deliver on proven industry metrics that lead you to success
27:00
So are those metrics right? We saw some of those I think in the keynotes this morning right speed efficiency and risk and when we start talking about how to hunker down and make changes in any of these areas Usually when I talk to teams about this everybody wants to focus on speed right go faster faster faster And we can drive faster right, but if we don't have a set of guardrails We might potentially end up in a ditch and when we start talking it through and figuring out what really matters most folks realize
27:25
They probably want to start by mitigating risk and when you start by mitigating risk Then you start delivering on some of the factors behind service efficiency, and then that usually leads you down the path of speed So let's look at them in that order There's been a lot of talk on the main stage about compliance automation
27:43
Hopefully you've been able to attend one of the InSpec talks I believe that track is still going in there for you left today if you haven't made it yet But on stage Carmen Kruger from SAP Referenced the tension between development and security right are you constantly trading off between speed and risk and the problem here is that
28:02
Your development posture and your information security posture and most organizations are just diametrically opposed Right in a continuous delivery world all changes manages code So your development posture is all about test-driven development, right whereas most information security tools Just simply aren't designed with continuous delivery in mind, right?
28:24
They posture around binders of policy and manual processes right and filling in checklists of results But InSpec allows information security teams to orient around enabling speed with automation and so InSpec allows Information security to meet developers where they already are
28:43
Right, which is code driven continuous delivery that uses packs of easily distributed versioned executable tests that can plug into any test driven development workflow, right and so that one shift allows both your Information and your development teams to align in the same direction. Although there's there's definitely a lot more to that subject
29:05
It's a pretty dense subject and if you want to get into the full-length dissertation I put together a 19 weight. Sorry a 19 page white paper on it that we just published today So check it out or if you just want to talk about it again. Hey, let's talk after this and grab a beer
29:21
Tooling around efficiency right tooling around efficiency means looking at service stability and in order to ensure service stability You need visibility into all of the things that are happening with those underlying layers of automation So that's what some of the changes are that you've seen to Chef Automate on the main stage Right, you need to find the data that you need depending on your function and in an organization
29:43
So this is why Chef Automate provides views around What's happening with your nodes, right? If you're an infrastructure person that cares about the state of your infrastructure or compliance based views So if you care about the state of information security and what's happening across your organization You can easily see those errors bubble up to the surface
30:04
And when you do see that issues bubble up to the surface you need to be able to respond to them quickly Right, and if you started to mitigate issues of risk using automated compliance tests You can start also deploying remediations very quickly when you identify that those issues have arisen
30:21
Right and this start this leads to things like the detect and correct cycle Using in spec and chef client and you can start seeing how this starts leading into that cohesive web of practices I don't know what happened there. There we go My clicker is not working
30:42
There we go speed. So this is the one that folks usually care about right and so I'll talk about this quickly the Chef Automate workflow, I think reinforces the need for basic things like Source control right code reviews test-driven development dependency management Separation of duties etc. SAP did a really great talk on
31:03
Using workflow yesterday, so I think that's a great way to reference it instead here I wanted to talk a little bit about the habitat build service that was in the keynote so the habitat build service, even though it's slightly Future facing vision is basically still addressing the same basic needs, right?
31:21
Except risk right making sure that you're in compliance and that you aren't I guess exposed to vulnerabilities Along with efficiency right having proper testing all of that has been automated in the process instead instead of doing Things manually step-by-step as you are in today's current workflow, right?
31:42
We've just codified those existing behaviors and made them automatic You still have to manually promote artifacts from acceptance into production, but otherwise it just codifies those common behaviors I'm looking at the clock and I'm almost out of time. So I was going to talk about some of the flexibility to Maintain visible or a new vision and learning and make a joy a joke about space bears
32:06
But now the time pressure is on and my speaker notes literally say joke about space bears here So I'm just going to go ahead and wrap up instead So from a tooling perspective, right? The requirement is to weave together a cohesive set of practices
32:22
that and Align the the working habits of diverse teams into that You know that cohesive protection against unintended consequences So the fundamental philosophy of chef automate is to do that by default so you don't have to thinking that you don't have to do
32:41
It right. You don't have to think about managing it. It just happens for you automatically and this is the default way that you work So the way to succeed in Transformation is to set up those self reinforcing cycles, right? And again, you do that by one focusing on the metrics that matter for your organization And to putting tools in place that reinforce those behaviors on a daily basis setting up those self reinforcing cycles
33:07
Is how you distribute expertise right and how you align the needs of teams with? Different needs and different goals to optimize around the same set of outcomes So reinforcing those behaviors with tooling choices then turns those daily behaviors into what eventually becomes your culture
33:25
And that's the type of approach that scales across even the largest most distributed groups, so Thank you, and that's our time