“We’re no longer an airline. We’re a software company with wings,” claims Veresh Sita, CIO, Alaska Airlines. The success of today’s businesses rests on software. It is an integral part of infrastructure, so we need to always ask, “How can it be better? More reliable? More secure?”
Nathen started his talk by stating that “automation at scale is required for high velocity IT,” making the point that in today’s environment, you can’t wait months between deployments. Enterprises are moving to continuous integration/continuous deployment, and he advocates for continuous automation.
To implement automation at scale, you have to start with a dynamic infrastructure by:
Provisioning and setting up environments
Implementing dynamic scaling of compute resources
Migrating legacy workloads to the cloud
Deploy in multi-cloud and hybrid-cloud environments
Support heterogeneous environments
Several speakers of All Day DevOps talked about automation, and all of them said a critical step is to treat infrastructure as code. According to Nathen, this means that to programmatically provision and configure components, such as servers, databases, firewalls, etc., you also have to treat it like any other code base. This includes version control and automated testing, but also:
Automated, full-stack application policies
Package and service installation
Versionable, testable and repeatable workflow
Scalable application policies
Management of interdependencies across nodes
When you treat your infrastructure as code and deliver at scale, you can scale elegantly from one to tens of thousands of managed nodes across multiple complex environments.
For software to be effective, users have to trust that it will do what they expect it to do. This is true from handheld calculators to self-driving cars, and it is also true when we automate our development and operations. Nathen advocates that we have to build a pipeline to production that creates faith in us that our code is ready for production. This pipeline must:
Test the code/verify locally
Verify in pipeline with automated testing
Approve with another engineer (aka code review or Nathen’s “four eye rule”)
Build an artifact
Deploy into acceptance environment to automatically test the artifact
Ask someone else, “Do we want to ship this?”
Ship the code with a click of a button
Union (bring together dependencies and run tests)
Rehearsal
Delivered (ship to customers)
What does the future hold?
Infrastructure automation is NOT enough. Why? Auditors show up to audit your infrastructure and applications. The problem is, they use different tools—Excel spreadsheets, notebooks, PDFs, etc. This makes it very difficult to audit. Nathen advocates managing compliance documents as code, too. When we translate compliance into code, it can be executed as part of the pipeline so we can test for compliance throughout the entire life cycle.
Finally, Nathen stresses the need to have application automation, too. Modern applications look like infrastructure as code.
Developers can make applications that operations can deliver and run in production. This makes it easier to consume, run, and keep applications healty. Operable applications need to be:
Isolated
Immutable
Configurable
Built on a common interface for monitoring health
Rebuildable from sources
Reside in common packaging
Maintain runtime independence
As enterprises implement infrastructure, application, and compliance automation, it creates a freedom for people to focus, and people are the key.
Nathen notes that, “DevOps is a cultural revolution and professional movement, focused on how we build and operate high velocity organizations, born from the experiences of its practitioners.” He underscores that people are the future of automation. Automation places the priority on people, which enables great companies and great products.
You can watch Nathen’s entire talk online here, where you can dig deeper into this subject. If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free of charge here. Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here. This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed). It’s all free and online on Oct. 24.
From where I sit in the DevOps community, there is often more focus on dev than on ops. Damon Edwards (@damonedwards) of SimplifyOps sought to change that with his talk, “Ops Happens: DevOps Beyond Deployment,” at the All Day DevOps conference.
Damon dove right into the primary, systemic force behind most DevOps problems: silos. The product development process goes like this: Planning—>Dev—>Release—>Operate. The problem lies in the tendency of many enterprises to place similar functions together. Everyone ends up in a silo. Then walls build up between the silos. Eventually, people only know life in their silo, making handoffs even harder.
We often find application knowledge and business intent are heavily emphasized on development side but light on the operations side. Likewise, operational knowledge is heavy on the ops side, but light on the development side. Furthermore, development has ownership but limited accountability, while operations has accountability but no ownership.
While many enterprises are striving toward building cross-functional teams, the reality is that the transformations often stop short of truly integrating operations. The result? Silos remain.
So, one has to ask, why is this so hard?
The reality is that enterprise operations are under tremendous pressure. One side is telling them to go faster and open it up, and the other side is telling them to be more secure and be more reliable. These are often seen as competing priorities.
To solve this, enterprises need to “shift left” in the product development cycle operations activity as much as possible. They need to do as much as possible during development. For the deploy function, enterprises should be:
Writing/running automated tests
Writing/exercising deploy automation
Running security scanning tools
For the operate function, enterprises should be:
Writing/exercising automated runbooks
Writing/exercising monitoring/metrics
Operational control (safely!)
However, shifting operations to the left is much more difficult. How do you do it? Embed ownership.
Let me repeat: embed ownership.
First, those who build something define the procedures to fix it, and those who build something fix it when it breaks.
That sounds simple, but raise questions:
How do you safely and securely give out access?
How do you enable the experts to contribute remediations?
How do you give the experts visibility into operations?
How do you do postmortems days/weeks/months later?
Damon recommended four steps.
Step 1: Establish a secure ops portal
Step 2: Establish a software development life cycle (SDLC) for ops procedures
Step 3: Connect with enterprise management systems
Step 4: Make Compliance really happy
Ticketmaster is a real-life of example of this working at a large, prominent scale. Ticketmaster calls its system, “Support at the Edge” and it involves:
Automated Ops procedures written/vetted by the delivery teams
Ops remained in full control of what can run and security policy
Empowered support teams with self-service ops tasks
Empowered developers with limited self-service operations
Combined with new incident response model
Ticketmaster has seen transformative results. Before Support at the Edge, the average mean time to respond was 47 minutes. Now, support at the Edge has reduced that to just 3.8 minutes in addition to decreasing escalations 50 percent and overall support costs 55 percent. Ticketmaster has seen real results.
Damon has more details in his talk, which you can watch online here. If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free of charge here.
Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here. This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed). It’s all free, online on Oct. 24.
Mark Burgess (@markburgess_osl) is a theoretical physicist, but in his keynote at the 2016 All Day DevOps conference, he talked more about economics and human interactives than physics. What does either have to do as the keynote for a conference on DevOps?
Well, for a little more background, Mark Burgess is also the founder and former CTO of CFEngine, a configuration management and automation framework, and is the author of “Promise Theory.” While at CFEngine, Mark worked to apply a theory of how the autonomous agents in software interact with each other. Promise Theory was born.
Exploring Promise Theory
Promise Theory sits counter to obligation theories. Obligation theories view human interactions and behavior under the assumption that people (or agents, in the case of software) choose behavior based on their obligation to follow the rules. Agents are obligated to take a certain action. Promise theory contends the desire to follow the rules is voluntary and that agents can only be responsible for their own behavior, not the behavior of other agents.
In his presentation, Mark started out looking at human behavior and trends in our society. For instance, with technological advances, our need for one another is decreasing, even as our interdependence through communication is increasing. For example, our smartphones enable us to do almost anything without the direct interaction of someone else.
Looking at interactions in society, trust is the basis for our exchanges, working communities, and function as a society. He contends, “The promise is the source of intent by which all promises and observers may calibrate their expectations.” Money is an example of this. Money does not have intrinsic value, but we use it because we trust the backer will stand behind its value and it is more convenient than bartering goods. He explains that in the old monetary economy, banks and governments were the provider of trust; in the new service/IT economy, the service provider is the basis of trust.
How Agents Make Promises
How do you model this trust? Enter Promise Theory, which describes how agents make promises with each other and how this leads to trust between them. Mark outlines the “ingredients” of Promise Theory:
Agents and super agents make promises in a scaling hierarchy.
An agent can never make a promise about another agent’s behavior (only its own).
An agent’s promise need not be accepted or used by its intended or unintended recipient!
An agent makes its own valuations: what you have is only worth what another is willing to give you for it.
Dependency invalidates promises.
At the core of understanding this, you have to understand that collaboration is made up of semantics, what words mean and dynamics: all how things work. And that our ever-increasing service economy is driving us to an explosion of semantics, because words matter so much more than the mechanics. As an example, Mark sketched the hierarchy of promise dependencies in the old and new economies. Looking at the old economy, where we have more dynamic money, the hierarchy is:
Retail→ Money→ Banks→ Central Banks→ Government.
In the new economy, where we have more semantic services, the hierarchy is:
Client→ Network Availability→ Provider→ Internet Authorities→ Company/Service Organization.
The Need for Cooperation
None of these systems could work without cooperation at the bottom of it all. So, production is a cognitive process between the producer and the consumer, but also between the agents inside those organizations that have to interact. Often we create pipelines to describe these interactions, but the interdependencies within the systems are often much more complex than the pipeline can model.
This is all just the tip of the iceberg. Mark has three books that dive into it in detail: “Thinking in Promises,” “In Search of Certainty,” and, “Promise Theory.”
In the end, Mark made the point that technology does an excellent job of both binding us together and pulling us apart. We need to be careful that we don’t take ourselves out of the systems we create, or we could scale ourselves out of existence.
devopsy.kinsta.cloud Supports the All Day DevOps Conference
If this piqued your interest, you can watch Mark’s full All Day DevOps conference session (just 40 minutes). When you do, you can view the other 56 presentations from the 2016 conference online and free of charge. Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here. This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed). It’s free and online on Oct. 24. devopsy.kinsta.cloud is a media sponsor for All Day DevOps 2017.
In this DevOps Chat we speak with Rob England, the IT Skeptic. Rob joins us from New Zealand (you have to love the internet). Rob is going to speak at this year’s DevOps Enterprise Summit London, June 5-6, about the importance of taking care of your people in the DevOps transformation process. Rob is always an entertaining fellow and this chat is no different. If you are attending DOES London this year, you don’t want to miss his session!
As usual, the streaming media of our conversation is immediately below and the transcript of our chat follows that:
Transcript of the Chat
Alan Shimel: Hey, everyone. This is Alan Shimel from devopsy.kinsta.cloud here for another DevOps Chat. We’re lucky to be joined on this DevOps Chat by a friend of mine and a person who’s actually appeared before on our DevOps Chat, all the way from New Zealand: Rob England, the IT Skeptic. Rob, welcome to DevOps Chat.
Rob England: Hi, Alan, and, hi, everybody. It’s a pleasure to be here.
Shimel: So, you know, Rob, actually, I didn’t ask, but are you back home in New Zealand right now?
England: I am, so I’m about to have my breakfast. [Laughs]
Shimel: Okay.
England: Tomorrow. Your tomorrow. So –
Shimel: Yep, it’s my tomorrow. You’re already living my tomorrow—that’s interesting. So, Rob, of course, I think you’re well known within the DevOps community and the IT community at large, but, for anyone who’s listening may not be familiar, why don’t you give us a quick little background?
England: Okay, thank you. Yeah, so I come from a service management background, so I have a bit of a presence internationally with a small blog that got a service management following, so that’s how I sort of became internationally networked. And, originally, I was a bit of a skeptic of the whole DevOps thing, but I was gradually turned, by Gene Kim and by John Willis and by Jez Humble and others, into a bit of an enthusiast, and now my whole life is DevOps, really. I consult here in Wellington, New Zealand to the DevOps community and I’m working with a couple of the largest government departments here in New Zealand now, helping them on their DevOps journey.
Shimel: That’s just great. And, Rob, you’re traveling from New Zealand to London, June 5th and 6th, for this year’s DevOps Enterprise Summit, DOES London. It’s at the –
England: I am.
Shimel: – QEII Conference Center. And you’ll be speaking there as well.
England: I am. Oh, I’m really, really pleased and honored to be selected to speak; I think that’s fantastic.
Shimel: I think it is too. So, Rob, we’re lucky enough to interview a few other speakers from DOES—not only from London but in past DOES events in San Francisco, but can you give our audience a little bit of a flavor for what it’s like or what’s the process like or what motivates one to go speak at a DOES event?
England: [Chuckles] Oh, in this case, what motivated me was Gene Kim, so I was talking to him about some of the people stuff that I’m quite passionate about, and he said, “Hey, you should write that up and submit it,” so I did. And, from there, it was pretty straightforward—I put all the details in and had my proposal accepted—so that’s very exciting. As I say, I’m very passionate about the people side of things and the cultural change, and the focus for this presentation is around taking care of our people through that transformation.
Shimel: Excellent. And so, Rob, when you mention people like that, I’m reminded or brought back to a—I think it was Adrian Cockcroft’s presentation in San Francisco this past—don’t remember if it was October or November, but you may remember. And Adrian’s presentation was very much that,“Hey, people are your most valuable asset and you gotta treat them right. And, when you think about the money you spend on tools and all of these other things, it pales in comparison to the importance of spending money on people.”
England: Yeah. Absolutely. In the past, even before my DevOps life, I used to write about how, if you look at any project, when we’ve had projects, and how the money was allocated within that project, if it wasn’t sort of one-third people, one-third process, one-third tools, then you had a very strong indicator it wasn’t gonna be a successful project.
Shimel: Mm-hmm. Repeat that again, though, ’cause you know how you New Zealanders are – you talk so fast. [Chuckles] That it was one-third, one-third, one-third?
England: Yeah, yeah, yeah. So one-third people, one-third practices, one-third tools. If it’s not something like that, it’s very typical to see project proposals that are going to spend 50 percent of their money on installing the tools and 50 percent of their money on redesigning their processes—oh, and, by the way, there’s a day’s training. You know, and it’s like, well, there’s nothing else recognizably about workshopping with people or collaborating with people or, you know, coaching people or all the other people aspects. It’s very common to see projects that are not planning to spend any money on all that, and I think that’s a –
Shimel: I agree.
England: – a formula for failure, right?
Shimel: Yeah, no, it is. I mean, we tend to take the people part of it for granted, and, just as you said, you don’t spend the money on it, will spend a ton of money on tools and infrastructure. Right?
England: And I have to say, I think that’s one of the two primary reasons why service management initiatives were so often unsuccessful, was that, I thought, didn’t coach us enough to focus on the culture and the transformation, and we spent too much time on process, so DevOps—for me, the power of DevOps or a big part of its power is it’s focused on people and culture.
Shimel: I have to agree with you. I have to—you know, Rob, I’m reminded of, back in my security days, the co-founder of StillSecure, I went to visit a rather large bank out in New York, and it was about vulnerability management. And we were talking about the vulnerability management program they had in place and I mentioned to ’em that the way they were doing things, it was forcing his security team not only just to scan at night, which is, you know, normal, but to actually only do remediations on weekends.
England: Mm-hmm.
Shimel: And I said, “You know, that means that your security team is working every weekend, in addition to working during the week, ’cause you don’t have enough people to stagger that.” And he said, “I don’t care. I pay them by the week; I don’t pay them by the hour. I don’t care if they work seven days a week.” And that –
England: There’s a good boss, eh?
Shimel: Yeah, no, that’s someone you’d wanna work for, right? But this, unfortunately—you know, we talk about culture and the whole “Kumbaya” thing that many people kinda try to say with DevOps, but it’s real. You gotta treat your people as your greatest asset, and that was Adrian’s message, right, at DOES San Francisco. They’re not –
England: That’s powerful.
Shimel: Yeah. And they—if you treat ’em like crap, crap is what you’re gonna get, I’m afraid.
England: Absolutely. And my particular focus for this presentation is about the effect of the transition on people in your organization and, in particular, there’s this “Get on the bus” thing, but we don’t wanna actually throw people under the bus, so it’s giving people the opportunity and the time to grow and to make the transition. There’s very often a “revolution, not evolution” thinking in management’s mind: “Are we just going to change everything?” And, again, we’re very neglectful of the fact—the old bell curve—we’re very neglectful of the fact that just because a few people are coming along doesn’t mean we—we still have to allocate more time for the great masses to get their head around this thing and absorb some of these really quite challenging and radical concepts that underpin Agile and DevOps—it does people’s heads in, as we say down here.
Shimel: Yeah. So, Rob, let’s talk about that a little bit, if we can. You know, you’ve now consulted, as you said, with a bunch of government departments and companies, both in New Zealand and in other parts of the world. What, from a people point of view, what is the hardest things that these guys or these people have to kinda wrap their heads around to make it successful?
England: Oh, I’m sure the biggest challenge is getting—well, actually, one of the biggest challenges is getting away from that silo-ed thinking, and so the other power of DevOps, along with its focus on people, is its focus on systems and systems theory and systems thinking. And so I think that they struggle to get out of their silo and start thinking holistically and seeing the whole flow of value and understanding their role in that. That is a big challenge to just about everybody.
Shimel: Agreed.
England: Then there’s also—yeah. And then there’s also peculiar challenges to each organization as well, right? So I’m thinking of one where a particularly psychopathic CIO had moved on, and it was trying to teach people that, “It’s okay now. You can come out from under your rocks, you know? It’s gone.” So that’s –
Shimel: “Out from under your rocks.”
England: Yeah. That’s a—they all sort of crawled away into shelter, you know? And so that’s the peculiar problem in one situation. So there’s—you know, every place has its own challenges, but a universal one is that siloed thinking and another universal one is just the letting go of the—do you remember the Bastard Operator from Hell, BOFH, or –
Shimel: Mm-hmm.
England: – or Dilbert‘s Wally? You know, these characters that—it’s considered funny in IT that people have dysfunctional behaviors and are misanthropic, and part of the DevOps message is just we don’t tolerate that anymore. That negativity is not allowed—we just don’t tolerate it—and getting rid of some of that old cynical bitter and twisted IT thinking is also a common challenge.
Shimel: I agree. I agree. And you know what? I think part of it is not only the negativity from whether it be a supervisor or peer; I think the other biggest thing that I personally see and when I talk to organizations around DevOps and stuff, and not just dev and ops—when I talk with QA and security and management and so forth—is the finger-pointing, is the—it’s almost like American politics, I’m sorry to say, in that “Yeah, I know this is screwed up, but blame the other guy,” or “If you think this is screwed up, you should see how screwed up the other guy is.”
England: Absolutely.
Shimel: You know? “And it’s not my fault; I inherited a mess,” and all of this kind of thing where one of the refreshing things about DevOps is it started with the blameless postmortem, but it’s more than just a blameless postmortem—it’s about “Stop pointing the finger and let’s work on solving this together, instead of just saying, ‘Hey, it’s this mate’s fault and it’s his problem.’”
England: “I’ve got your back.”
Shimel: Yep. I mean, and that –
England: I’ve got your back, buddy.”
Shimel: You know, and that may sound hokey and “Kumbaya-ry” and all that, but, really, I think that’s when you start building a team.
England: There’s a really good cartoon, that might be a Paul Wilkinson one, where the ops guys are at one end of the boat, looking down at the dev guys at the other end of the boat, trying to deal with a fountain of water and saying, “Not my problem, not my end of the boat.”
Shimel: Right. Uh-huh. Exactly. And we’re all on the same boat, though. So –
England: Yeah. Yeah.
Shimel: So this is a real thing. Rob, other than DOES, have you been talking about this kind of subject at other events and so forth?
England: Oh, for sure. So, actually, it’s been an interest of mine since before I was consulting. I used to work in—for my sins, for a vendor, and I used to do work on professional development there and trying not to let the technical people fall under the bus and trying to get them to skill up to be consultants, rather than just product jockeys. So I’ve worked and talked in this field for a long time, just as a personal passion. I hate to see good people lost, you know, just because their organization failed to make sure they were coming along and to take care of them.
Shimel: Sure. Sure.
England: So that’s a long-term passion, but this particular topic now I’m hatching especially for DOES, to put together a presentation specifically about the DevOps implications of—it’s called “Surviving DevOps,” so making sure everybody’s—it’s not just that you individually survive, but that “no person left behind,” you know, as well.
Shimel: I agree with you. So, Rob, geez, I’ve met you—wasn’t this year’s San Francisco DOES; it was last year’s. So it wasn’t 2016; it was 2015 DOES San Francisco. And we’ve, of course, seen each other several times since, but –
England: And, you know, I’m one of the few people in the world who’s been to every single DOES in both the U.S. and the UK.
Shimel: So I think I’m one of them too, actually, but –
England: Yep, you would be.
Shimel: Yeah, which is interesting, when you think about it that way. But let’s—I mean, many in our audience may not have been lucky enough to even get to one, let alone five or six of these things. Can you give our audience a flavor of why? Why do you keep coming back? Why did you feel compelled to wanna speak at this one? What makes this a great event in your mind?
England: Well, I think it’s the fount of knowledge for DevOps, especially DevOps enterprise, so my interest is DevOps for hoses, not DevOps for unicorns. And, very much, the focus of the enterprise conference is around DevOps in the real world, DevOps in the enterprise world, so that’s the first thing. The second thing is that Gene does a fantastic job of focusing and coaching presenters to make sure that their presentations are really short and pithy and full of value, and they also make sure that the presenters are practitioners, so there’s not a lot of talking heads, except for some really high-value experts like John Willis and Jez Humble and Adrian Cockcroft, the people who are up there purely because of their intellectual strengths. But most of the speakers are there because they’re reporting back from the coalface about their own experiences and learnings, and so that, to me, is gold.
Shimel: Yes. Any—well, I guess that kinda says it all, Rob. If anyone had any doubts about whether they’d wanna go to this or not, that clears that up. Rob, anything else happening exciting around DevOps you think people should be on the lookout for?
England: Oh, well, I’m not sure about _____ – the value for me is that I live on the last rock on the planet, so I actually get quite a different lens on DevOps than perhaps those, like yourself, immersed in the big economies and big societies, and, certainly, it’s going gangbusters here. There’s a huge wave of interest in the mainstream—in government, in the airline, the banks—and I’m gathering that that’s not necessarily the case everywhere in the world, so, you know, I think that –
Shimel: No, I think it is. I really think it is.
England: Yeah. Yeah. But they’re not just dabbling anymore, right? They’re actually transforming; they’re restructuring the way they go. And, to me, that’s the excitement of the moment, is that this thing is mainstream. You know, it’s bridged the chasm. Remember the Star Wars book about crossing the chasm? You know, the –
Shimel: Yeah. Sure do.
England: – DevOps has gone from the early adopters to mainstream now. It’s definitely –
Shimel: Oh, it’s certainly mainstream, but I –
England: – the majority.
Shimel: So I think it’s in the early majority, though, not the later majority.
England: That’s true. That’s true. It’s still not everyone; it’s still not—but, yeah, but it’s certainly jumped—it’s certainly bridged the chasm and it’s on its way up that curve.
Shimel: Oh, no doubt about that. No doubt about it and, hey, we live it every day here at devopsy.kinsta.cloud, as we continue to kind of chronicle all this. Anyway, Rob, we’re about out of time. I wanna thank you for joining us all the way from New Zealand. Look forward to seeing you in London and your presentation and thanks for doing everything you do, Rob. I mean, you know, you’re a healthy IT skeptic. In IT, skepticism is healthy, right?
England: It sure is and I love doing it. Thanks, Alan. It’s always a pleasure to talk to you, my friend.
Shimel: All right, Rob. You be well. We’ll see you in just a couple—well, it’s about two months now, probably.
England: See you there.
Shimel: All right. Rob England, IT Skeptic, speaker at DOES London on June 5th and 6th at QE Conference Center. This is Alan Shimel for DevOps Chat. We’ll see you soon on the next DevOps Chat.
The results and analysis of the State of DevOps Report 2017 report are due out in early June. just in time for the DevOps Enterprise Summit London June 5-6. In this DevOps Chat we speak with Puppet exec and one of our favorite interviews, Nigel Kersten.
Of course, Nigel and the folks over at Puppet have been co-producing the State of DevOps report and survey for six years now. For this year, Nigel along with Dr. Nicole Forsgren and Jez Humble of DORA, will be co-presenting at the DOES London, where they will announce the results of this year’s survey. It should be quite interesting.
Nigel gave us some sneak peeks and early trends for this years report, as well as discussed the DevOps Enterprise Summit and, as usual, some good info on what is happening at Puppet and the DevOps world in general.
You know the drill by now: The streaming audio of our conversation is immediately below and the transcript of our conversation is below that. Enjoy!
Streaming Audio
Chat Transcript
Alan Shimel: Hey, this Alan Shimel, devopsy.kinsta.cloud, and we’re here for another DevOps Chat. And we’re happy to be joined again by a repeat guest on DevOps Chat, none other than Nigel Kersten of Puppet. Nigel, welcome.
Nigel Kersten: Hey, Alan. Nice to talk to you again.
Shimel: Good to speak with you. So, Nigel, we’re not talking about the latest and greatest from Puppet today. Well, maybe if you wanna just mention it quickly, feel free, but I wanted to really talk a little bit about the upcoming DOES London event, Gene Kim’s DevOps Enterprise Summit, which is June 5th and 6th in London at the QEII Center, and you will be presenting there. Correct?
Kersten: I will be. Yep, with Dr. Nicole Forsgren, who’s one of the other authors of the DevOps report, and DevOps Enterprise Summit London last year, I think, was honestly one of the best events I’ve been to in this space for a long time and I adore London for lots of reasons, and so it’s always great to be back there.
Shimel: Yeah. And, Nigel, correct me if I’m wrong – is Jez Humble also presenting with you and Dr. Nicole?
Kersten: I think Jez probably will be, but I’m not sure if it’s quite confirmed yet. We’re sort of trying to work out how we’re covering all of the different events, for the various roadshows and webinars we’re doing around the DevOps Enterprise Summits and the DevOps enterprise report.
Shimel: Yep. Okay, so I guess we’ll stand by for final confirmation on that, but, certainly, you and Dr. Nicole will be on, and, of course, Nicole has appeared on our show before and we’ve talked a little bit about not only this year’s DevOps survey but past years’ as well. But, Nigel, for some of our listeners who maybe weren’t lucky enough to hear previous talks about it, this is what? The sixth or seventh year of the State of DevOps survey?
Kersten: This is the sixth year, which is kind of amazing ’cause, you know, I think, when we first started with the fantastic Alanna Brown, who also works here at Puppet, everyone was a bit skeptical about it. I think this was even before you’d started devopsy.kinsta.cloud and people were like, “Is this really a thing? Do we really need a survey about all of this?” but I think it’s just gone from strength to strength over the years. So, yes, I guess, for the people who are sort of new and may not have come across the report before, what we essentially do is we survey a whole bunch of practitioners—we’ve done tens of thousands of ’em around the world over the last six years—and what we do is we ask about the practices and the tools that they use, but also some metrics about “What’s your mean time before failures? How quickly can you deploy your software? What sort of practices do you use?” as well as what sort of outcomes you have. And then we do a statistical analysis on all of that so that we can—and we actually end up showing that there’s a huge gap between what we call “high-performing” IT organizations and everyone else.
And, in fact, interestingly enough, over the last few years, we’ve shown that the gap is increasing over time, so the people who’ve adopted DevOps practices—because, essentially, what we’re showing is we’ve been able to show statistically that what we tend to call “DevOps practices,” around using CI, using CD, using infrastructure-as-code software, doing continuous deployment, using testing, storing things in version control, all of these practices, when you cluster them, are the people—the people who employ these practices are the people who have high-performing organizations. And they’re really huge statistics—they tend to be thousands of times better, being able to deploy just ridiculously faster—and, essentially, what this ends up showing is you really don’t have to sacrifice quality for speed or vice versa, so we’re seeing that these people are both producing high-quality infrastructure and applications and they’re doing it far more quickly than everyone else.
I think one of the things I’m really proud of with the DevOps report is that it’s useful to sell DevOps practices within your organization, so I talk to an awful lot of customers and practitioners out there who are really thankful for the report because it tends to be focused on business outcomes. So, even though we’re surveying practitioners, it’s something that’s really applicable to C-levels and VPs and directors. They can look at this with them and go, “Ah, this is where the industry’s moving and these are the sort of benefits we’ll actually get.”
Shimel: Excellent. And, Nigel, in typical humble Nigel self, you’re—I mean, let’s give a little bit more flavor, if we can. Over the five previous years, I think there’s over 25,000 responses to these surveys.
Kersten: Yeah, no, that’s right. 25,000 over five, six years. It’s pretty crazy.
Shimel: So that does represent a—in a field like DevOps, which is fairly new, right, it represents a sizable amount of people and organizations who have taken the time and contributed to the data that you guys have analyzed over the years. And another important thing, I think, to note for our audience is not only the analysis of the data but even the questions themselves are, from a statistics point of view, a statistician’s point of view, rigorous—rigorously designed and rigorously analyzed. And, look, having a Ph.D. statistician helping you with it doesn’t hurt, but so these are not just some –
Kersten: No, it’s not your average –
Shimel: – go up and doing surveys.
Kersten: – sort of marketing survey at all, and I think this is why it’s always really important for us that—you know, we’re a software vendor and we’re in this space and there’s a lot of people in our space who do pretty fluffy kind of surveys that only take two or three minutes and then some sort of ridiculous claim gets made, so this is why we’ve always been really keen on working with the external parties of Gene Kim, Jez Humble, Dr. Nicole Forsgren. Particularly Nicole. She’s a trained statistician who’s literally got a Ph.D. and has spent her career working on studying organizational performance, which overlaps with DevOps in really interesting ways, but I think having that external rigor, and I think it helps keep us honest as a software vendor. So this is something we really loved, having a partnership with them, ’cause this is their specialty.
They actually—to give them a little bit of a plug, they have their own organization, DORA, DevOps Research and Assessment, where they’ll come in and do benchmarking of your organization and actually measure how you’re actually doing, so I think it’s just really great. We’re clearly really plugged in as Puppet into this whole community, but they plugged in at a different level, and working together, I think, means that we both get to expand reach and bring a bunch of statistical rigor to something that could easily devolve into a self-serving survey, which ultimately doesn’t –
Shimel: Hey, Nigel?
Kersten: Yep?
Shimel: I thought I lost you there for a second. I apologize. Agreed, I mean, on all of the above. And that’s really—I want people to understand that, that this isn’t a marketing survey they up and have done now for six years running. I wanted to make another point, Nigel, and that is, certainly, over the last two years at least, and I would imagine for this year as well, one of the real nuggets of wisdom that have come out of this analysis is really just how high-performing or what high-performing IT organizations mean to the bottom line of these companies that are doing it. I think, at some level, we all at a gut level say, “Well, if you’re performing better, you’re releasing faster, it should translate into a better company,” but, certainly, the State of DevOps report—survey and report is one of the few that are out there that really connects the dotted lines here.
Kersten: Absolutely. So you look into the sort of things that people are actually sort of seeing. What we’re seeing, so to sort of hit some of the boon stats from last year, is that we’re seeing the high-performing IT orgs, three times lower change-failure rate, 200 times more frequent deployments, and 24 times faster recovery from failures. And those are really amazing stats because I think they really resonate, both with practitioners who’re the people who are getting woke up in the middle of the night or having to deal with the pain of a deployment that didn’t work properly, but they’re also the sort of stats that your average, been-away-from-the-technology-keyboard for a few years, high-level executive, can look at it and they go, “No, that’s actually what we want. We want to be able to deploy more frequently,” because, I think, one of the lessons that SAS has taught us is the reason a lot of SAS companies outstrip on-premise competitors is because, every time they deploy, it’s a chance for learning, it’s a change for feedback.
And Agile has taught us, from traditional software development, the more frequently you can deploy, the smaller the deltas are in those deployments and you can do more frequent cost correction, so you can actually produce a much better outcome over time by deploying more frequently and being able to correct course more frequently.
And, to, I think, bring it back to enterprise folks, not everyone always thinks about deployments in this way, but, every time you get a patch from your vendor, that’s another deployment. Every time you respond to a security incident internally, every time you have to follow through a recommendation of your audit and compliance committee—all of those things are deployments and the more pain-free and friction-free you can make the ability to deploy within an organization, the more responsive you’re gonna be to all the different stakeholders.
Shimel: Yeah. Let me give you my favorite stat that you omitted or you just didn’t get a chance to, and that is these high-performing IT organizations have 50 percent less vulnerabilities post-deployment.
Kersten: Yep.
Shimel: That’s huge.
Kersten: It’s a major. And you’re spending less time on that. And I think the other related one that’s really amazing is that the high-performers spend 22 percent less time on unplanned work and rework. And, for anyone’s who’s been neck-deep in infrastructure, it’s the unplanned work that kills you. It’s the context switching. You’re not making progress on your defined road map every time you’re having to spend time on unplanned work.
Shimel: Yeah. So, Nigel, these are all fantastic insights and metrics, so now, of course, though, we’ll turn the table on you and say, “Hey, what have you got for us this year?” I know it’s early; I know you haven’t released the report yet. You’ll probably be announcing a lot of the results, I think, come out just at the time of DOES London, which, again, is June 5th and 6th, but is there anything you can share with our audience as maybe a preview?
Kersten: So I think one of the things that I could share is we’re still going through doing the analysis, but we’re seeing that, again, the high-performing orgs are achieving just as well compared to everyone else, as they have in previous years. It doesn’t look like there’s only sort of peak, as far as implementing these practices. I think the whole industry, even people who have been doing this for a while, have still a fair way to improve.
I think one of the really interesting things—well, there’s two big ones I wanna call out. One is that, this year, we spend a bit of time working on non-profit performance ’cause, in previous years, we’ve shown that commercial companies who are high-performing IT orgs tend to outperform their financial metrics, outperform in the stock market, their internal company goals, but, this year, we decided to focus on non-profit performance, and so we’re looking at things like, “What’s their operating efficiency like? Customer satisfaction? Quality of the products that have been shipped?” So we’re actually, I think, showing that DevOps practices in high-performing IT orgs impact in a positive way all sorts of industries, so I think that’s gonna be one of the really interesting sections.
The other section, I think, that’s gonna be really fascinating is that we’re actually looking at what’s the—there’s a myth out there, to sort of back up a little bit, that DevOps practices tend to work if you’re building all of the software yourself, if you’ve got a web app, if you’re building a whole bunch of stuff in Node.js or something like that, and deploying it to the cloud, sure, you can do DevOps—you can do continuous integration; you can do continuous delivery—but, for those of us who are sitting there running commercial, off-the-shelf software, we can’t actually do that and we can’t actually obtain the benefits that are available by employing DevOps practices. So I think what we’re gonna be showing is that this isn’t true, that there’s a couple of things you can do as an organization, in the way you consume commercial, off-the-shelf software, to actually let you employ continuous integration, continuous delivery.
Now the reality is you’re not gonna be able to test all the same kinds of things because, unfortunately, you know, lots of vendors that release software don’t necessarily have an API-first policy, so you’re not always gonna be able to test everything inside the application, like you can’t run unit tests, necessarily, ’cause it’s not your code, but there are a whole bunch of things you can do. And one of the big bits of guidance that we’re gonna be pushing is that, when it comes to commercial, off-the-shelf software, really try to make the installation as vanilla as possible. Don’t spend forever customizing it. And, if you’re having to customize it because that’s what your business processes say, in many ways, the lower-cost and better-outcome approach is to not customize the software and adjust your business processes because there’s something within your control, generally. And if you adjust those, then it becomes simpler to deploy that software into a CI system, to have Jenkins or Bamboo or whatever do deployments of it, do external black-box testing, make sure that it actually works, and then roll it out to production.
So we’ve got a pretty strong belief that, when it comes to utility computing, to sort of use Martin Fowler’s distinction between utility and strategic computing.
Shimel: Yep.
Kersten: There are huge efficiency gains to be made there, but there’s a few things you can do to avoid those problems. The analogy I kind of come back to is that there was a period, I think, in the late ’90s and early 2000s, when lots of people would customize their Apache installs. They would sit there and come up with this fine-grained list of modules, configured in specific ways, and, every time they deployed a new version of Apache, they’d eke out another one or two percent performance by having this really customized installation. It turns out the actual cost to the business is really great because those tend to be manual processes—you’re turning yourself into a snowflake when you didn’t actually need to be—and I think the more you can commoditize the software you’re buying and that you’re building and that you’re deploying, the faster and more friction-free a lot of these processes are gonna be.
Shimel: Got it. You know, Nigel, that—so I’m old. That’s firing up some old synapses in my brain back from the dot-com days, when I helped start a company called “Interliant.” We were an early ASP. And, mind you, this is before we have a modern cloud and virtualization and ubiquitous connectivity, but we were offering hosted Lotus Notes, PeopleSoft, Oracle applications, Lawson ERP—I don’t know if you remember Onyx was an early CRM tool back then.
Kersten: Oh, yeah. Yep.
Shimel: That’s a blast from the past, huh?
Kersten: Totally.
Shimel: Anyway, so our thought was to offer hosted versions of these applications. This is early, right? We called them “application service providers.” And what we quickly learned in—you know, when you go to market, and we did the whole IPO thing, all of that, but what we learned from our enterprise customers was that, as much as we wanted them to run a vanilla PeopleSoft or a vanilla Lawson or Onyx or even Lotus Notes, for that matter, the best we could hope for was about 80 to 85 percent of out-of-the-box, just plug-and-go. They always needed—and so what happened was we had to change our whole business model and we wound up acquiring a bunch of service bodyshops, for lack of a better word, who would come in and do that last-mile customization, if you will, that last 15 percent. And, as a result of that, I will tell you, the business model failed, ultimately bankrupt. And, if you look at all those early ASPs, none of them really succeeded—USinternetworking and Corio, some others—because we weren’t able to get people to use the vanilla configs that would have been easy for us to host, spin up, and put down.
I think you see the same thing a lot today, with kind of bare-metal hosting. Right?
Kersten: Yep.
Shimel: Versus a traditional cloud virtual, you know, kind of hypervisor thing. How many people are using just vanilla bare-metal kind of config versus how many have—and you guys are Puppet, right? You’re dealing with this more than most, right? How many people are highly, highly customizing their bare-metals?
Kersten: I think we’re seeing people shift away from customization. I think there’s probably a few things. One is I think people are realizing that a lot of this industry is sort of commoditizing, and so you may as well use off-the-shelf stuff. And so, if you’re just consuming stuff the way it was sort of shipped from the vendor, whether it be hardware or software, there’s sort of a general expectation that, I think, both software quality has improved—as much as we like to bitch and complain about software, I generally think software has gotten better than it used to be. There was no sort of Golden Age of incredibly rigorous enterprise software, as far as I’m concerned. I think stuff’s getting better. So I think there’s a couple of different pressures there, is that software’s gotten better, people have gotten more used to the idea that various things are being commoditized, and so they’re more willing to entertain the notion that the next layer up is getting commoditized.
Shimel: Yep.
Kersten: I think we’re also seeing things like—so here’s a good example, I think. If you consume Atlassian’s JIRA, the hosted version, versus the on-premise version, you can’t customize it as much. And, if you’re consuming GitHub the public service, versus GitHub enterprise, you can’t customize it as much. And so there’s a general understanding from people that, you know, an uncustomized version, or as much as is sort of possible, is actually pretty good and we don’t need to make everything completely different for everyone else because it means that documentation just works out of the box and people who’ve used the software somewhere else can join the company and have much faster on-ramp.
And I think we’re seeing that—and this is a somewhat optimistic approach—that there’s a general desire for people to adopt software engineering principles and sort of DevOps cultural changes to get to that higher-performing IT organization state. And I genuinely think, if we keep pushing this sort of attitude out to people that, “If you don’t customize your software, adjust business processes to fit instead, that’s cheaper and you’ll get a better outcome,” I think all of those things combined sort of give me hope that we’re actually heading towards a world where people are giving up unnecessary customization.
Shimel: I hope so. But, Nigel, we’re so far off our course here. You know, we were supposed to be talking about DOES London, and let me try to bring you back. So, I mean, obviously, all of this is background and the—this is why this survey is so important, so that we see these trends and we see it manifest itself in how companies are doing things and so forth. Let me ask a little bit—so, Nigel, you’ve presented at DOES before and I did an earlier interview today—I was talking to one of the program committee’s members for London, Jonathan from Hiscox—and –
Kersten: Ah, yes.
Shimel: Yep. And, forgive me, his last name—Jonathan Fletcher from Hiscox.
Kersten: Yeah.
Shimel: You know, and I’ve known Jonathan for some time—great guy. What we—you know, we forget—all rolled into one place in the space of two days, we’re gonna be jam-packed with all of this great information around DevOps and what we’re seeing and not only what we’re seeing but people are gonna talk about what they’re doing right now and what they did last year versus this year versus next year, what the findings are in our surveys, and I think that’s what really makes for a great event. Right? I think –
Kersten: Yeah, I think there’s a couple of things that are really unique about it. I think one is that it’s not a vendor event, and I’m in the business of working the software company and we make and sell software, but it’s also really refreshing to go to an event where everyone who’s on stage is really there just telling case studies, their real-world stories. They’re not product-pitching to you. We’re not getting up and pitching Puppet Enterprise to you at all. We’re getting up and talking about the DevOps report, and everyone who’s there is—I think this is Gene’s big focus, is that everyone’s telling a real-world case study about what they’re actually doing, where the challenges were. It’s war. It’s honest. So I think that’s one section of it, that it’s real stories from out in the field.
But, perhaps more importantly, it’s not just practitioners. And I think those of us who sort of have had a technical background can sometimes get too in the weeds about going and watching someone’s talk about this incredibly interesting deployment they’ve done and what they achieved, but we’re seeing business leaders talking about the actual impact on the business, how they ran large departments, large transformation projects. You know, the term “digital transformation”’s been kicking around for quite a long time, but we tend to see very sanitized case studies, driven either by a software vendor or a large consulting firm or the PR department of some multinational corporation talking about what they’re doing, and these tend to be really warts-and-all stories, going, “This is what we did and this is how it worked or this is how this didn’t work.”
And I think some of those are some of the more fascinating stories, where people are getting up and talking about “Here were our lofty ambitions and we only got 60 percent of the way there and these were the problems we ran into.” And that, I think, is just really, really powerful, so I think the fact that you’ve got senior business leaders and executives there, as well as the fact that they’re all real-world case studies, is just a really, really powerful combination.
Shimel: Yep. I agree with you. As a matter of fact, one of the things I’d love to see is more people get up and talk about failures, right, where maybe DevOps, they didn’t do it right, or what they could have done differently or what have you, where it didn’t work out right and this is what we did as a result, ’cause I think too many people come out of these events, out of Gene’s things, sometimes, and it’s like it’s all rainbows and unicorns and horses and such, and that’s great, but we—you know, as a dad, I try to teach this to my kids—you don’t always win. And that’s why you gotta learn to deal with failure and how to recover from that as well. And I think those are some of the best lessons for people to learn, is we learn more from our failures than from our successes sometimes, so.
Kersten: Absolutely. And I think it’s hard because we haven’t always had a culture in the IT industry of actually performing postmortems and retrospectives on large projects that we’ve done, so it’s people don’t always have great answers for how they would have done things differently, but I think that’s something that’s actually also starting to shift quite considerably. We’re seeing DevOps has been a big part of that, of “Let’s do blameless postmortems,” and, hopefully, that continues so that we see more people being open about their failures.
‘Cause I think one of the things I find really frustrating—this has happened to me more than once and I don’t think this is gonna identify me, one customer or user, because they do so many of them—seeing your executives at Amazon summits get up and talk about how fantastic their whole cloud migration journey has been and that they’re all in the cloud and everything’s done and it’s absolutely wonderful. And then you go talk to the VPs or directors who are actually running those deployments and they’d be like, “Oh, God, no. We’ve only moved five percent of things and it’s been a miserable failure and we’ve now added three years to the project because we’ve fallen over organizational boundaries.” So I think that gap between the sort of PR-style business leader talk and the reality—that’s not a gap that actually exists at the DevOps Enterprise Summits, which I think’s been really fantastic.
Shimel: Yep. Agreed. Agreed. Well, Nigel, our little 15-minute chat has turned into a solid half-hour, and I think we’re gonna need to call a break here. We are looking forward to the release of this year’s analysis of the survey, looking forward to your presentation along with Dr. Nicole at Gene Kim’s DevOps Enterprise Summit in London, June 5th and 6th, and just always looking forward to what you’re up to and what the folks in Puppet are up to. Many people, you know, when they think DevOps, they think of companies like Puppet, right? A leader in—I don’t know if they’re ever gonna do a DevOps Magic Quadrant, but—or some sort of stuff like that, right? But, I mean, seriously, Puppet’s one of the cornerstones here and you’re one of the cornerstones in Puppet, so it’s always great to hear what’s happening from you and getting caught up. It’s a pleasure.
Kersten: Aw, thanks, Alan. So I will get one little pitch in, which is, because of DevOps Enterprise Summit being in London that week, we’re going to be announcing pretty soon that we’ve got a Puppet Camp happening pretty soon afterwards, so there’ll be a Puppet Camp in London, and this will be a slightly different tweak on the Puppet Camp format. We’ve run hundreds and hundreds of these events over the last few years, but we’re doing a slightly different thing, where we’re having a sort of more executive-manager-focused morning and a more practitioner-focused afternoon. So, if you’re someone who’s an IT architect, you might find mornings and afternoons both applicable, but we’re really looking to try and join together the conversation for sort of senior executive leaders as well as practitioners on the ground. So we’re already collecting a whole bunch of really great talks, both for the morning and for the afternoon, but, for those of you who are into Puppet, look out for a Puppet Camp London coming soon after DevOps Enterprise Summit.
Shimel: All right. We’ll try to get info on that up on devopsy.kinsta.cloud for anyone interested. Nigel, fantastic, man. Thank you so much for the time today. We appreciate it. Nigel Kersten of Puppet here on DevOps Chat. This is Alan Shimel for DevOps Chat. Hopefully, we’ll see you soon at the next—on the next DevOps Chat. Until then, have a great day.
Our guest on this DevOps Chat is Jonathan Fletcher, CTO of Hiscox. Jonathan will be quick to tell you that he is actually “interm” CTO. But as I told him in our Chat, if Hiscox is as sharp a company as I think it is, it will make that title permanent soon. I have known Jonathan for about 3 years or so now; I believe it was at a Ranger4 event in London where I met Jonathan. It was readily apparent to me that he was the driving force behind Hiscox’s impressive DevOps transformation.
Jonathan is on the program committee for this years DevOps Enterprise Summit London. We spoke a bit about what it is like to be on the programing committee for DOES. We also spoke about what he is presenting at DOES. You will have to listen or read along to find out.
As usual, the streaming audio is directly beneath, with the transcript of our chat below that. Enjoy!
Audio of our Chat with Jonathan Fletcher
Transcript of the chat with Jonathan Fletcher
Alan Shimel: Hey, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat, and I’m very happy to be joined by our guest for this DevOps Chat. It’s Jonathan Fletcher, CTO of Hiscox. Jonathan, welcome to DevOps Chat.
Jonathan Fletcher: Hi, Alan.
Shimel: Great to hear from you, Jonathan. I probably haven’t spoken to you since, oh, maybe DOES London of last year, which was also in late June and –
Fletcher: No, that’s right.
Shimel: Yep. Since that time, looks like you’ve got a new title over at Hiscox. Is that correct?
Fletcher: That’s right. Interim at the moment, but, hopefully, that will develop into a permanent role in the not-too-distant future.
Shimel: Well, if they’re smart, they’ll make you permanent.
Fletcher: A CTO office.
Shimel: Yep. Excellent, John.
Fletcher: Yeah, I think you’re quite right.
Shimel: And well-deserved.
Fletcher: Yeah
Shimel: Well-deserved.
Fletcher: Thank you.
Shimel: So, Jonathan – excuse me – Jonathan, I wanted to speak to you today, though, a little bit about the upcoming DevOps Enterprise Summit London 2017, which is June 5th and 6th, at the QEII Conference Center in London. And you’re actually one of the speakers lined up for the event. That’s correct?
Fletcher: That’s right.
Shimel: And, Jonathan, can you – I don’t know if it’s too early or not, but can you give our audience maybe a little bit of a preview of what you’ll be talking about?
Fletcher: That’s a good question [chuckles] and I’m not sure really sure yet. I think what I’m gonna be talking about is a little about a continuation of our journey, particularly about moving to cloud and what that means, the business results that can be found from doing that, along with sort of where we started and how that changes the IT organization. ‘Cause moving to cloud isn’t just a move of technology; it’s change in skills; it’s a cultural change. It changes things that I hadn’t really thought about, a way we budget, I mean, in fact, from a legal compliance teams. It’s a real transformation program for us. I kind of keep (saying) that savings isn’t IT 1.1; this is IT 2.0. This is a new IT department. So I’m really excited to kind of talk about that. We’ve got a long way to go ourselves, but seen some good early signs with cloud adoption, so I think that’s where I’m gonna focus my time.
Shimel: Fantastic. And, Jonathan, of course, in addition to your speaking role with DOES London, you’re also on the – is it called the “speakers committee”? Is that what it’s called?
Fletcher: Yes, right, programming committee.
Shimel: Programming committee. I’m sorry. Jonathan, can you – our audience, the overwhelming majority of them have not served on the program committee. Can you give us a sense of what is involved in that?
Fletcher: So there are dozens and dozens of people who want to come along and share their story next year, so the program committee really is around trying to filter some of those down – not everyone can come and talk – and trying to make sure they are as much relevant to the audience that’s coming, so I think it was worth reimbursing in last year. it was real stories from people doing transformations at real enterprises, and not unicorns, not ace, but is this a real bank, real insurance company, real companies with a legacy of acquisitions and different types of IT, different technologies, and hearing about how they’ve got on and what they’ve got to do in the future, so that’s really powerful. So program committee’s trying to turn a number of – dozens and dozens of submissions to the program down into a really good, tight sets to deliver over two days in June.
Shimel: I got it. And, Jonathan, I don’t know if you even know the answer, but can you give our audience a sense of how many submissions versus how many speakers are actually selected for an event such as DOES London?
Fletcher: So I’ve seen a bit of pre-filtered list, so I couldn’t speak on Gene’s behalf how many there were, but I’ve seen hundred – in the hundreds, I guess. And I think that’s down to 30-something; again, I don’t wanna get the numbers wrong, get the (incorrect) stats, but it’s significant amounts and significant amounts of people that Gene has conversations with, I guess, _____ _____ _____ _____ get through to a formal submission, so it’s very significant, which I think is a really good thing. Obviously, people are seeing a value in DOES London and wanna come share their stories, so it’s a shame not more people can do it, but it’s only those two days.
Shimel: Yep. Absolutely. You know, and I have some ideas around that I’m gonna talk to Gene about. But, Jonathan, was there any – obviously, the DOES, the Dev-Ops Enterprise Summits, traditionally focus on large organizations, “horses,” as we call them, telling their transformation story. And some of these stories we’ve now seen and followed over multiple years and we’ve seen that transformation evolve. Were there any particular themes or things that the committee wanted to really bring out for this year’s event?
Fletcher: I think it’s lot of different things. I think a – in terms of sense of continuity between last year’s and this year’s, so what are the results that we’ve seen, in terms of transformation and – that seems to be a bit of a theme. To share that continuity _____ _____ years is quite an interesting thing to look at. The theme, obviously, is try and – the _____ tend not to be technically focused, so we don’t have too many groups talking about technology, more about the people and process of things. So I think a lot of what you’ve heard last year, the same kind of thing, but, hopefully, just seeing people a bit further along the journey, where they’re going to and the challenges that they’re running into.
Shimel: So, Jonathan, this – you know, I’m gonna attend this year’s DOES London event, and this will be the, man, the fourth or fifth DOES that I’ll be attending. And, though I think I’ve come to – I think all of us have come to appreciate hearing the transformation stories of these various organizations, bigger picture, in order for DevOps to continue to grow, right, what else needs to come to the forefront at conferences like DOES, other than “Hey, we tried to do this DevOps thing and here’s how we’ve done”? Do you think at some point we need to hear more than that around DevOps?
Fletcher: Sorry, what do you mean?
Shimel: So, in other words, at this point in the game, depending on who you believe and who you listen to, a majority of enterprises have at least dipped their toes in the DevOps pool, if you will. Not many of them have undergone an enterprise-wide transformation, but at least they’ve started along their way. What more – so, in other words, what is there beyond the “We’ve tried to transform the company” type of lessons that the DevOps community needs to learn from these events? Or maybe there is nothing more.
Fletcher: That’s a good question. Well, I don’t know. It’s a difficult question to answer, really, ’cause it depends on the strategic direction for those companies and how far they need to push the barrel. I mean, not everyone needs to release 400 times a day _____ _____. You know, the different companies got different requirements. And I think, really, DevOps is such a all-encompassing term now that it’s kinda lost its meaning. If your company is about improving quality or that’s your strategic goal, rather than the pace of change, there are different things for different people, so dipping your toe in the water is fine. I think DevOps is for everyone, regardless of scale of company, so those focused on enterprise, well, that doesn’t mean that, if you’re a small shop, that’s not relevant to you ’cause it is.
I think, really, it’s such a wide topic that seems to encompass Agile and Lean and technology and people, and it’s so vast in topic that, actually, the next step for people in the transformation program ought to stop worrying so much around necessarily what other companies are doing. The war stories are good, but it’s focusing more on what that really means to your company. It’s no longer about DevOps transformation; it’s about business success transformation and what you need to get to get you there. So I think a bit of maturing thinking from companies that started on this program is really actually what they tried to achieve and where they need to get to because I think there’s an assumption between certainly some people aspect where it’s all about Puppet and getting 4,000 releases out the door, and that’s not always the case. So _____ _____ big business goals and I think really trying to realize some of the results so that the business benefits ’cause we’re doing this not because it’s cool and it’s _____ cool IT; it’s because there’s tangible business benefits in doing it. And I think that’s really what the community needs to focus on and _____ –
Shimel: Yep. And I think you’ve — Jonathan, I think you’ve hit that right on the head and that’s just what I was looking for, which is so many people, especially in the IT industry – I don’t know what it is about the IT industry, but we suffer from “shiny trinket” syndrome, right? Where everyone wants to latch onto what the new cool thing is. And the risk you run is that, when the luster is off of the trinket, people tend to start looking for the next trinket, instead of doing what makes sense for the business, what’s best for the business. You know, ’cause to my mind –
Fletcher: Yeah, exactly.
Shimel: Right?
Fletcher: It becomes a – go ahead. Sorry.
Shimel: No, no, go ahead. I’m listening.
Fletcher: Yeah, it becomes a little bit of a statistics race, like, “How fast can I get a release out the door? How many servers can one person look after?” And, actually, that’s fairly meaningless, unless there’s a business benefit behind it, so that sort of arms race to be the fastest becomes less and less relevant, so. And, as I said, DevOps is such a wide term now that it kind of – it’s just about doing IT better.
Shimel: Yeah. And that’s exactly it. I mean, Jonathan, to me, in my many, many years in IT and in business, there’s very few revolutionary things. There’s more evolutionary type of developments, right? And, when we look at DevOps, we look at the Agile that came before, right, and we see kind of where Agile is and its effect, but yet we still see plenty of organizations that are doing waterfall or some may call it “fast at waterfall” or “Agile waterfall” or whatever you wanna call it. But, you know, it’s a very – the inertia in our systems is such and entropy in our systems is such that nothing moves – we don’t move at the same speed across. And even something like DevOps, though you may have organizations that are now presenting for the third or fourth year at a DevOps Enterprise Summit, there’s still plenty of organizations that are still just starting on that journey, and they will be on that journey for many years going forward. And I think we lose perspective of that when we live in this bubble of “Who’s releasing the most often? Who did this first? Who’s on to the next thing?” That’s not who wins the game, necessarily. People who win the game are organizations –
Fletcher: Well, and –
Shimel: – and their customers. Go ahead. I’m sorry.
Fletcher: And some of these things are – all these things are less relevant, so, if you’ve got a system you’re gonna throw away in two years’ time, there’s – ROI to spend tons of time automating it and putting all that engineering in place with, you know, sort of – is kind of mothballed. So, again, it’s picking the right application, the right teams, to get benefit from this. I don’t necessarily see the – you have _____ all of these other _____ everywhere. Waterfall has its place. It’s about picking what is right for the business and getting the business _____ _____ _____. It’s not about a blanket “This is a right way or this is a wrong way of doing IT.” I just don’t believe that.
Shimel: Mm-hmm. I agree with you. And so, Jonathan, we’ve come full circle in our short little chat, but this is what makes DOES a great conference to attend. Right? Where we are hearing these transformation stories, and some of them may be old hat to some of us, some of it may be a revelation to others. Right? But it’s – the last part of this that I wanted to hit is that it’s, at the end of the day, it’s about the community. We as a collective community learn from each other’s experiences and these shared experiences, and that’s how we evolve and that’s how the whole movement moves forward, not just Hiscox, not just Disney, not just any particular organization, but as an industry, as a movement, that’s how we move forward. And then I think that’s what DOES is about.
Fletcher: Yeah, and that feels fairly unique. I can’t remember, in my 20-odd years of working IT, a movement with such a community feel, with so many people who want to help other people, and it’s – I think that’s amazing. And I don’t ever get – when I speak to people much further down the line than we are and they do better things then we do, I never get that looking down their noses or “You should be where we are.” It does feel like a real community sense of being, that everyone’s gonna help each other. And I don’t know what it is about DevOps, but I think that’s amazing, and you really see that at DOES.
Shimel: Yep. Absolutely. Jonathan, we’re about out of time here – probably, we’re over time – but, listen, I wanna thank you for joining us today on DevOps Chat. I look forward to hearing your presentation at DOES London and we’ll check in before then and get more of a final version of what you’re speaking about. And, also, I wanna thank you for being on the program committee. I’ve been on organizing in program committees of events in the past and I know it’s, in a lot of ways, an unsung job – you don’t get paid for it and God knows there’s ton of work that goes into it – so thank you for your service.
Fletcher: You’re welcome. Thanks very much.
Shimel: No, my pleasure. And, Jonathan, I’ll get together in London beyond that. Maybe we’ll catch up on a video or something. Hey, but continued success. I hope, by the time I see you in June, the interim title’s gone. They couldn’t find a better man or person for that job. All right?
Fletcher: Thanks, Alan.
Shimel: Cheers, Jonathan. Jonathan Fletcher, Hiscox and the program committee at DOES London 2017. This is Alan Shimel for DevOps Chats and devopsy.kinsta.cloud, and we’ll see you on another chat soon.
On the heels of our latest DevOps Enterprise Summit London speaker and programming announcement, I had the pleasure of being joined by Tom Clark, head of Common Platform at ITV;Andrea Hirzle-Yager, head of Department, IT at Allianz Deutschland AG;Mark Schwartz, CIO and author of “The Art of Business Value” and “A Seat at the Table“; and Mayank Prakash, Chief Digital and Information Officer at Department for Work and Pensions for a live video chat—already our third installment for 2017! We huddled up for an hour and took a “deep dive into DevOps,” as my fellow panelists shared keen insights into their technology transformation experiences and leadership lessons learned from pioneering DevOps adoption in their own organizations. And as you’ll find out, these are all such great people!
Clearly, one of the responsibilities of technology leaders in DevOps transformations is enabling a culture of continuous and lifelong learning. In fact, this characteristic is one of the more profound conclusions after having seen nearly 200 leaders share their stories over the past four years. And holy cow, if there’s a great time to learn, it is now; personally, I can’t overstate how much I’ve learned since co-authoring “The Phoenix Project.” (For example, in Dr. Steven Mayner’s DOES16 San Francisco presentation last year, he confirmed that this seems to be a critical element of successful transformation—you can see what we learned about the role creating a culture of learning and transformation plays in successful Agile and DevOps transformations.)
These were among several questions that I had to privilege of asking Andrea, Tom, Mark and Mayank.
What will you be presenting on this year?
What can you share about what’s happened in your own journeys since 2016?
What can you tell us about your DevOps journey and technology transformation?
Can you tell us about where you decided to start, and why you chose there?
It’s been observed that DevOps transformations are easier in smaller organizations—what are the toughest obstacles that you’ve overcome as leaders in your journeys?
What are your favorite lessons learned that you think would be applicable for all leaders endeavor in to do similar things in their organization?
What are your favorite resources you look to (past and present) for leveraging the best practices and principles—this could be in the form of research, books, events, articles, etc.
Can you share you impressions of your two days at DevOps Enterprise Summit London last year?
It was fantastic hearing the specific lessons they’ve learned in their journeys that they thought would be applicable for all leaders doing similar things in their own organizations. It was interesting to hear how books and conferences play such a critical role for them, as it has for me—and I always love getting a glimpse of the bookshelves of technology leaders, because certain books keep keep showing up up again and again
Be sure to watch the video replay of the chat—there are some great nuggets of information about where these leaders are in their own transformation journeys and what you as DevOps Enterprise Summit attendees can expect at the event this June.
DevOps Enterprise Summit London Update
Plenty has happened since our previous live video chat with Jonathan Fletcher, Cornelia Davis and Jonathan Smart. The programming committee has made its final selection of speakers to round out the conference program, and we’re in the final planning stages for the event this June. One item on the agenda that I am particularly excited about is the “Ask the Speaker” portion of the program. This year, we are opening up an hour of time each day of the conference for question and answer sessions between our plenary speakers and conference attendees. It’s going to be a great way for attendees to pick the brains of the folks just coming off of the main stage.
Additionally, we have added another format (tested during DevOps Enterprise Summit San Francisco last year) that we called “DevOps Workshops.” These are small-group discussions using the Lean Coffee format, with a small army of trained facilitators at each table.
We’re expecting a phenomenal turnout for each of these sessions and we’ll have some world-class people helping to lead the discussions. More to come on that soon!
Want to join us in London this June? Save 20% on tickets using code “DEEPDIVE20” today!
Snowflakes are beautiful, unique creations. But, let’s keep them in nature. They don’t belong in our server infrastructure. Snowflake servers, where every configuration is just a little different, can introduce unnecessary security vulnerabilities and complications. While common in IT infrastructure, in the DevOps realm, they are gradually becoming ancient history.
At the recent All Day DevOps conference, Erlend Oftedal (@webtonull), with Blank and head of the OWASP Norway chapter, discussed the benefits of immutable infrastructure practices within serverless architectures. Erland walked us through the positive effects on security as well as offered insight on potential problems.
Erlend outlined the progress from physical servers to immutable servers, discussing the benefits of each step and the concerns that lead to the next phase, ending with immutable servers—that is, they can’t be changed. Once set up, they are set. Automated processes coupled with immutability principles can eliminate snowflake servers.
Immutability isn’t a new concept. Some classic examples include: live Linux CDs, internet cafes, schools, libraries, hotel business centers, etc. To set up immutable servers, Erlend outlines these steps:
Find a suitable base image
Build a specific image for the application (dependencies, application, secrets)
Deploy image to server(s)
Repeat steps 2-3 for new versions.
Of course, this immediately raises questions.
What about data? He notes that, because data inherently changes, data has to be stored externally.
How do you deploy changes? Well, you don’t change the server. You take one out and put a new one in. If that one fails, roll back to the previous one.
How do you manage secrets? You can build secrets in, leverage cloud key management or use third-party services.
How do we apply security patches? If truly immutable, you deploy a new server with the patch. However, you can have a semi-immutable server that allows for automatically installing patches but still doesn’t allow for logins or manual changes.
Speaking of security, what are the security advantages? For starters, if an attacker is in your server, it will be thrown out when you change servers, although it may come back if the vulnerability isn’t patched. It also allows for very specialized images by removing all unneeded packages. With these specialized images, you can more easily audit and monitor the system for unexpected file changes, logins and connections.
Erlend discussed containers because they are a step closer to a serverless world. Containers isolate processes and all run on the same OS. Of course, you can make them immutable, but, whether they are or not, there are some key security best practices you’ll want to consider:
Don’t run as root inside container
Implement user namespaces so the root account within the container is separated from the root account outside the container
Utilize the least privileges necessary for capabilities and resources
Keep them up to date
Automate scanning using tools such as Sonatype Nexus, Twistlock, Clair or Aqua.
Separate untrusted and trusted containers
Erlend also dove into serverless architecture. While there is debate over what exactly qualifies as serverless, there are five principles that Erlend highlighted:
Use a compute service to execute code on demand
Write single-purpose, stateless functions
Design push-based, event-driven pipelines
Create thicker, more powerful front ends
Embrace third-party services
Migrating to immutable, serverless infrastructure is a topic to be discussed well beyond this blog post and even Erlend’s session. Whatever you do in the future, though, take his parting words to heart: “The cloud can solve many of your problems, but in the end you cannot transfer your responsibility for security.”
Erlend’s session was packed with information. If this piqued your interest, you should watch his complete session in his full All Day DevOps conference session (just 30 minutes). The other 56 presentations from the All Day DevOps Conference are also available online, free of charge here.
As adult learners and leaders, we tend to glean less from theory and seem to derive more from people actually describing the real-world problems they are trying to solve. Ever since the DevOps Enterprise Summit began in 2014, we’ve been adamant about providing a unique venue for the technology leaders of large, complex organizations to come together and share their DevOps transformation experiences—from how they started and what they did, to what the outcomes were and what they learned.
On the second video chat gearing up for DevOps Enterprise Summit London 2017, programming committee members Cornelia Davis (Pivotal), Jonathan Fletcher (Hiscox) and Jonathan Smart (Barclays) joined Gene Kim and spent an hour taking a “deep dive into DevOps,” to reflect on the first DevOps Enterprise Summit London last year. Panelists also shared some of their lessons learned and wisdom about their own DevOps transformation stories today and shared some of their favorite resources for leveraging best practices and principles while discussing the value of lifelong learning.
Just a reminder that Early Bird ticket pricing for DevOps Enterprise Summit London 2017 was extended to 22 March and the price is only £650+VAT. Register here >>>
All in all, it was an excellent conversation with Jonathan Smart, Cornelia Davis, Jonathan Fletcher, and Gene Kim as we all inch closer to the DevOps Enterprise Summit London this June. The goal (according to each of these people who are now on the programming committee for London) is to hopefully make the show even better than it was last year. We look forward to seeing all of you June 5-6 at the QEII Conference Centre.
Here is the video and a full transcript of the conversation below that. More links to DOES videos and interviews are down at the bottom. See you London June 5-6!
Gene: Summit 2017 in London. This conference is taking place on June 5th and June 6th. For more information on this, just go to events.itrevolution.com. I think what excites me so much about the DevOps Enterprise Summits is that there is just, no doubt in my mind, that the people who are presenting are the leaders and practitioners, who are pioneering how we’re managing and using technology in large, complex organizations. So on this Live Chat, we have Jon Smart from Barclays. We have Jonathan Fletcher from Hiscox, Cornelia Davis from Pivotal who’s also…In fact everybody is on the programming committee.
So my goal next hour is to have each one of you share what you’ve been working on, share some of your lessons learned and wisdom which is just, obviously, a fraction of what you’ll be presenting at the DevOps Enterprise Summit. So just one last reminder is that there’s an early bird ticket pricing that ends on the 8th of March, which is one week from today. So the next step is really to share what wonderful speakers that we have on the panel today. So let’s go around the table, and if each one of you could present your name, your role, company and, specifically what you presented on last year. Cornelia, why don’t we start with you?
Cornelia: Sure. Good morning, good afternoon, everyone, and, hi, Gene, and my fellow panelists. My name is Cornelia Davis. I am the Senior Director of Technology at Pivotal, and so Pivotal is a company that maybe is most well known for incubating the Open Source Cloud Foundry Project, and my role is that I work in the product organization. I work with clients and customers to take our products and use them effectively. Well, it turns out that our products are really disruptive.
It’s very different architecture and so they have to change everything. So that’s where DevOps and digital transformation comes in, is they actually have to in order to use our products effectively, they have to change organizational structures and you have to change processes. And I have this tremendous opportunity to work with very large enterprises across the globe, in then figuring out how that works for them.
Gene: It often can be very disruptive to the way we’ve done the thing for decades, absolutely.
Cornelia: Oh, yes.
Gene: Jonathan Fletcher, why don’t we start with you? I wanna go to you next and, by the way, congratulations. I hope you’re gonna tell us about your promotion, as well.
Jonathan: Yeah, so I’m Jon Fletcher. I am the interim CTO for Hiscox Insurance. Based out of offices around the world. I’ve been the CTO for a month, five minutes, it seems. So, it’s fairly new.
[Crosstalk]
Gene: Can we stand by a second? We’re having some audio issues. Let’s go to Jon Smart while we resolve that. Jon?
Jon: Hi, Jonathan Smart. So I work at Barclays. My role is Head of Development Services and I’m leading on better products faster, so better ways of working, adoption of agile dev ops, lean principles, and practices across Barclays.
Gene: Brilliant, and what did you present on last year?
Jon: Last year, I presented an Experience Report. So I gave an update of the Barclays journey across the whole organization. We started two years and two months ago, beginning in 2015, so last year, I gave an Experience Report, shared some of the lessons we’ve learned in terms of transforming a large organization. We are 130,000 people in 40 countries. We have 48 million customers.
We’ve got some main business lines such as the investment bank, retail bank, wealth, corporate. So we’re a very large organization, as I said. We’re 327-years-old, founded in 1690. Four years before the Bank of England existed so that’s a lot of legacy to change and it’s a large organization. So I shared our journey so far, and I’m looking forward to sharing an update this year, as well.
Gene: Brilliant. And I think one of the things that just left such an impression on me was just the scope of what you’ve been overseeing in terms of how many engineers and how many applications?
Jon: It’s 26,000 staff in technology and over 3000 applications.
Gene: That’s awesome, fantastic. Thank you, Jon. All right, Jonathan Fletcher, let’s go to you. Name, company role and what you presented last year, and you’re gonna to tell us about your promotion. And then we’ve gotta unmute.
Jonathan: I am the interim CTO of Hiscox Insurance. I’ve been in that position for about a month. So I’m not exactly seasoned, but I’m doing it so far. I’m really excited to be part of this and speaking in DOES in June. So I’m looking forward to that.
Gene: Awesome. And then you presented last year?
Jonathan: I did, yes. Sometimes it’s on our move to DevOps and a bit of my personal journey starting as a solution architect four or five years ago, and how I got involved, and how the whole thing started to happen, and I hope this year to carry on talking about that journey and where we are now.
Gene: Very good. Thank you. So why don’t we go to a little bit about the conference and your impressions on it? You know one of the things that many people have told me over the years is that DevOps Enterprise Summit is structured differently than most typical technology conferences that we go to. And I think many of us are, actually almost professional conference attendees. Would you mind sharing your impressions of your two days at the DevOps Enterprise Summit, London, last year? Jon, why don’t we start with you?
Jon: So what I really like about it is that it’s peer-based, so it’s people who are doing the job of transforming organizations and that’s what I like about it. It’s people sharing case studies, sharing their real experience so, you’re learning firsthand. It isn’t a series of sales pitches. It’s about people who are doing the job. Specifically in the horse is not the unicorns. I’m shy of horses, rather than the unicorns. People who are not born Agile, but are born Waterfall. So that’s what I like about it.
It has great networking opportunities, as well, with people who are going through the same journey. And also it’s interesting when you sit through a number of the case studies, you start to see the common themes emerging, and pretty much every single time, the main theme that emerges is it’s all about people. And often with DevOps people jump straight to the tooling and they don’t think about people and culture, often, but it’s all about people. So it’s great when you see these themes coming across from many different companies.
Gene: That’s awesome, and I’ll maybe just comment on that. I mean I think that’s one of the reasons that we choose very deliberately to have people share Experience Reports. Just because as adult learners, as leaders, we tend to learn less from theory. Instead, we learn from people actually describing the problem they’re trying to solve, what they did, where they started, what were the outcomes, and what did they learn. Jonathan, how about you?
Jonathan: I’d echo much of what Jon said, actually. So I like the fact that the very little of it is technical. So very people, focus, culture, process-based and I love being the least smartest person in the room. So it’s watching to learn from lots of other people. I think lots of DevOps conferences are very technical, although, they’re very at the beginning of the journey.
So being surrounded by other people that are at least where we are, if not further ahead. For me, it was a great learning opportunity and I can remember coming away reinvigorated about what we’re doing, and I guess hiring because you were pushing against people that, necessarily aren’t aligned to your way of thinking. So it’s just to get that we are doing the right thing, and we are going the right direction. That was really fantastic. So I really enjoyed those couple days.
Gene: Awesome. Cornelia.
Cornelia: Yeah, it’s all of those themes, but there’s some interesting…As you know, Gene, I work with you on the Programming Committee, have been in the U.S., and now this year in London, as well. I wasn’t at London last year, but we did something in the U.S. last year that we’re going to bring to London this year, and it’s really just an exemplar of what we’re talking about here. It’s a programmatic way of really fostering that peer-to-peer collaboration.
And so last year in the U.S., we did these lean coffees where we had this structured format where we got people together at round tables and had kind of a facilitated way of sharing ideas, and it was fantastic that the tables that I sat at, it was literally an hour-long period. And I think everybody at the table got three concrete takeaways of, “Oh, that’s a technique that I wanna try.” And so as you know, Gene, we’re talking about bringing that type of a format.
It’s not just conference sessions. It’s that type of a format to really foster that collaboration and that’s really very different from a lot of conferences these days.
Gene: Yeah, and I think both Jonathan and Jon will be joining the Program Committee starting this Friday. And I think one of our goals is, you know how do you create the conditions where those serendipitous interactions, how do you maximize the opportunities for the interactions that lead to learning, right? And part of that from a program perspective is we do both the talks, but also creating session formats like that. So one of the things that I’m just delighted about is that the conference will be featuring both Jonathan and Jon, again, sharing the continuation of the journey both at Hiscox and at Barclays.
What I love about this is it’s something that most conferences actually don’t…it’s actually quite unusual, right. But, for me, it seems like this incredible opportunity where we’re almost documentary filmmakers following these leaders, as they go through their own journey and we get to learn as they learn. So you’ll both be presenting for the second time. What can you tell us about what’s happened in your own respective journeys since you presented in 2016? Jonathan, why don’t we start with you about the Hiscox journey?
Jonathan: So last year, I talked about our starts with DevOps, and I guess the point of my talk was that I don’t think we’re really doing DevOps. We’re doing bits of Agile, and continuous delivery, but I think that’s really what DevOps is trying to solve. So there’s lots of stuff with testing in automation and application teams, but really I think the real nirvana is when we bring the Ops side into the equation. So in the last year, we’ve been doing a lot of stuff with cloud.
We’ve been doing a lot of stuff with talking around how we move to a more Agile operations team, rather than a sort of ticket-based system and doing projects in a Waterfall way. So trying to get some of those concepts that we’ve learned in an application mode into the operations teams, and the challenges of doing that, and how we get those two linked together so we can minimize and help the flow of feedback that goes through development into operations systems. This is the final bit of that journey, I guess.
Gene: And you could you talk a little bit about how the change in your role, maybe even going back, I mean how do you think the work that you did in terms of pioneering some of those practices at Hiscox, how did that lead to your change in responsibilities, and how does your change in responsibilities allow you to do more or less going forward?
Jonathan: So I started as a Solution Architect. So actually nothing to do with DevOps at all, and it was kind of just was born out of frustration. I was like, “We’ve gotta change the way we do stuff because this is daft.” So it’s coming in with a great new focus which, again, most DevOps translation started quite small which we got an application, and we did some automation around it, in terms of scale and CD and some automated testing. And then we saw these successes of that and went towards something else, and then it’s just kind of ballooned over the years. And, I guess, we’re really starting to see some of the business payback for that and that’s helped me.
I get more visibility to be seen as someone that’s trying to be more strategic, in terms of how as an insurance company we maintain a competitive advantage. And I think that this step to CTO is sort of the logical conclusion is to help to see that journey through. It’s helped me because now I’ve got a lot of guys rather than influencing up the chain over time, but other peers of mine are direct reports so that that’s gonna help…not that it’s a dictatorship. But it’s going to help my influence and ability to do that, as well as having own budgets and ability to spend some money on that.
Gene: By the way, conclusion sounds so terminal, Jonathan. Let’s not hope that’s the conclusion…haha!
[Crosstalk]
Gene: A continuation perhaps.
Jonathan: A continuation, yes!
Cornelia: I love what you said about Agile operations team instead of tickets. So instead of tickets, it’s so huge. It’s such an important part of DevOps, and it’s all about empowerment, right, but empowerment still in a safe environment.
Jonathan: Yeah, absolutely. I love that. And I think there’s a technology problem there as well. I think it’s very difficult to align the types of tooling that develop as you’re using along with the ops guys that also want to have things like, ITIL based processes and a change management database, and trying to get that transparency across the whole value stream is quite difficult. So that’s one thing I’m kind of wrestling with at the moment.
Gene: That’s great. Jon, how about you? Yeah, what has changed in your journey since you presented back in June?
Jon: So knowing why you’re doing this is important. So why is any company doing DevOps, adopting DevOps and why are active products faster with delighted customers and colleagues, better, faster, happier, safer? And so taking a broader definition of DevOps, in terms of better product, faster, safer, happier we’ve increased our adoption across the organization. As I said, we’ve been doing this across the whole firm for two years and two months.
If you go back two years and two months, it was a relatively small percentage of our change work was done with these practices and principles, and now we’ve got a fairly significant percentage of our change work now being done with Agile and DevOps and Lean principles. So in 2016, we’ve carried on that at-scale adoption, and we have done it apace. We have something like, rough order of magnitude, something like 15,000 people who are now working with Agile and Lean principles, and practices who weren’t two years ago and important to get the ball rolling.
It’s important that we do it with control in a highly regulated environment where as we know the impact of attitude is significant. And so we’ve also been focusing on control because we want both speed and control. Sometimes people might think that you can’t have both speed and control and people might think that speed is at the cost of control, but actually, it’s quite the opposite. You can do anything badly. You can do fragile or you can do Agile, and actually an Agile approach and a lean approach increases control. So we’ve been putting quite a lot of effort in 2016 into control, as to both we are balancing by speed and control.
Gene: Cornelia, you had a question for Jon.
Cornelia: Yeah, I do. So, I thought it was very interesting that you said it’s been two years and two months. So that’s a pretty specific date/time period. What was the catalyst? What was the starting point? What defines as two years, two months as opposed to roughly two years ago? Was there a specific event?
Jon: Well, maybe I’m speaking from my personal perspective. It’s roughly two years. It’s roughly two and a half years and, specifically, what any organization needs to do this successfully, it needs both top down and bottom up. So the specific event, this was a catalyst, in our case is with new leadership and new leadership saying, “Agile and lean is the way to go,” and then the natural champions in the organization, like myself, we put our hands up, “We volunteer to help move the needle.”
Gene: Okay. I mean so in other words, this signal of support from upper management is kinda what you mark as the real start of the journey, right, where it was now a sanctioned, important activity.
Jon: And it was articulated, formally as part of our strategy, yes.
Cornelia: And that is something that I see across, again because I get to see across a lot of different enterprises that are all on a similar journey and that’s not at all unusual. When we have new leadership that comes in, sometimes new leadership that’s brought in, specifically to shake things up, that is often kind of the defining moment where things start to change.
Jon: Yeah, and like I said, absolutely, mandatory criteria to be successful across and organization, you’ve got to have that top down support, as well as the bottom up community. You’re gotta have those two things.
Gene: By the way, I love the number that you put out, in terms of 15,000 engineers working with Agile principles, just to calibrate. That’s actually the size of the Google engineering organization in 2013. So it’s just amazing to see what happens when you can elevate the productivity of engineers that it’d impact that many people. Jonathan, you had a thought.
Jonathan: Yeah, Jon, I was really interested, you were talking about control. Barclays is a fairly massive beast. I was thinking with your move to Agile. How did you have that control at the scale that you’re operating in? I mean lots of Agile teams work very much, almost as a silo, themselves. They’re in back of their work how to orchestrate such a large transformation in such a large company.
Jon: The main principle has been to start with what we have now. So we clearly are operating in a highly regulated environment. We’re not starting from a clean sheet and working towards what we have. We’re starting with what we have and we’re iterating to improve control effectiveness. A starting point was a Waterfall lifecycle, and I’ve spoken about this at the last DevOps Enterprise Summit. We had NT8 mandatory artifacts, many hundreds of questions, and it was a very un-lean process, and it was evolved over time, multiple input, probably from multiple audits and multiple control findings, and so on.
But it became really catered to the lowest common denominator, but applied to everybody. So what we’ve been working on is improving the control effectiveness and leaning the process. So it’s more as a greater risk sensitivity now. So if you’re doing something which is, say, for example, an internal system, nothing to do with payments, no client data, it’s purely…I dunno…a seating map, for example, then it’s risk sensitive. So the controls that will apply to that are in line with our control framework.
Something that is to do with payments, some has client data, the control implications are much higher. The main thing is it isn’t a lowest common denominator for everybody. The thing is applying Agile principles, we’ve moved it to be more of an early and often conversation with our control professionals. So, previously in a traditional manner, you deliver something and we had a control engagement at the end, just before you’re about to put it into production.
And then that leads to another three months to six months of unplanned work, in a reactive manner is what we observed in some cases. So instead we’ve got long-lived controlled tribes, multi-disciplinary long-lived association with the customer value stream, and then you have a conversation at the beginning, and you have regular small conversations as you go, so there’s no surprise at the end. And there isn’t an end because it’s a long-lived product with regular deliverables.
Gene: That coincides with the regular audits that happened, right, the compliance reports. That makes a lot of sense.
Jon: Exactly, exactly. Exactly, the control effectiveness is stronger because you’ve got that regular interaction and the regular looking at an actual product that you’ve actually got something tangible to look at.
Gene: Just as a little side note that we have a group and, hopefully, you’ll be joining us, Jon, from MarkSoft, Capital One, and others, just really trying to help bridge that gap with compliance professionals using their terminology, using the design control effectiveness language, really to show that you know DevOps people aren’t crazy. In fact, you end up with better control effectiveness working all the time. So that’ll be a very fun interaction. I’m very excited about that deliverable.
Jonathan, one of the themes that have come up here is that wonderful things happen when you’re surrounded by fellow travelers who are facing the similar types of challenges and kind of the learning that can ensue. I actually had the privilege of observing one of those sessions that you and I were talking in, and you had a conversation with Scott Prugh who’s the VP of Development and Product Operations at CSG. They’re one of the largest bill printing companies in the United States, and the topic was how do you overcome some of the traditional challenges, how you get more traditional IT operations organizations on board. Can you share some of the challenges that you’re grappling with and some of the insights that came out of that conversation because it was absolutely amazing to observe?
Jonathan: Yeah. So in terms of our org structure, Hiscox a fairly federated business. So we have a number of British units aligned to countries around the world. Application testing teams tend to be aligned to their business units, but operations infrastructure is a group resource that delivers against all of those operations, all those departments. So what we’ve been wrestling with really is how do we or do we maintain that? Do we align infrastructure operation teams to a particular country or do we continue to measure out of a group resource? And if we do that, then how on earth do we have a backlog where we’ve got so many different stakeholders with different requirements, different projects?
And how do we prioritize amongst all those different business units and how do we still get projects done? How do we still get BAU done? I guess the questions that any Agile team has, it’s just on a much grander scale. So each business unit is operating independently. I don’t really care what some of the other business units are doing as much as it’s about their P&L. They want to first bust at the cherry. So does that mean then that BAU goes off to the side and we stop patching because there’s continued focus on projects? So there’s some of the sorta challenges we usually went over with Scott.
Gene: Yeah, mute button. And what was just some of the insights that you had or at least, maybe even validations of the problem? Specifically, how do they inform your thinking?
Jonathan: So I think what was quite interesting is listening to Scott’s talking about visibility of work in progress. And some of the frustrations there are between development operations is because both of them are almost black boxes. So a developer might say, “Look, I need an environment and it might go into a ticket system” and it goes from the server guy towards the SAN guy, and the storage guy, and it goes around in little circles.
How can we let the developers know what the ops guys are up to, and conversely, how do we let the ops guys know what developers are doing? So how do we get that work-in-progress highly visible and that, as a starting place, would be a good way of beginning to address some of the prioritization issues because they’re working off completely different backlogs. The left-hand does not know what the right hand’s doing. How do we start to make that happen? So that was a good sorta first head’s up from him, just to go and look at that problem.
Gene: All right, in fact, I think he’s spoken a lot about trying to get more and more of the ops work into the same work systems as development. So in their case, it would JIRA, and so forth, and less the remedy and so forth, right, just to have a single prioritized work unit.
Jonathan: Yes, but that’s pretty hard. And who’s gonna be a natural tendency for projects to trump everything else because that’s what a business is asking you to do and we’ve gotta change out the door? But you still need to make sure things are patched, and security’s done, and I really like that sort of conversation where you start to allocate points in a sprint, so that’s BAU and that’s projects. If you don’t do that it becomes a very difficult way to triage and prioritize stuff that’s coming because like BAU is gonna be on a loser.
Gene: Cornelia, as coming from a development background, I think you’ve observed something very similar in your journey.
Cornelia: Absolutely. And one of the things that’s really interesting that we found very effective is to take the same product-oriented mindset that the application teams have when they’re building and delivering their products, and actually have that same mindset at the operations and at the platform level. So that, instead of it being treated as just unplanned work, work that comes along, now it comes in, we have to prioritize it, they start to treat their offerings as products themselves. So that they do things like measure…they have a backlog of additional features that they wanna create.
They have release notes that say, “Hey. We’re patching the system on this day” or “You have the opportunity to apply your patches because the patches are queued up and ready to go.” And so really shifting that product mindset, all the way deep down into what’s kind of traditionally an infrastructure kind of role that tends to be a little bit more order cook-ish, and really transforming that into a menu-driven, “Here are the offerings that we have.” Of course, you can’t get rid of all of it, but that’s really, really powerful, is a product oriented mindset, even at that deep infrastructure level.
Jonathan: I think you’re entirely right. I think the mindset, yes, I think the practical application is more difficult. So if you build an environment, for example, you need a server person and a SAN person, and a storage person, and there are lots of techology-silos. So what isn’t very practical is go and take all of those resources, and go and stick them in a dev team because your Agile team’s gonna be 400-people strong all of a sudden which is not ideal. So I think I get the mindset implication or, I think, the technical implementation of that, I think is a bit harder.
Cornelia: Yep.
Gene: Jon, I can’t imagine that somehow Barclays is exempt from some of these issues, as well. I’m guessing that this has relevance, at least in some areas of the organization for you.
Jon: Yeah, absolutely. This really resonates. I think if you go back and my own personal experience, you go back about 20 years ago and, specifically, that’s when banking, we used to do all the roles. I was a developer. I did the analysis. I did the development. I did the support, and I sat next to the customer or the partner and we did everything, and over time, we’ve gone from a role specialization and the split between kinda ops, run, and build, dev. And so, yes, this absolutely resonates.
Generally, for Barclays, coming from a generally Waterfall approach prior to two years ago with islands of Agile, I’m looking at this topic, we’re looking at how we get closer to you build it, you run it. But still maintaining regulatory compliance around segregation of duties, Sarbanes-Oxley Compliance. But as we’ve discussed, the run specialists, the operational specialists, utter the feedback with the build and the dev specialists need to all be lined up behind the customer. And, obviously, what happens when you’ve got operations, you’ve got run who are working in their own world.
The feedback loop never gets back to the dev team, so developers need to feel the pain. I like the SRE Site Reliability engineering philosophy of hiring engineers into ops roles because when you put engineers into op roles, things tend to get fixed kind of at the root cause, rather than a band-aid, rather than a short-term fix. So we are absolutely this is a high priority for us, especially in 2017 to try to increase the feedback, and get more to being one team. But to Jonathan’s point here, we can’t do that with everybody in every role. So yeah, there’s going to be the product teams and there’s going to be secondary teams, and that’s absolutely something we’re trying to move the needle on.
Gene: Jonathan.
Jonathan: Yeah, I think when you start, I think, cloud for us changes that. When the infrastructure guys start to use the same processes, and tooling, and approaches that the developers do, then I think that becomes a lot easier. So I’m trying re-push infrastructure as code at the moment, and I think that is the way of really breaking it down. If infrastructure is just another software project, that becomes really easy to put into that Agile team with the application team. If you’ve got a mix of traditional, “I’ve gotta go and plug a server into a wall. Then I’ve gotta go and configure this” that doesn’t really fit in with a normal Agile team.
And you’ve got a guy was talking to me earlier, he wants to order new servers, six to eight weeks, and then we’ve gotta go and get finance approval for it and. “I think I’ll do this.” That’s not gonna fit in that tight feedback loop that Agile’s trying to work with. So, for me, it’s about transitioning some of the infrastructure skills into more software-led skills, and that’s where you’re gonna get that much closer alignment. That’s where you’re gonna get the DevOps cultural start. That’s where it is. I think trying to do in on-prem, in a manual way is kinda of a bit of a recipe for disaster.
Gene: I think the best people that really embody this is Jason Cox from Disney. His title is Senior Director of Systems Engineering at Disney and he’s talked tirelessly about how he’s tried to create, embed those ops, talent and engineers into the lines of business, into the dev teams, really helping them do things on-demand, and it’s been amazing to see his own journey over the last four years. Just a little joke here.
You talk about infrastructure is code, Jonathan, I love how Scott Prugh from CSG, he said, “The ops of that is infrastructure’s tickets” which is actually what we don’t want, right. We want those on demand. Let’s go to Jon, and one of the just tantalizing pieces that you had talked with us there at Prep Call, just before this panel was the Lean Portfolio Management work that you’ve been doing and how that’s become your newer areas of focus, and I think all our ears perked up about that.
Because of I think this realization that all of us have had over the years, is that you can have fast iteration loops within the dev test operations stream, but if you have an annual budgeting cycle and annual planning process, that really sets some very hard limits on how Agile you can be. Tell us about what you’ve been working on.
Jon: Yeah. So, as you say, we can have as much agility as we like. We can be practicing DevOps. We can have great continuance delivery, but it’s a local optimization when you look at the system, think a system’s thinking and a theory of constraints to deliver better products faster and with delighted customers and colleagues, it’s gotta be end-to-end agility. And so I think this is a natural evolutionary thing, having made some pretty progress, I think in the last couple of years, in terms of how we do what we do.
As we start to expand out in the theory of constraints, look at what the next constraint is. As a large, complex organization, we’re starting from the position of annual planning and annual budgeting, and that doesn’t give us enterprise flexibility as much as we would like. So this is a focus for 2017 for us, is to move to more of a courtly rolling wave type approach, more of a hypothesis-driven investment approach, more of a focus around outcomes, not a predictive plan. So once a quarter you said, “This investment should have achieved these outcomes. Has it?” And being able to build more agility into the system of work holistically.
Gene: Yeah, Jon, I’m dying to ask you. So I think the way I was trained there’s kind of two planning processes, right? You have the project budgets, right, which are owned by the business which tend to be…they can go up and down quite quickly. Whereas then you have the annual shared services budgets, right, where you tax every person, right, 2% of revenue or whatever, and then you a create work queue that’s prioritized, and maybe it’s not a good year now, maybe you’ll get it next year or the year after. So has your focus been primarily on the project on the business side? To what extent can you translate that to shared services?
Jon: So, that’s a good question and I think a caveat to what I said, as a public-listed company, we will still have an annual process. What we’re trying to do is we’re trying to push the courtly rolling wave, portfolio-management process as far…We’ll start at a certain point in the organization and then we’ll try to push it as far up the organization as we can. So that, basically, within our budgetary constraint whether it’s a business investment, you used the word project, whether it’s a business investment or whether it’s a shared service, irrespective of that, you treat it, your budgetary constraint, it is a constraint, and you wanna maximize the value on it.
So you would do it, you know my view is that we do it in both because, as well as about financial flexibility and being about to move money around, it’s also about de-risking delivery and getting away from the sum cost fallacy for a shared service. You know, “You said you’re gonna achieve this and, of course, this year, here’s this big chunk of money.” Naturally, “Have you achieved it? Are you going to slowly?” You know, “Can you cut the value chain? Have you delivered your value? Can you stop early? Can you pivot?” So it kinda serves multiple purposes.
Gene: Just a joke. I mean I was actually having a startling conversation with a friend of mine who was saying that they’re a publicly traded company and there was this sorta zombie operations project that they had depreciated over five years, and they couldn’t kill it because that would actually create a material change in the financial statements. But everybody knew that such a $7 million in a right world, we should just admit that it didn’t work. Kill it, so we don’t have to prop up this fallacy of a services actually running when it is not running at all. Does that resonate at all with you?
Jon: Yeah, it does. You know what we’re trying to avoid happening is exactly that kind of that sum cost fallacy and looking at a traditional approach, I’m sure we’ve all seen large initiatives which have that got multi-year sum cost fallacy that hasn’t delivered, but we’ve already spent so much money on it, we’re gonna carry on spending money on it.
Gene: Just to add color to that story. So they actually had this annual ritual where they’d have to run one transaction through it, just to prove to the compliance people that it is still operating, and so therefore, still eligible to be depreciated which is a shame. Jonathan Fletcher.
Jonathan: Jon, I love what you’re trying to do with that. It sounds fantastic. My question to you is are you forever stuck in writing businesses cases for return on investment? Does that slow the process down?
Jon: Hopefully not. You know we’re taking a lean canvas approach. So it’s not in the past in a traditional approach, you might have had to fill in a PID project initiation document which might be multiple pages long. We’re trying to keep it lean, so we’ve got a one-pager, lean canvas. You’ve got all of the information you need on that one-pager. Again, it’s conversation over contracts. That should be sufficient to have the conversation in terms of, “Do we feel this is the right way to go?” You know we might need to see more evidence. We might need to see more feedback from a proof of concept or experimentation or a customer focus group. We’re trying to keep it lean with this one-page lean canvas.
Jonathan: And is there a maximum budget that you would go with that project? Would you spend a $100 million on a one-pager?
Jon: We have a tiered approach and the tiering is the seniority of the people making the decision.
Gene: Conversations over contracts. I love it. So I’d love to know from each one of you, what are the favorite resources that you go to for finding your inspirations, practices, principles? I imagine this could be in the form of books, events, articles, research. Jonathan, would you mind sharing kinda what books are you reading these days that you’re finding most useful in your own daily work?
Jonathan: You looking for a plug, aren’t you Gene?
Gene: No.
Jonathan: All this here is homework. I think conversations of this kind of thing helps me immeasurably. So there’s this stuff you can get in theory, but it’s real world, practical, “I did this and it failed, and I could have approached it differently.” That’s where I get a load of value and I think just talking to people and getting out into the community. The DevOps community’s great at sharing information. Unlike like any other part of the [inaudible]. So I think people are always really generous with their time. So, for me, it’s not about reading papers. It’s about talking to like-minded individuals and the ones that are honest and go, “You know what? We tried that and it was a terrible mistake. Don’t go down that route.” That’s of much more benefit to me.
Gene: Great. Cornelia?
Cornelia: Yeah. I think a reason that Jonathan makes that point, and I can’t argue against that, is that we are still as an industry pretty early on in this journey. And somebody brought ITIL earlier and sometimes ITIL kinda gets a bad rap. But the reality is that ITIL is something that emerged over years, decades as kind of the codification of the best practices that we knew at the time. And when I was in college I learned about the Waterfall Methodology. That was the best practice at the time so, I’m dating myself, right?
Thirty years ago, in Computer Science Education, they taught us about the Waterfall Methodology and that was the state of the art. We created all sorts of practices around that. We created the books, the standards, and so on, and so we had a bunch of resources to go to. So when somebody was setting up an IT organization or evolving it, they had the manuals to go to and say, “Ah, here’s the codification of the best practices of the day.” Well, I think we’re still so early in the DevOps journey, not super early days because we’re seeing these fantastic success stories, but we don’t have the ITIL of the next generation yet.
So it’s hard to say that this is the go-to manual, this is the Bible. It is really about events like this, and it’s about, I, personally, I’m somebody who, when I’m on the treadmill in the morning, I watch videos, and I’m a propeller head, so I watch a lot of the tech videos, you know purely tech videos, but I watch the videos from previous events. Those things are incredibly insightful and really useful.
The DevOps Enterprise Summit, obviously, is just a fantastic event, but then there’s also what I consider more the grassroots events, like the DevOps Days which are not quite as focused on strategy, but definitely are focused on sometimes very pragmatic, very specific techniques and tools that are being leveraged. You need to bring that together with the high-level strategies. So it’s really still the community, but the good thing is that there’s lots of places to engage in that community.
Gene: Awesome. Jon, how about you?
Jon: So I think what Cornelia said that really resonates in terms of being early days, it’s not early days for Agile and Lean principles, at least in the 1980s, if not earlier, however, what we are learning is doing it to scale, and it’s been at the team level. It’s known at the team level. It’s not known at the enterprise level and so this is where a lot of the learning is. It’s, “How do you do this at scale?” And I’m not referring to scaling frameworks, necessarily. It’s more messy than that. It’s culture change. It’s behavior change. It’s involving everybody in the value stream. It’s not just technology.
Just technology is a local optimization. It’s everybody in the value stream, and we are learning, and this is a new way of working. This is a fundamentally new way of working for organizations with tech or without tech. I don’t know if this right term, but it’s like the fourth Industrial Revolution. We’re going from a tailor-ist way of working from the Industrial Revolution to not just a handful of firms working with multidisciplinary teams with long-lived products, and long-lived value chains, and fast feedback and fast learning, but entire organizations, and entire organizations trying to change how they do HR, how they audit, how they control, how they do portfolio management is a part of that, but it is a part of it.
So we’re absolutely early days. It’s a new way of working. It’s a more engaging way of working. It’s a happier way of working, and at things like the DevOps Enterprise Summit is where we come together to share on this learning. You know the question was, your question Gene was, “Favorite resources for learning…” so another really good forum which is quite similar which is around peers sharing is the SD Learning Consortium, sdlearningconsortium.org and it’s a community. It’s not commercial and we have a number of large companies sharing this journey and that’s where I get most of my learning from, as well as Twitter, as always lots of great content being tweeted.
Gene: It’s so true. I think six years ago I would have laughed at you, but just as a little side note, many people might not realize that one of my reasons for tweeting is actually too, is my mechanism recording things because, ultimately, of course, you’d actually write things down. Awesome. Jonathan Fletcher, you had a thought.
Jonathan: Just to add to exactly what you guys were saying. There’s next to where I work there’s a brand new building being put up, and I find it fascinating watching that process go on. So they’re damming in the foundations and from our floor, we can see right down to the foundations and see the guys that are working. And I often think of a parallel between a building and what we’re doing. You know IT is 20-30 years old. These guys who are building buildings since the pyramids, and they know what all the things are gonna happen, and they know the tolerances of the steel.
They know how much bricks they’ll need. They know the amount of concrete they need, and they know what order it has to go up. They know they need Planning Commission 1, 2, and 3. They don’t need to get halfway up the building, commonly knock it down and start again. And I think we should strive to get there in the future. We’re actually this is a common and understood journey and there are artifacts, and processes, and cultural norms that we can call upon, and I think this is the revolution that Jon was just talking about we’re going through now.
We’re trying to work out what these things are, and I guess I have one part which becomes routine. This is the university course of the future. I’m exactly the same as Cornelia. I can remember my sophomore engineering course and they’re talking about the silo model and Waterfall and this and that. That’s how you did it. So I think we go through that process now and I’m looking forward to that becoming more formalized and recognized, I think.
Gene: Fantastic. And love this, you know as you were reflecting on this, I was thinking about this quote that I think about all the time. As someone once said, “You’re only as smart as the average of the top five people you hang out with,” right, and so that is learning only happens when you’re hanging around people that you actually learn from, right? So that’s something I think about a lot. So we are all lifelong learners, now more than ever, at least for me.
I can’t tell you how many times, it’s difficult for me to overstate how much I’ve learned. I mean it’s just I’ve learned so much, even since the Phoenix Project came out 2013. I’d love it we’d just maybe go around the panel and just share one lesson that you’d like to share with everyone that you think it has significance and importance to everybody. Cornelia, let’s start with you.
Cornelia: Yeah, so one of the phrases that has really resonated with me as of late is this notion of radical curiosity and really just being continuously reminding myself that everything that I’ve seen so far is just what I’ve seen so far. And so I find my best days are the days where I get to talk with folks, where I get to ask the questions. I like to ask questions a whole lot more than I like to talk about things because it’s there where you get those insights. Even just this conversation for the last hour has just been the best part of my day and it’s only 8:00 o’clock in the morning for me.
So it’s really about asking questions and not falling into the trap of, “This is the way we’ve always done things.” I remember somebody asking somebody about how they do their firewall rules, how they determine what those are or how they secure something. And they said, “Well, we set the firewall rules.” And I was like, “No, no, no. I asked you how you secure things.” And it was all about the firewall rules. So it’s reminding ourselves and that we all fall into those traps of we have the solution, and we forget what the question is. I think that’s my answer.
[Crosstalk]
Gene: Yeah, that’s awesome. Jonathan Fletcher.
Jonathan: This is kind of a heavy thought for 4:00 o’clock in the afternoon. I think just that I’m really not the cleverest person in the room, and to keep an open mind about what others are telling you. Because as Cornelia says, this is a changing and evolving thing. People are reshaping IT and you know you don’t have to be the smartest person to pick up on some of this stuff. This is a movement and a cult of change that is happening, being able to set out some of these ideas and the Jez Humbles…All we’re doing is sort of following behind and listening, and picking the good bits and implement ourselves. So we’ll copy other people’s ideas, I guess, but that helps me get to where I want to get to. So just recognize that you’re not the smartest in the room, and just take the lessons that others have set out for you, and learn from them and move forward.
Gene: Perfect, love it. Yeah, one of the people I admire is Martin Fowler and I think he wrote kinda somewhere about his role, and he calls himself the best dumpster diver of other people’s ideas. I thought that was actually lovely beyond words. Jon Smart.
Jon: So in terms of a learning for me, I think in terms of culture change, an org change at scale, it’s going from, “I believe it when I see it” to “I’ll see it when I believe it.” So, you know I only really see it when I believe it and you to actuate new behaviors. So what I mean by this in terms of culture change, it isn’t about just going in there and saying, “Think this way” and trying to change the thinking. People need experience. People need to experience it, and actually you need to change the behaviors to change the thinking, to change the culture. I’ll see it when I believe it. That’s a learning for me.
Cornelia: Brilliant. That is brilliant. I love it.
Gene: I love it as kinda I’ll force it into being by sheer force of will. I love it, from Jonathan Smart. Fantastic. Well, to Jon Smart, Jonathan Fletcher, and Cornelia Davis, I’m so grateful that I spent an hour with us, and I know that your time is exceedingly valuable. You’re working on incredibly important things. I can’t tell you how much it means to me that you spent an hour with us, and for this hour, I hope that everybody else got as much value and delight as I did. So thank you, again. Now you’ll see more from us about the DevOps Enterprise Summit program as it shapes up.
Again, all three people here are part of the Programming Committee, and our goal is really to make that even better than it was last year. So I look forward to, hopefully, seeing all of you, on June 5th and 6th in London at the QEII Conference Centre. And, of course, an amazing venue in the center of Westminster and the center of London. You’ll see all the updates online at events.itrevolution.com, and again, early bird tickets end the 8th of March, so be sure to register as soon as possible. So with that, thank you so much and I look forward to seeing all of you on the Programming Committee calls or rather on the panel, and stay tuned for more updates. Thank you, again.
There you were. You heard about Docker, become mesmerized, floated into its new, special world … and then all chaos broke out. Things were not that easy and you scrambled for knowledge. Some folks saw the light and stepped forward, while others are still trying to figure the out the happy path home where containers will become part of their new ordinary.
This is the true story of Daniël van Gils (@foldingbeauty), a developer at Cloud 66, and the 12 steps he laid out in his Docker journey. He shared this journey during his presentation at the recent All Day DevOps conference, and I’ll share a summary of his steps here. His journey will take you full-circle, from your “ordinary IT world” to the “very special container world” and back, to where the container world is the new ordinary.
Containerization continues to be a hot topic in the software world, and one that is only going to grow and mature. As it matures, questions still abound:
How can you implement containerization into your organization?
Have you already started but run into roadblocks?
How can you be the hero of your organization’s journey?
Daniël addressed this journey in his talk, “Docker Inside/Out,” at the recent All Day DevOps Conference.
Daniël’s journey started in the Ordinary World (#1), the world you might be in now. You are at a conference, you read a book, you talk to some colleagues and you want to jump into containers. You receive the Call to Adventure (#2) … but you are human, you like the safe, you fear the unknown, so you want to Refuse the Call (#3).
Thankfully, others—including Daniël—have taken the journey. They can take you under their wings, coddle you and then push you out of the nest. You Meet a Mentor (#4) and follow your heart. The heart is the good stuff—it is the core. Like most people probably would have, Daniël chose an artichoke to illustrate his point.
The heart of the artichoke is the good stuff, but the outer leaves protect the heart and make up the whole artichoke. Each aspect of an organization has something that drives them—their heart:
Development – building elegantly performing code
Operations – stable, performing code
Business – delivering the right services to customers
Customers – consuming the service they want
Your drive to satisfy the heart’s desire gives you the courage to Cross the Threshold (#5). You have a containerization machine, such as Docker. You put code in, creating nice little containers.
Now that your infrastructure is set up, you test and know where your allies and enemies are (#6). The most important lesson here is that shortcuts are your enemy. Shortcuts are evil, promising a life of ease but delivering a life of pain.
Daniël offers his Approach (#7) through the Docker journey to ensure you’re successful. You must KISSSSS:
Keep It…
Slim – remove what you don’t need
Secure – ensure you have the latest updates; remove all secrets
Speedy – Follow best deployment practices and run performance tests
Stable – Use version numbers for your Docker files
Set – Immutable. Don’t put databases or complicated volumes into your containers. You can, but the the technology is still too new.
The next steps in his journey cover Ordeals, Death and Rebirth (#8). Once you pass this point in the journey, you’ll understand what it takes to run Docker in production and have shown the proof of concepts. You’ll then reap the Rewards (#9) and have clear visibility to your Road Back (#10) to the new ordinary.
For the successful heroes on this journey, now is your moment to shine. The next steps: your Resurrection (#11) and to Return with Elixir (#12) where containers are now the new ordinary.
If you want to learn more about Daniël’s Docker journey, be sure to watch his full All Day DevOps conference session (only 30 minutes). The other 56 presentations from the All Day DevOps Conference are available online, free-of-charge here.
This blog series is reviewing sessions from the All Day DevOps conference from November, which hosted more than 13,500 registered attendees. Last week I discussed, “One Team, 5,000 Jobs: Life in the DevOps Jungle.” Next week, look for “Launching Products at Massive Scale: The DevOps Way” presented by Kishore Jalleda and Gopal Moore.
