Share: |

Since witnessing the repetitive trainwrecks Agile adoption can cause to the Ops folks in the House of IT, I've been primed and ready for DevOps. I bumped into the DevOps term -- beginning of 2010, at the start-up StreamStep -- my head and my heart told me this was huge idea, a concept for something that previously was inchoate.


First off, Agile is a huge change, yeah but let's keep this strictly at the business level. It transforms the risk a business takes on when it goes to deliver new product, update or enhance existing product, or maintain product. It takes the executive gamble from "bet 18 months and potentially the company's future to get a kickin' product that comes out a year and half from now" to "incrementally improve your product in a stepwise fashion in short, iterative bursts that enable you to do stepwise refinement and check it all, in cadences as short as 2 weeks or less." Oh, and you no longer need that crystal ball that tells you the future state of the world when that app was going to come a year and a half from now. Agile lets you "ready, aim, fire" repeatedly in quick bursts. If you were the executive, you pick. No brainer, right?


But . . . the business still gets blindsided. Agile is a half-baked IT transformation because it's weighted solely on the Dev side. Outside of you and me, the rest of the world sees Dev as IT as much as it sees Ops as IT. Don't agree? You know Jesse Robbins' famous Amazon example where Ops got penalized for app downtime while Dev got bonuses for delivering the downing app on time? That means even Amazon sees it as IT. (You can call it "engineering" or use an umbrella "development" term or whatever you prefer; I'm sticking to the point regardless of the local vernacular.)


In running the DevOps Leadership Series, I've had the opportunity to interact with the luminaries and doers in the space and I've finally getting a handle on why I think DevOps is bigger than the "gap" between Dev and Ops. It was sparked by something John E. Vincent said in his interview (coming out soon). DevOps is about more than tooling (man, wind me up and I'm rolling on that topic). It's a fad only if you consider heart disease a fad. We may not forever use "DevOps" but the word works for me and we do need a word for it.


I ran this past Gene Kim and Clyde Logue over some great sushi last night and they seemed to think I had something here. The epiphany goes something like this:


Agile restores the business'  faith in Dev while DevOps restores the business'  faith in IT.

Share: |

Rugged DevOps.gifAs the discussion around DevOps has been advancing forward, most of the discussions have been about pushing code faster, more reliability, etc. Security remains a dirty word for many organizations, and DevOps doesn't necessarily change that.


In their presentation at the 2012 RSA conference - "Security is Dead. Long Live Rugged DevOps […]", Gene Kim (co-author ofVisible Ops) and Joshua Corman (Director of Security Intelligence for Akamai and co-founder of Rugged Software), presented the idea of "Rugged DevOps". They showed how security can not only be successfully woven into a DevOps delivery model, it is essential to doing DevOps right.


The vulnerability of code, and the necessity of recognizing that vulnerability is best expressed in the "Rugged Manifesto" they quote from - "I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended." They advocate that secure architectures and design can be incorporated tightly into the DevOps release process by making security part of the team, rather than the dreaded check box at the end of the road.


If I was a security professional I would immediately become a DevOps evangelist, because this could be the best thing to happen to security in decades.


I highly recommend you read through the presentation by Corman and Kim, and I won't regurgitate that here. What I will do is delve into an interesting area for DevOps automation - automating Rugged DevOps. As you will see in their work, Corman and Kim contend that Rugged DevOps has organizational, strategic, and implementation dimensions - just like plain old vanilla DevOps does. The bias against security is deeply ingrained in many companies - both in Dev and Ops (something they can agree on).


Security testing slows developers down and audits take Ops away from daily duties. The solution for Ops has been to apply standardization, automation, and reporting - get everybody on the same standard, automate as much of the process as possible, and then provide transparency up and down the value chain through reporting. When applied correctly, this formula can bring huge cost savings and a dramatically improved security stance. DevOps seems set to collide head on with these carefully laid plans (for the Ops teams than even apply them).


From a implementation perspective, I would contend the problem is wrapped up in the way we view security. We tend to view security by device, and sometimes by application (not code, but rather infrastructure like JBoss or Weblogic). You build it, then scan the server. You update the app, then scan the server. And on, and on… To truly implement Corman and Kim's ideal, we need to not only integrate the teams, we also need to view security implementation with DevOps glasses - securing by "Agile Sprints" or deployed "modules", not by server.


So, how do we do that? I would suggest that we need to secure three separate parts of DevOps: the infrastructure, the "sprint" updates, and the actual DevOps process itself. We discuss how to do that in the next installment...

Share: |



This is the second excerpt from our interview with Clyde Logue.



Tom:  So Clyde -- just a quick summary on what you mean by the term DevOps.


ClydeLogue:  DevOps is about development and operation teams working closer together to deliver applications to the business in much the same way as Agile methodology enabled the business users and development resources to work more closely on an application enhancement or a new application. 



DevOps is about development and operation teams working more closely together to deliver applications into production environments.  What was traditionally in some ways called the release management is now part of DevOps as is configuration management, some of level of datacenter automation and even we’re seeing now user monitoring or application infrastructure monitoring is now part of the overall purview of the DevOps type source. 



DevOps is really about a set of methodologies, a way of thinking, that bridges that gap that used to exist between development and operations.



Tom:  Okay. How is DevOps transforming IT and enhancing business performance?



Clyde Logue:   Well, I think DevOps is really in its performance today is focused around applications. In many organizations,their Web applications or their internal applications are critical to their business delivery and business value delivery. So the act of being able to enhance and improve your applications or change them as the market requires, as quickly as possible is critical to success and so DevOps is about delivering application faster.  It has a direct effect on business success. 



I mean we’re seeing companies that have gone from quarterly deployments of applications, which is a fairly long time to wait for new application enhancements, to monthly application deployments and now multiple times a week or even multiple times a day. 




Tom:  All right. Well, Clyde, we’re seeing companies looking for DevOps resources.  What does the DevOps person do? 



Clyde Logue:  DevOps resources can come from either the operations side where they learn more about development and start to understand end-to-end process.  Or they can come from development side where they learn more about operational concerns and production type environments.



So that’s kind of where we’re seeing them emerge, right?  I mean typically there hasn’t been a person that sat in the exact middle, except for some folks sort of on the release engineering teams typically had a foot in both worlds.  So there’s a third option where if you're a member of a Release engineering team or Release management you’re ideally suited for a DevOps type of capability or role. 



Tom: What do they typically do?


Clyde Logue: What do they typically do?  They do everything from managing deployments, to actually executing deployments to understanding the overall release flow, coordinating deployments between different environments, managing those environments, managing configurations, the data, the code within those environments.


And then understanding that the environmental performance of those different applications so if the application is slower then, in many cases, paying a lot of attention to being monitoring of those environments to understand the impact of new application releases on the physical infrastructure.






Coming up next, the third installment of excerpted material from our interview with Clyde Logue.

Share: | mark of a mature IT organization is effective change management. But all too often, updating change records is a neglected data entry chore undermining the usefulness of the change record and raising the spectre of audit failure. To combat this, some of our automation solutions support a feature called "operator initiated change" whereby a Remedy ticket is automatically opened, updated and closed as part of making administrative changes. Role-based access control ensures the person making the change is an authorized administrator, so they are relieved of the tedium of updating the change ticket. Having changes require approvals means a solid record of authorized changes is ensured. This works because the operator never has to change their focus from system administrator to Remedy user, in effect never changing their persona,


A persona-driven approach is the essence of closed-loop change management because it allows someone to stay "in character" while making changes and automatically updates the change record to accurately reflect real-world state. Software development has its own system of change tracking for enhancement requests, defects, etc.and persona-driven approaches to closed-loop change management is an objective there too.


The DevOps trend has focused attention on improving the overall application change cycle (the DevOps Cycle). We at BMC are now taking a persona-driven approach to change management during the application release process. Planning and performing tasks during the release process automatically update change records as those tasks are executed (successfully or not, especially not). As a result, change records contain detailed results of task execution. We record not just operational changes but correlate those changes with the software development changes that are represented in the release (i.e. this deployed application went through these pre-production stages, corresponds to this ITSM change history, contains fixes for these defects and supports these user stories).


This achieves a complete "chain of custody" for the deployed application and connects CMMI with ITIL change disciplines. It provides forensic information for application support personnel should an issue arise, satisfies auditors and delights compliance officers.


Closed-loop change management in the application release process closes a huge part of the gap between Dev and Ops.

Share: |





In our continuing DevOps Leadership Series, we have a discussion with Clyde Logue, a seasoned IT veteran with special insight into DevOps from being a release manager at a major financial institution to co-founder of StreamStep, whose product was created and designed to "bridge the DevOps Gap".

Previously, Clyde was Director of Release Management at Liberty Mutual, where he oversaw and lived the challenges of release management firsthand.  Prior to his tenure with Liberty Mutual, Clyde led product management for enterprise and banking online invoicing solutions at Bottomline Technologies.  Before joining Bottomline, he co-founded mValent (acquired by Oracle). Clyde holds an MBA from The Amos Tuck School at Dartmouth College and a Bachelor of Arts from the University of Texas.



The following is our first excerpt from the podcast interview.





Clyde Logue:  I think we want to talk about datacenter automation but we want to talk about how datacenter automation or, really, the movement around “infrastructure as code”, has evolved out of DevOps and how datacenter automation is really being changed by the DevOps movement. And how DevOps as a methodology has improved the delivery of applications.


What’s happening with DevOps is, and within companies that are starting to adopt DevOps methodology, is they are shortening the gap or reducing that distance between development and operation teams.  So, operation teams are learning more about development and application architectures. And development teams are learning more about datacenter automation and other types of automation in terms of the actual deployments of applications or application deployment automation.



Tom:  Right.



Clyde Logue:  That is a really fruitful cross-pollination as well because the groups are now much more effective at delivering applications to the business.  And that’s the real goal of adopting DevOps. 



Just like companies adopted Agile methodologies for development to try to bridge that gap or reduce the distance between development and business teams in terms of a business saying, hey, I need this piece of functionality and the development teams' understanding and delivering it.



We now have a development team saying I need to deploy this piece of code many more times than we have typically done it in the past and the operation teams now have understanding how to accommodate that level of change.



And it’s critical that they have excellent and complete datacenter solutions in order to deliver that level of change in the environment, especially the production environment. 






In the next transcripted snippet from Clyde's interview, we'll get into his working definiton of DevOps and how DevOps is more than about a gap.

Share: |

An interaction on the DevOps google groups occurred yesterday that struck a nerve. The group has a group of smart, motivated techies who are very passionate but often myopic in concentrating on tooling. This can be a disservice to the DevOps notion in the wider IT community. (DevOps is about making your business run better. Is your toolchain a part of that? Of course. But much more so is planning, coordination, teamwork, use of all of the toolchains, etc. -- culture.)


There's a very human problem at the heart of this behavior that comes out of passion combined with our intimate relationship with our beliefs (we hold them to be self-evidently true). So two thought leaders in the DevOps community, Damon Edwards and Ernest Mueller, replied in a winding thread on the google groups DevOps yesterday.


Without context or further ado, here's the snippet I would like to temporarily memorialize (yes, I'm aware I'm not quoting the entire thread, etc):


---------- Forwarded message ----------

From: Damon Edwards

Date: Mon, Mar 19, 2012 at 5:38 PM

Subject: Re: tools for managing and composing shell scripts?





On Mar 19, 2012, at 5:35 AM, Ernest Mueller wrote:





Let's not all confuse our preferred approach with the One True Way, and let's not confuse DevOps with using the shiniest tools.





Ernest's points deserve highlighting. Not acknowledging the realities of the world some people live in and expecting everyone to conform to ours seems like a sure fire way to kill the DevOps momentum and goodwill.


Most of the time DTO get's called into "brownfield" organizations (or "greenpatch" where it's a "lets do it right" project inside a legacy mess). There are years worth of people, politics, processes, entrenched habits, and general organizational spaghetti to unravel.  Automation toolchains are just one part of a much broader organizational transformation endeavor.



Share: |


In the last part of our excerpts of the interview with Chris Hemphill, Sr. Manager, Configuration / Release / DevTools Engineering at The Active Network, Tom Parrish asks Chris the key question. Chris answers it in short and precise form.




Tom Parish:  Our final question. How is DevOps important to executives?


Chris Hemphill: Well, there's really two things that DevOps gives back to executives and one is it saves money.  Basically, through resource management, you end up saving a lot of time, a lot of people's time, a lot of people's resources, which ends up saving money in the long term.  


            And the other thing is that you really have a reduced time to market with higher quality for your releases. 





The next interview in our series will be with Clyde Logue, co-founder of StreamStep, the company dedicated to "bridging the DevOps Gap" and is now integrated within the BMC family of products.

Share: |


I've been publishing transcript excerpts from the wide-ranging, open interview podcast that our BMC podcast host, Tom Parish, had with Chris Hemphill. Chris is an engaging and insightful senior manager at The Active Network who's doing enterprise-scale, real-world DevOps in the trenches and getting it done. Chris' interview is full of his insight and wisdom and it's a great listen. It's part of the DevOps Leadership Series (and more podcasts are coming).


The podcast in its entirety is now available here


For those of you who, like me, prefer to consume their information by reading, I'm again doing transcript highlights that I am publishing from that interview like Part A here, or Part B, and will do that for every leader we interview. For Chris Hemphill, there is one more transcript excerpt still coming.

Share: |



This is part B highlight of the podcast interview with a real-world, enterprise-scale practitioner of DevOps, Chris Hemphill, Sr. Manager, Configuration / Release / DevTools Engineering at The Active Network.


Below is the excerpt on CI, CD and DevOps.





Tom Parish:  Chris, you've mentioned the importance of agile development and that brings up the whole idea of implementing a continuous delivery environment or a continuous delivery process.  So how does the concept and the philosophy of DevOps play into continuous development? How critical is it? 



Chris Hemphill:  To be able to achieve continuous delivery, it has to start with continuous integration. And without a good continuous integration strategy and automation within the continuous integration environment, you're not going to be able to have a high degree of confidence with the build in the version that is moving through the environment.  So that's step one. 



And then in order to achieve continuous delivery, you also have to have a dynamic and current understanding of the applications state, environment state, database state and configuration state at any given time. 



Tom Parish:  Yes.



Chris Hemphill:  This means understanding exactly what state is an application in and knowing the matrix of all your environments.  And then, further, you also need to know the exact state of your environment and how that relates to the applications within that environment.  



And just as important is the database and the data within the environment and how it relates in your promotion model as it moves down the pipeline, and out to production. Without the culture of DevOps and the integration with the automation tools, you start to lose insight and understanding in these different areas to be able to have a high degree of confidence in your releases and your builds that go out to production. 



There is other point I want to make about continuous delivery and DevOps. 



Tom Parish:  Please do. 



Chris Hemphill:  So one of the things about continuous delivery is -- one of the goals is to get -- to reduce your lifecycle, to get features out to market more quickly, which really means that you need to be able to make decisions quickly, (and) act with good information to be able to make decisions quickly. 


            The only way you can really make good decisions within the timeframe that's needed is by establishing this culture of DevOps. 




Tom Parish:  That's good. I think it's important to keep bringing back the culture piece. It's a thread that I've heard on a number of conversations. "Hey, it's not the tool.  It is the tool but it's the culture with the tool and here's what we mean by culture.”  This touches on all the same things that you've mentioned. 




Upcoming in our Part C excerpt, Chris addresses the key question of why DevOps is important to executives.

Share: |


Today's interview is with Chris Hemphill, Sr. Manager, Configuration / Release / DevTools Engineering at The Active Network. The Active Network, Inc. is a leading provider of organization-based cloud computing applications serving diverse market segments including business events, community activities, outdoors and sports. Their technology platform, ActiveWorks™, transforms the way organizers manage their activities and events by automating online registrations and streamlining other critical management functions, while also driving consumer participation to their events.



"It really has a lot of transparency, visibility and the ability to audit the full release process. For anyone who has to deal with SOX compliance, you can understand how big a deal that is.  All the while it gives us the flexibility we need to run complex, smoky, multi-faceted releases."

Chris Hemphill, Senior Manager, Configuration / Release / DevTools Engineering, The Active Network




What follows below is the first of several highlights of this upcoming podcast with Chris Hemphill about DevOps at Enterprise Scale.






Tom Parish:  Chris, What exactly is Active Network?



Chris Hemphill:  Active Network provides technology to organizations to help facilitate and manage their activity,  from online registrations to transaction processing to marketing. We might help an event director manage and create a 5K, marathon or triathlon race, for example, taking the registrations for that race, putting on events and helpingthe event coordinators manage the event. Or an event like Oracle World. 



Tom Parish:  I can see that you guys have to do a lot of different things and many are fairly specialized from event to event.   I can see where being nimble would be really important. 



Chris Hemphill:  Yes.  Events are constantly changing and there are new events that are coming up all the time.  That's exactly right.  We have to be nimble and put things out tomarket quickly to be able to support what the customers need. 



Tom Parish:  We've been doing a number of podcast on DevOps; it is a fairly new topic on this show. Just in case someone hasn't caught up on the terminology, let's talk about it for a moment and have Chris fill us in on what DevOps is and what it's not. 



Chris Hemphill:  I see DevOps as a culture, the culture that exists within an organization.  You use technology to be able to support that culture, as opposed to seeing DevOps as a technology methodology. 



Tom Parish:  So DevOps isn't a tool in itself or a technology in itself? It's both the culture and the tool together? 



Chris Hemphill:  That's right. It has to start from the top through fostering the culture of partnership with the IT department, with the SDM, with the development, QA, project and product management teams.  Through that culture of partnership with all of those teams you then devise the methodology and the technologies to be able to support a DevOps culture. 



It's really required in today's enterprise environment because organizations are moving away from the more traditional development methodologies like waterfall and replacing them with Agile development methodology.  You need to be fast and nimble.  Services need to get out to the market quickly. 



The shift in development methodology doesn't remove the requirement to understand the change that's moving through the development life cycle. This shift makes that change and understanding that change even more critical for the teams. 



What you're seeing in the industry is that timelines and development cycles are becoming shorter, but the application dependencies and the application complexities are not.  And so to be able to handle the agile development cycle, while maintaining the high level of quality, the teams have to be focused and very quickly understand and pinpoint change throughout the applications.  Then they can concentrate on the areas of the software that needs to be tested and prepared for release. 



At the Active Network, we’ve been very fortunate.  We've gotten good support on  this culture and technology for DevOps throughout the organization. 



Tom Parish:  How is DevOps related to automation?  I know that’s probably an oversimplified wayof looking at it but I would imagine folks who've been around IT for a longtime may think, "Oh, that's just related to automation."  I bet that's not true. 



Chris Hemphill:  I see DevOps more as a culture where the automation helps to support that culture.



Tom Parish:  Okay. 



Chris Hemphill:  If you look at development today, as things move towards the rapid Agile Development Model, this means that you're going to have many deployments from many different environments every single day.  Automation is the key spanning simple build and unit testing all the way to being able to very quickly build out an entire environment with tested applications.



It has to be done reliably, be repeatable and fast.  To be able to hit those three things really requires a high level of automation.

Communication is essential.  Each step along the way, the communication to the various teams must be clear, concise and immediate. 



The only way to achieve that type of communication for the many different steps along the way within this lifecycle, especially in an abbreviated development life cycle, is to provide solid automation throughout the process. 



In Part B, Chris will discuss the importance of DevOps to Continuous Integration and Continuous Delivery.

Share: |

Since the acquisition of StreamStep by BMC, it's been a very busy time for me and for the other StreamStep folks.


I've been lucky to be involved in a lot of hard, great, in-depth conversations with some solid Ops intelligentsia all in the same virtual room. And as these discussions unfolded, it became clear, I think, to all of us, that the whole DevOps movement actually has at its core something larger than 'the Gap' that exists between Dev and Ops.


If you'll go back to the Leadership interview that began with Patrick Debois, he even kept pointing at it himself. He didn't have or use a name for it. And it shows up elsewhere, like in James Turnbull's comment on the DevOps Google groups that "uptime is not servers, or services, uptime is business." There's something underneath all of this, something deeper than a DevOps gap in application movement from Dev coding through to Ops production.


“I saw the term DevOps as collaboration, but in reality, this is a narrow definition.  It's not just about development and operations collaborating, it's getting every silo, every part of the business, of the enterprise and the organization collaborating to meet business goals.”

Patrick Debois,

DevOps Leadership Series

Feb 2012

DevOps is about the business, the business of producing applications, more than just Brooks' book Mythical Man-Month's analogy about "transom effect" (as in, 'tossing over the') widened and deepened by Agile, cloud and multi-tier stacks. It's more than that -- but still DevOps. DevOps as mostly discussed to date, however, is about the gap.


So we hammered on it, made decks, threw it out, drew pictures, revisited it, pounded on it, tested it out with analysts and certain customers and got to something. I think we've got something here. Like any concept, it's a mental tool for navigation, for clarity, for visibility, for accelerating use of your OODA loop.


Here's Jody giving a quick 2 minute overview, hopefully worth your time:



Share: |



The last question in our DevOps Leadership Series interview with Patrick is around a phenomenon all of us involved one way or another in the DevOps movement over the last few years have been watching closely. Like it or not, "DevOps" has become huge.


There's a blitz of articles from analysts and media on "DevOps is the next big thing". Today, most everybody's a convert (or on a crusade against it, for some reason). And, of course, the vendor community with relabeling product . . . vendors suddenly have old products with new "DevOps suite" names -- you know who you are -- and then there's the latest to jump on the bandwagon ("now with DevOps!"), the giant from Redmond.


So we asked Patrick about that. He gave a straight, customer-oriented answer.




Tom Parish:  Patrick, last question.  DevOps seems to be at risk from suffering from an overload of media and analyst noise, so do you think this is a danger to the organic growth and the adoption of DevOps?



Patrick Debois: Obviously you have watched it growing at an increasing rate. But some companies are just taking that term, re-branding          their processes or repositioning existing products


Will it be a danger?  



The difference is that this doesn't just start from an institute or a company success - let's coin the term and drive it through.  It has to grow from a bottom-up approach, which takes longer.  If a vendor uses that term and he doesn't deliver, each person has to evaluate whether that was a good thing or not.






Here in total are links for all the excerpts and the podcast itself (25 minutes):


Excerpt A: What DevOps is, and what it is not


Excerpt B: Tooling, ITIL and collaboration


Excerpt C: Monitoring & the Awkward Teenage Years


Excerpt D: Departmental Metrics vs. Business Metrics


Excerpt E: Is DevOps at risk from vendor hype?

Share: |



In this section of the interview with Patrick, we cover some fundamentals that are starting to come up in the discussion of DevOps and the changes it brings. Then the harder issue around metrics and their role in both Dev-side thinking and in DevOps.



Tom Parish:  We were talking about DevOps and how it needs to be a part of everything from the software development cycle all the way to release, but how far back into the product life cycle should DevOps go, or be involved?


Patrick Debois: If somebody has an idea,  you start discussing it determining whether it's a good idea or even feasible.   I guess that's not a good time to actually get engineering involved, because they are focused on getting it done, so you lose the creativity.  Once you get going on a project, it makes sense to have them involved, in part to have a reality check. 



From that moment on, it makes sense to get all these people aboard, and see what the impacts would be across their different specialty.  Don’t wait until the product is partly developed and then come in. You can start immediately at the project phase when that kicks off...



You can do it sooner, but like I said, the risk is they will just stop imagining.   You have to pick the right moment.

Tom Parish:  Hmm, interesting.  Let's say a group is definitely into the DevOps concept and moving in that direction. Can you provide some insights into DevOps success metrics for developers, operations and business people?



Patrick Debois: Ultimately, it comes to having people work together in way that helps to  make that business a success.  It’s hard to define a metric for that. Traditionally, the metrics have been winning for each silo. There would be things like the number of pointer codes, the number of services you manage, but what they don't take into account is how you measure the collaboration aspect between the different groups, and whether you're actually doing something useful.



If you look at more flow-based metrics, how long does it take to get something from development to production?  You can't take that alone as a metric, because you can do a lot of shitty things and push them out very fast, but you also have to look at how your flow rate is reduced doing that stuff.



I don't think metrics make sense if they are measured by group or by individual.  You have to look at the  flow from the beginning to the end.  Is it optimized? I If you reduce that time, you will notice that it means you are resolving collaboration conflicts you had in the past. 



Did we actually tackle that problem?  The metrics that exist within typical Scrum or Agile management may have some use but you have to extend them so that it makes sense when you go through the whole cycle.




Tom Parish:  By the way, do you need to do this internally in each group, as well?  You figure out what your metrics are, but then, you keep your eye on more than their metric.  You need to look at whether what you're doing is adding or subtracting to the end goal?



Patrick Debois: Yes.  I made the analogy with managing servers.  How do you know that your business is up?  If you ask your system administrator, he will tell you things like how the CPU, memory and disk areperforming.  But that doesn’t matter.  Your developer will say, "Oh, my code works.”   But the only monitoring that actually makes sense is from a business perspective.



Can a user log in? Can you accept this page?  But if you measure that and yet, something fails, what you need is the lower level metrics and monitoring to be able to understand where it's failing and why it's failing.  And you won't get that from a business perspective, obviously.  You still need to monitor from the business perspective, but you also need  the lower level metrics  to see where things are working or failing.




The last question in our interview with Patrick comes in the next installment when he's asked if DevOps is at risk from all the vendor hype (so many vendors have simply rebranded existing product "now with DevOps!") and then the analyst and media hype . . .

Share: |


The third snippet from Tom Parish's interview with Patrick Debois gets into monitoring issues. Plus, a fun and interesting analogy for apps as kids in development, to teenagers in operations, to wrinkled and old in legacy. Here's the excerpt from the interview:



Tom Parish:  How important is monitoring for DevOps?


Patrick Debois: A lot of the initial focus of technical discussions in DevOps was about automation, and clearly, it's about how fast can we get things into production.  This makes sense and it’s a crucial part. But once things are in production, you will want to know how they're doing.  Do they make sense?  Are they valuable to the customer?  What's happening there? Are things breaking?  You need automation that provides reporting feedback from ops to dev, so that everyone knows what is happening.    How can we learn from what is happening there? 



From a business perspective and from a development perspective, how can we learn from all the feedback we are getting from customers?  It's a major part of this – you need to receive feedback once it's there.



Tom Parish:  Yes. It just has to be there as part of  the feedback mechanism.



Patrick Debois: Traditionally, but they are different tools; monitoring used to be kept within the operational site.



Tom Parish:  Oh, yes. I see what you're saying.



Patrick Debois: More and more people are beginning to relate that to their development and business groups, so they can learn from that as well.  It is a strange thing - why are we using different tools for debugging and testing things in our test labs environment?  Why are we not using the same monitoring tools to understand what's going on there?



These tools will start aligning too, but in the whole cycle we are using and viewing what's out there.  Why are developers not writing monitoring scripts, so they can see issues while they're writing the application as well as once it's in production you can see what's happening there.  And from what I've seen, developers actually love to see how their baby runs.  It just makes sense.




Tom Parish:  You spend hours in development, not just by yourself but with your whole team, and part of the satisfaction is to see how well it's performing. I think it's a really good way of working.  It's kind of odd that it hasn't happened sooner.



Patrick Debois: There's a kind of metaphor I use  – relating development to raising kids.  Just before the teenage years, the kids are sweet and nothing is happening.  But when you're putting things into production, it starts behaving differently, strangely, like a teenager.


            You don't know what's happening.



Then after a few years, the legacy code starts growing old, so in fact, they need to care about it  from inception tools through legacy,  not just when everything is sweet and performing well.

Tom Parish: In other industries, they have seen essential transformation of product supply chain activities, by focusing on build-to-manufacturing practices.  So is this transformation similar to how DevOps is transforming IT?



Patrick Debois: We have a discussion about how this - if manufacturing is lean, it is sort of similar to this way of thinking, but within manufacturing, you try to minimize change as well.  Within Ops, we do try to minimize the change in a way and we automate, trying to we make everything repeatable, but it's more about freeing up time to work out the most complex problems.



We are not doing this to make people redundant, but to free up those valuable resources so we can do more and more fabulous, awesome things. It's a strange thing that a lot of people drive automation just to reduce the number of people who manage servers, but in fact, all the time that gets freed up enables them to do things that actually differentiate them from their competitors.



It's not just about minimizing the number of people or automating things like a factory. That's why I don't like the metaphor of the factory, because it implies that we want to remove the human factor.  And I believe in the opposite.




More to come in the next part of our interview with Patrick Debois when he discusses departmental metrics vs. business metrics . . .


Share: |



I've been publishing transcript excerpts from the wide-ranging, open interview podcast that our BMC podcast host, Tom Parish, had with the engaging and insightful fellow who kicked off this whole DevOps thing in late 2009, Patrick Debois. It's part of the DevOps Leadership Series (and more podcasts are coming).


The podcast in its entirety is now available for download here.  You can also stream it from this page.


For those of you who, like me, prefer to consume their information by reading, I've got a some more transcript highlights that I will be publishing from that interview, coming out daily tomorrow through Thursday.

Filter Blog

By date:
By tag:
It's amazing what I.T. was meant to be.