DevOps is a term for a group of concepts that, while not all new, catalyzed into a movement in 2009 and rapidly spread throughout the technical community. Like any popular term, people often have confused and contradictory impressions of what it means. Here’s my take on how DevOps can be usefully defined; I propose this definition as a standard framework to more clearly discuss the various areas DevOps covers. Like “Quality” or “Agile,” DevOps is a large enough concept that it requires some nuance to fully understand.
Definition of DevOps
DevOps emerged from the collision of two major related trends. The first was called “agile infrastructure” or “agile operations”; it sprang from applying Agile and Lean approaches to operations work. The second is an expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service, and how important operations has become in our increasingly service-oriented world (cf. Operations: The New Secret Sauce).
I believe that you can define DevOps practically as:
DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the entire development process all the way to deployment and production support.
A primary corollary to this is that part of the major change in practice from previous methods is incorporation of knowledge from each field into the other.
DevOps is also characterized by operations staff making use of many of the same techniques as developers for their systems work, and development staff creating applications designed to work well in an operational environment.
Developer techniques that operations learns to use in a DevOps environment range from using source control to developing infrastructure as code (including testing) to participating in an Agile development process. Operational concerns built into systems include observability and resilience. Both tend to use continuous integration and delivery as the means of iterating on a solution.
“DevOps” is intended to be maximally inclusive. It doesn’t differentiate between different sysadmin sub-disciplines – “Ops” is a blanket term for systems engineers, system administrators, operations staff, release engineers, DBAs, network engineers, security professionals, and various other subdisciplines and job titles. “Dev” is used as shorthand for front end and back end developers in particular, but really in practice it is even wider and means “all the people involved in developing the product,” which can include Product, QA, and other disciplines.
DevOps has strong affinities with Agile and Lean approaches. The old view of operations tended towards the “Dev” side being the “makers” and the “Ops” side being the “people that deal with the creation after its birth” – the harm that has been done in the industry from those two being treated as siloed concerns is the core driver behind DevOps. In this way, DevOps can be interpreted as an outgrowth of Agile – agile software development prescribes close collaboration of customers, product management, developers, and (sometimes) QA to fill in the gaps and rapidly iterate towards a better product – DevOps says “yes, but service delivery and how the app and systems interact are a fundamental part of the value proposition to the client as well, and so the product team needs to include those concerns as a top level concern.” From this perspective, DevOps is simply extending Agile principles beyond the boundaries of “the code” to the entire delivered service.
Definition In Depth
DevOps means a lot of different things to different people because the discussion around it covers a lot of ground. People talk about DevOps being “developer and operations collaboration,” or it’s “treating your code as infrastructure,” or it’s “using automation,” or “using kanban,” or “a toolchain approach,” or “culture,” or a variety of seemingly loosely related items. The reason this is confusing is that there are different levels of concern within DevOps, with higher level concerns informing more specific implementation in lower levels. Here’s a taxonomy to clarify the space.
- DevOps Values – I believe the fundamental DevOps values are effectively captured in the Agile Manifesto – with perhaps one slight emendation to focus on the overall service or software fully delivered to the customer instead of simply “working software.” Some previous definitions of DevOps, like Alex Honor’s “People over Process over Tools,” echo basic Agile Manifesto statements and urge dev+ops collaboration.
- DevOps Principles – There is not a single agreed upon list, but there are several widely accepted attempts – here’s John Willis coining “CAMS” and here’s James Turnbull giving his own definition at this level. “Infrastructure as code” is a commonly cited DevOps principle. I’ve made a cut at “DevOps’ing” the existing Agile manifesto and principles here. I personally believe that DevOps at the conceptual level is mainly just the widening of Agile’s principles to include systems and operations instead of stopping its concerns at code checkin.
- DevOps Methods – Some of the methods here are Agile; you can use Scrum with operations, Kanban with operations, etc. (although usually with more focus on integrating ops with dev, QA, and product in the product teams). There are some more distinct methods, like Visible Ops-style change control and using the Incident Command System for incident reponse. The set of these methodologies are growing; a more thoughtful approach to monitoring is an area where common methodologies haven’t been well defined, for example.
- DevOps Practices –Specific techniques used as part of implementing the above concepts and processes. Continuous integration and continuous deployment, “Give your developers a pager and put them on call,” using configuration management, metrics and monitoring schemes, a toolchain approach to tooling… Even using virtualization and cloud computing is a common practice used to accelerate change in the modern infrastructure world.
- DevOps Tools – Tools you’d use in the commission of these principles. In the DevOps world there’s been an explosion of tools in release (jenkins, travis, teamcity), configuration management (puppet, chef, ansible, cfengine), orchestration (zookeeper, noah, mesos), monitoring, virtualization and containerization (AWS, OpenStack, vagrant, docker) and many more. While, as with Agile, it’s incorrect to say a tool is “a DevOps tool” in the sense that it will magically bring you DevOps, there are certainly specific tools being developed with the express goal of facilitating the above principles, methods, and practices, and a holistic understanding of DevOps should incorporate this layer.
In the end, DevOps is a little tricky to define, just like its older brother Agile. But it’s worth doing. When left at the pure philosophy level, both can seem like empty mom-and-apple-pie statements, subject to the criticism “You’re just telling me ‘do my job better,’ duh…” But conversely, just the practices without the higher level guidance turn into a cargo cult. “I do what this Scrum book says so I’m doing Agile” is as erroneous as “I’m using Chef so I’m DevOps right?” To be a successful Agile or DevOps practitioner is to understand all the layers that go into it, and what a given DevOps implementation might contain or not contain. In the end, what DevOps hopes to bring to Agile is the understanding and practice that software isn’t done until it’s successfully delivered to a user and meets their expectations around availability, performance, and pace of change.
Specifically, I’ve come to believe there are three primary practice areas that are usually discussed in context of DevOps.
- Infrastructure Automation – create your systems, OS configs, and app deployments as code.
- Continuous Delivery – build, test, deploy your apps in a fast and automated manner.
- Site Reliability Engineering – operate your systems; monitoring and orchestration, sure, but also designing for operability in the first place.
History of DevOps
The genesis of DevOps comes from an increasing need for innovation on the systems side of technology work. The DevOps movement inherits from the Agile System Administration movement and the Enterprise Systems Management (ESM) movement.
ESM, which arose in the mid-2000’s, provided the original impetus of “Hey, our methodology of running systems seems to still be in a pretty primitive state despite years of effort. Let’s start talking about doing it better.” John Willis, whurley, and Mark Hinkle from Zenoss were involved in that, and sponsored a BarCamp around the concept. I think during this phase, initial enchantment with ITIL as a governance framework was largely overthrown for the “ITIL Lite” Visible Ops approach, as well as a shift from being “large vendor” focused – used to be, the enterprise frameworks like HP, IBM, and CA were the only meaningful solutions to end to end systems management, but more open source and smaller vendor stuff was coming out, including Spiceworks, Hyperic, Zenoss, and others.
Also in 2008, the first Velocity conference was held by O’Reilly, focusing on Web performance and operations, which provided a venue for information sharing around operations best practices. In 2009 there were some important presentations about the developer/operations collaboration at large shops (most notably Flickr) and how that promoted safe, rapid change in Web environments. Provisioning tools like Puppet and Chef had strong showings there. More people began to think about these newer concepts and wonder how they might implement them.
Somewhat in parallel, as agile development’s growth in the development space was reaching its most fevered pitch and moving from niche to common practice, this turned into thinking about “Agile Systems Administration” especially in Europe. Gordon Banner of the UK talked about it early on with this presentation. A lot of the focus of this movement was on process and the analogies from kanban and lean manufacturing processes to IT systems administration. Then in 2009, Patrick Debois from Belgium and Andrew “Clay” Shafer from the US met and started talking up (and coined the term) DevOps, and then Patrick held the first DevOpsDays event in Ghent that lit the fuse. The concept, now that it had a name, started to be talked up more in other venues (I found out about it at OpsCamp Austin) including Velocity and DevOpsDays here in the US and spread quickly.
In Patrick Debois’ view, DevOps arose as a reaction against the silos and inflexibility that were resulting from existing practices, which probably sounds familiar. Here’s a good piece by John Willis on the history of the DevOps movement that deconstructs the threads that came together to create it.
DevOps emerged from a “perfect storm” of these things coming together. The growing automation and toolchain approach fed by more good monitoring and provisioning tools, the need for agile processes and dev/ops collaboration along with the failure of big/heavy implementations of ITSM/ITIL – they collided and unconsciously brought together all three layers of what you need for the agile movement (principles, process, and practices) and caught fire. Since then it has developed further, most notably by the inclusion of Lean principles by many of the thought leaders.
What is DevOps Not?
It’s Not NoOps
It is not “they’re taking our jobs!” Some folks thinks that DevOps means that developers are taking over operations and doing it themselves. Part of that is true and part of it isn’t.
It’s a misconception that DevOps is coming from the development side of the house to wipe out operations – DevOps, and its antecedents in agile operations, are being initiated out of operations teams more often than not. This is because operations folks (and I speak for myself here as well) have realized that our existing principles, processes, and practices have not kept pace with what’s needed for success. As businesses and development teams need more agility as the business climate becomes more fast paced, we’ve often been providing less as we try to solve our problems with more rigidity, and we need a fundamental reorientation to be able to provide systems infrastructure in an effective manner.
Now, as we realize some parts of operations need to be automated, that means that either we ops people do some automation development, or developers are writing “operations” code, or both. That is scary to some but is part of the value of the overall collaborative approach. All the successful teams I’ve run using this approach have both people with deep dev skill sets and deep ops skill sets working together to create a better overall product. And I have yet to see anyone automate themselves out of a job in high tech – as lower level concerns become more automated, technically skilled staff start solving the higher value problems up one level.
It’s Not (Just) Tools
DevOps is also not simply implementing a set of tools. One reason why I feel that a more commonly accepted definition of DevOps is needed is that having various confusing and poorly structured definitions increases the risk that people will pass by the “theory” and implement the processes or tools of DevOps without the principles in mind, which is definitely an antipattern. Automation is just the exercise of power, and unwise automation can do as much damage as wise automation can bring benefit.
Similarly, Agile practitioners would tell you that just starting to work in iterations or adopting other specific practices without initiating meaningful collaboration is likely to not work out real well. There are some teams at companies I’ve worked for that adopted some of the methods and/or tools of agile but not its principles, and the results were suboptimal. Sure, a tool can be useful in Agile (or DevOps), but if you don’t know how to use it then it’s like giving an assault weapon to an untrained person.
But in the end, fretting about “tools shouldn’t be called DevOps” is misplaced. Is poker planning “agile” in the sense that doing it magically gets you Agile? No. But it is a common tool used in various agile methodologies, so calling it an “agile tool” is appropriate. Similarly, just because DevOps is not just a sum of the tools doesn’t mean that tools specifically designed to run systems in accordance with a DevOps mindset aren’t valuable. (There are certainly a bunch of tools I’ve used that seem specifically designed to prevent it!)
It’s Not (Just) Culture
Many people insist that DevOps “is just culture” and you can’t apply the word to a given principle or practice, but I feel like this is overblown and incorrect. Agile has not helped thousands of dev shops because the work on it stopped at “culture,” with admonitions to hug coworkers and the lead practitioners that identified the best practices simply declaring it was all self-evident and refusing to be any more prescriptive. (Though there is some of that). DevOps consists of items at all the levels I list above, and is largely useless without the tangible body of practice that has emerged around it. You might be able to figure out all those best practices yourself given the cultural direction and lots of time to experiment, but sharing information is why we have the Internet (and printing press for that matter).
It’s Not (Just) Devs and Ops
And in the end, it’s not exclusionary. Some people have complained “What about security people! And network admins! Why leave us out!?!” The point is that all the participants in creating a product or system should collaborate from the beginning – business folks of various stripes, developers of various stripes, and operations folks of various stripes, and all this includes security, network, and whoever else. There’s a lot of different kinds of business and developer stakeholders as well; just because everyone doesn’t get a specific call-out (“Don’t forget the icon designers!”) doesn’t mean that they aren’t included. The original agile development guys were mostly thinking about “biz + dev” collaboration, and DevOps is pointing out issues and solutions around “dev + ops” collaboration, but the mature result of all this is “everyone collaborating”. In that sense, DevOps is just a major step for one discipline to join in on the overall culture of agile collaboration that should involve all disciplines in an organization. So whoever is participating in the delivery of the software or service is part of DevOps.
It’s Not (Just) A Job Title
Simply taking an existing ops team and calling them “The DevOps Team” doesn’t actually help anything by itself. Nor does changing a job title to “DevOps Engineer.” If you don’t adopt the values and principles above, which require change at an overall system level not simply within a given team, you won’t get all the benefits.
However, I’m not in the camp that rails that you ‘can’t have DevOps in a job title.” It is often used in a job title as a way to distinguish “new style DevOps-thinking, automation-first, dev-collaborating, CI-running, etc. sysadmin” from “grouchy back room person who aggressively doesn’t care what your company does for a living.” Some people find value in that, others don’t, and that’s fine. As a hiring manager myself, I see a clear difference in the fit of applicants when I put it on a job posting for a systems engineer, which provides an incentive for me to keep doing so…
It’s Not Everything
Sometimes, DevOps people get carried away and make grandiose claims that DevOps is about “everything everywhere!” Since DevOps plugs into the overall structure of a lot of lean and agile thinking, and there are opportunities for that kind of collaboration throughout an organization, it’s nice to see all the parallels, but going and reengineering your business processes isn’t really DevOps per se. It is part of an overall, hopefully collaborative and agile corporate culture, but DevOps is specifically about how operations plugs into that. Some folks overreach and end up turning DevOps into a super watered down version of Lean, Agile, or just love for everyone. Which is great at the vision level, but as you march down the hierarchy of granularity, you end up mostly dealing with operational integration – other efforts are worrying about the other parts (you can personally too of course). But there are still a lot of unsolved problems around the delivery of software and maintenance of services and making it fast, reliable, secure, et al. – if someone wants to use what they’ve learned from DevOps to go be a larger scope corporate consultant that’s fine, but most people involved in DevOps are technical practitioners who are looking for better ways to do their job, not someone else’s. In Agile there is “Agile Software Development” and then there’s the larger Agile organization work. I think DevOps is best defined as “Agile Software Delivery and Operations,” which should similarly work in concert with others working on larger organizational initiatives, but without losing sight of its primary value proposition for the organization.
Getting Started With DevOps
There’s not one path to DevOps – there’s just what works in your organization. Very successful DevOps initiatives have been originated from dev teams and from ops teams, top down and bottom up, from inside the company and from consultants, with widespread education and with skunkwork pilots. Therefore it’s hard to give a generic playbook for how you can get it implemented. I think it’s safe to say that it starts with you yourself learning about the values, principles, methods, and practices of DevOps and trying to spread it via whatever channel is most effective – telling fellow techies, getting management buyin, just starting to implement things in a more DevOps way yourself and letting success speak for itself… People will try to tell you how things can rise to success in your org, but that advice is usually more policy and wishful thinking than reality. Observe how other popular things in your organization have arisen and gained currency and try those same channels. And keep learning.
-by Ernest Mueller, Aug 2, 2010
– Last Revised April 26, 2023
the agile admin 
Pingback: What’s a “DevOp?” « the agile admin
Pingback: Intro to DevOps + what we learned at DevOpsDays Boston 2011 | ZeroTurnaround.com
Pingback: Intro to DevOps + what we learned at DevOpsDays Boston 2011 | Agile Development
Pingback: Ubuntu 11.10 released, DevOps now distilled (and defined) | Journal of Technology and Economic Development | Future Technology | Green Technology | Military Technology | Business | Trading | Finance | Computer | Robots | Entertainment | Games | GPS | Soft
I suggest the term ” DevOps Engineer” to clarify that it is not a Developer or IT operation person, it is a complete new role.
I don’t believe DevOps is a new role or job title. It is a way of working. It is people with both developer and operations skill sets (one, the other, or a mix) working together on product teams to create products.
In a larger org, you may have some operations folks that embed into product teams and others that don’t directly. You may have developers working on system provisioning tools, release automation, or monitoring and testing frameworks. Those may have specific role names, but which one is “the” DevOp? None of them, for that’s not a job title.
When agile came, you didn’t start calling developers AgileDevs. If a dev does test driven development, they’re not a DevTester. When a QA person works closely with developers to automate their testing, they’re not a DevQA. At best, agile is an adjective or something put in a job description to indicate “we want people used to collaborating in this way” – but you don’t hire an “Agile.” Same with DevOps. There are DevOps devs and DevOps ops and DevOps who have both skill sets and do some of both.
I agree with your point of view on the idea of “DevOps engineer” as a new, different role. I think it’s harmful for the reasons you cite above and the reasons Jez sited in his “No such thing as a DevOps team” article. However, I keep seeing people new to DevOps immediately adopt that anti-pattern, so I’ve been trying to think of a good, simple analogy to explain why it’s a bad idea.
The best I can come up with so far is two people dancing. Originally they danced awkwardly together, partially because they didn’t really like each other, but partially because they didn’t understand the other’s rhythm. Now, they’ve changed and they’re starting to figure out how to dance together better, and they’re starting to understand and even practice the other’s rhythm. The last thing you want to do is introduce a third party who acts as the broker between the two dance partners! It’s actually even more awkward!
Can you think of a better analogy or can you improve upon this one? I think it would help make this subtle concept more obvious.
This is perfect; I’m the Scrum Master for an organization that is upping it’s agile implementation substantially. As the dev teams have ramped up the gap with OPs has become very clear, and we’re looking at how, with the people we have, to bring the OPs folks more closely into the teams as we already have with UX and QA.
Your articles, and specifically your comment above very clearly outline not only the “why” though also offer very clear ideas on the “how”.
I’ll definitely be forwarding your site on to both the product owner and VP of engineering.
Thank you again for putting the time into this valuable topic!
Pingback: G's view of the world - On dev-ops, marketing, the c-word, and pneumonia
I do not often subscribe to BLOGS as me thoughts on Agile often conflict with many of the traditional mindset Agile-ists. I found your posting on DevOps enlightening and look forward to both reading more or your postings and adding my own comments also.
I come from a rare area for Agile advocation, that of Quality, please note I did not say QA or testing. Not that there is anything negative about QA or testing, however, after 15+ years living in this area and 6+ years offering my ideas supporting the Agile Principles to my senior leadership, it has become blatently obvious that divides still exist. I have manged many QA teams on large and small projects and influence upwards with the goal to increase Quality. Until now I had never heard of the role DevOp and now I feel much more content knowing that I am a DevOp proponent.
I also recently returned to the UK after 21 years in the USA working as a Developer, Test Manager, Scrum Master and Agile coach and I have easily seen much more eagerness to move towards Agile principles than I ever saw in the USA…why? I do not know yet, but will drill down to find out.
Cheers
Ray Scott
I believe it is the cultural individualism that is part of the US culture. While this spawns high creativity, entrepreneurship, and responsibility for results it does make adopting change and group goals somewhat difficult to buy into. It would seem the natural ying/yang of the opposing cultural and business priorities make some methods not only difficult to implement but also to even promote understanding for.
I recently supported a team in Sweden on a six month assignment and walked away with the same impression regarding eagerness to move towards Agile principles. If you ever gain any insight, or have thoughts on why, please share them as I’d be very interested in understanding the reasons – and perhaps using them to help push and evolve those same principles within my company – and teams culture.
Glad it’s resonating with y’all! I first heard the term at Opscamp 2009, and I realized “So THAT’S what I’ve been trying to get at…”
Pingback: Windows Azure and Cloud Computing Posts for 4/2/2012+ - Windows Azure Blog
Pingback: DevOps | andrewleaning.com
OUTSTANDING. I’m a sysadmin and dba (with a strong codemonkey streak) that is just now becoming aware of DevOps. Your post was extremely helpful in making the concept clearer to me.
Pingback: Agile and DevOps: A Perfect Match
Pingback: Devops Reading List | IT Revolution
DevOps is slowly catching on but I’ve noticed a struggle over control that seems to hinder it’s success. It’s not cut and dry, there are shades of DevOps while Dev and IT cultures slowly merge onto the same page. There’s definitely a lot of baggage (processes & people) to overcome…
Fantastic. Infrastructure and Dev have been eschewed from each other entirely too long. I am glad that the lesson has been learned we all are more useful to each other as collaborators than adversaries.
Pingback: Intro to DevOps | zeroturnaround.com
Pingback: DevOps Scares Me - Part 1 - AppDynamics: The APM Blog
Hi,
Would you allow me to translate this post to spanish and post it in our blog?
Looks like you already have; that’s fine but please credit/link to us here…
Sorry about that, it wasn’t support to be publish just yet.
But thanks, I’m going to update it to add the credit and links.
Thanks again.
Pingback: HomeOps: A call for the application of Devops principles at home, too | 0xf8.org
Pingback: The Phoenix Project Review | BrokenOps
Pingback: Is Your Product Team Using Ideal Devops Processes? Take a Look at These Devops Best Practices | Virtustructure
“DevOps Engineer” sounds so much better than “one man show”. gotta remember that.
You seem to have come away with the common misconception (not from this article, clearly, but I’ve seen the popular articles on the Internet that make that claim) that DevOps means one person does everything. That is clearly not the case. “Collaboration” doesn’t mean “one man show,” it means “working together with others.” Now, working together with people does require some basic understanding of and caring about what they do – if you’re the guy who deploys apps to production but you know nothing about what the devs do, you’ll be terrible at your job. And certainly, the nature of the ops jobs are changing to require more automation – sorry, but like making buggy whips, the days of lovingly installing the OS on 20 servers by hand are passing, it’s just not professional any more. But claiming DevOps (or Agile) requires everyone to “do everything” is not credible; get out there and see some real world implementations. The trick is to help those different specialties work together without the harmful siloing and turf warring of the past.
Today, I was participating in Agile India week 2014 confernce in Bangalore and came to know DevOps ‘term’ first time. After reading this blog, I felt, for so many years, why agile community only concentrated till CI and never extended to oprations. It amazing.
Yes, it’s definitely one of those “how did we overlook this” moments! Welcome!
Pingback: Austin, Devops and Great Folks | Cloud Insanity
In Devops, is the deployment done to the real working customer environment? If so, does it make the customer (Operations) working difficult?
Pingback: DevOps | Ciclo SW
Pingback: DevOps? A good definition | Automize.org
Pingback: Selecting a Delivery Pipeline: 10 Considerations | Jayme C Edwards
Pingback: Four Pillars of DevOps – Presentation at Agile Cambridge 2014 | johnfcshaw
Pingback: Why Media Companies Should Pay Attention to Software Development/Operations Integration - Olivier Travers
Pingback: The next wave of IT fadeouts | Nagg
To be honest, this sounds a little like a combination of what I used to do many years ago when designing “applications” and what I did more recently with scripting and such. It was all about first finding out what needed to be done and designing the work flow long before you got your hands dirty and actually put something together that would provide what the users needed to happen. I’m a great believer in the great cycle of technology in that nothing is ever left behind, whether it is a hardware technology, software concept or a way of thinking and this just strikes me as returning to what I did in the 1980s and 1990s before everyone got obsessed with buying the latest brand names and putting up with the inadequacies.
But I could always be wrong. It wouldn’t be the first time.
Pingback: DevOps and agile - building a new best practice
Pingback: Is There Value in DevOps? | Jason Armstrong
Hi,
This is a very information article. Thank you very much, Could you please share your thoughts on how QA fits in the DevOps model?
Sure, I’ll write a post on it.
Hi sir, can you please share your thoughts on how QA fits in the DevOps model?
That would be awesome!
Work that depends on several groups to work well has always depended on the good relations between the groups, mutual respect, and an appreciation of what those groups do, their workload, and how they have been historically treated.
Operations seems to have always been treated with less than respect, and with the ever-increasing demands on them, the increasing level of expertise needed, and the dependence of other groups on them, it pays to give them the respect they deserve.
This also goes for any group in an organization. Inter-dependence demands that we give respect and the benefit of the doubt to people that the rest of us have not walked in the shoes of.
You are all in this together: make it work with good relations.
Great article!
But in reality the mindset that the executives of less than 2000 employee company is that with devops, operations simply totally goes away because the developers takes over the operations. It is easier for developers to take over operations than operations to get some coding practice done (developers will not show their code & code design to operations) even if a ops person can code. In the whole devops execution, ops guys (including good ones) get nothing & get fired. The whole devops thing is all about developers gaining more roles & responsibilities & job satisfaction, and is about total elimination of ops team in entirety. That is the truth.
That, to me, means that your dev team doesn’t have enough to do. I’m an applications developer, and there are barely enough hours in the work day for me to do that as well as I’d like. I don’t have time to go do the sysadmin’s job (although I have designed and set up small networks).
This scenario always ends in regret once the things that the developers have built start breaking and the developers have to stop coding to go support them. ‘Far better to do DevOps right, and that requires management to understand what DevOps means.”
Pingback: DevOps theory for beginners – CSC Blogs
Pingback: Docker, SaaS, IT's Role, and Cloud Platforms - In 2015
Pingback: Definition of DevOps and the Definition of “Done” – Quick Links | Agile Advice
Thanks, well explained.
Pingback: DevOps, The Art of Walking in Someone Else's Shoes - The Colorful and Gray World of Engineering Management - Site Home - MSDN Blogs
This is a great article! Thanks for posting it.
I used to work as an IT Operations Manager in a bank between the years 2002 and 2007 and since I had worked as a developer in the early years of my IT career I understood both the Ops and the Dev methods and processes. Yet, both worked in silos and there were always arguments between the two teams when a new or upgraded system was to be put into production. I tried so hard to make the Dev team to try and understand the Ops requirements but they always had the upper hand and Ops would loose out by force. What actually happened was the new/upgraded systems would fail in production because certain Ops requirements were not catered for.
What I don’t understand is why would we have to wait until someone somewhere has to coin a term, “DevOps’ in this case, before the teams realise that they have to work together to ensure a seamless end-to-end process.
Well, it didn’t wait on the term necessarily – but there’s a difference between isolated people trying and a community sharing best practices, so having common language can catalyze change.
Interesting and very relevant thoughts. It makes sense for Ops team to be collaborating more with Dev from start as normally just after the go-live project teams are disbanded and everyone moves to other projects etc. Hence, If the collaboration had been there from the very beginning, it will be easier for Ops team as they would have known what’s coming their way and help them minimise any incidents mean time to resolution (MTTR).
Anwesh
Pingback: New CISSP CBK (after April 15th 2015) « Deepees’s Blog
Pingback: Best Guide to Getting Started In DevOps
How can we relate Devops to IT Infrastructure? Would it be the collaboration between the Build and Operate Teams(both being further segregation of sysadmin; one getting a new server ready and other taking care of it post application Go Live!) or just Infrastructure as a code via any of the configuration management/automation tool? In the second case we can surely reduce the time to deliver the system to the end user but Devops as a concept seems to be missing.
Please let me know your views.
Thanks for the great Article.
In my organisation we are looking into the innovative way of doing operation. Major gaps found is in the expertise level between Operations and the Development. Development team are not completely aware of all the business process where as the Operations never know the coding technology.
We are still working on Dev Ops Model for doing efficient operations.
Pingback: The DevOps interview: What to expect - Cloud2Class Blog
Pingback: 5 Things I’d Tell My Enterprise IT Self | Bryan Friedman: Clouding Up
Pingback: "What is DevOps" - Can you define it?
This is perfect explanation. I liked the way this article is narrated with DevOps.Thanks for writing such wonderful and meaningful article.Also do you have image representation for DevOps? that really helps people to understand quickly
Pingback: TECH::DevOp(inion) – Are we asking IT and developers to become Skynet? | Why Is The Internet Broken?
Pingback: DevOps for non-engineers - DevOps.comDevOps.com
Great article!
It helped me understand better what DevOps is.
Thanks!!
Pingback: Why this top cloud analyst moved to Microsoft | php Technologies
Pingback: Why this top cloud analyst moved to Microsoft - Browser Zone
Pingback: 4.74 Degrees of Separation: Bill Higgins | Social Business Insights Blog
Hmmm. This is ~exactly~ (and I mean exactly) the same job description I had 30 years ago. This is not a new job; this is a forgotten job. Once upon a time, when companies used mainframe, and processes were already mature, we had already solved what you describe here as new. Let’s say “new to you”.
Yeah yeah, nothing is “new” in the computing world, someone has always done it before. However that’s irrelevant, it’s about what is common practice and what is better than common practice. Good on you for already knowing it all, but experience shows that most IT organizations nowadays don’t and are bleeding as a result. Use that knowledge to help…
Pingback: Cloud Building Blocks | cloudit4you
Pingback: Define DevOps: What is DevOps? | On Skylights
Started career as developer and then move to server operations and gain some where in place where managning developement team with operations and Got importance of DEVOPS ….thers a big need for guy who aware of both else things most of time hangs between developer and admin/operations where thy pour things on each other wasting resource and time .
Pingback: Best Guide to Getting Started In DevOps - XebiaLabs
Pingback: DevOps & Cloud: A Match Made in Heaven | Flexiant
Pingback: Vagrant Series » Introduction
Pingback: Innovating: So What Is Possible? | Paul4innovating's Innovation Views
Pingback: What is DevOps? - Daniel Bowlin's SQL Server BI Blog
Pingback: DevOps Nedir? |
Pingback: Devops – Brief explanation | rafazzevedo
Pingback: DevOps is Trending as the New Agile IT Management Methodology : eDiscovery Times
nicely written. Let me know what you think about the DevOps definition I have provided in the following link:
I do like how it notes that you can try to get there via multiple paths, “better collaboration between the silos” and “single agile team busting the silos” – just because you can’t get to agile teams for whatever reason, you can certainly improve collaboration and move towards some of the benefits.
Pingback: Meros: My new venture | Growth Engineering
Pingback: New Definitions Added to the Ultimate ITSM Glossary | Kinetic Vision
Pingback: Why support organizations should care about DevOps |
Pingback: Derk-Jan de Grood
Thanks for wonderful explanation on DevOps…
It’s great to have operations folks involve in requirement analysis & design phase so as to prepare them for production roll out, alert stakeholders on operations requirements early in cycle. It’s also essential for Development folks to have basic understanding of Operational processes/practices.
More collaboration, cultural change with enabling tools for release & deployment would surely help. There is also necessity to have same set of tools to be used in dev & Ops for similar processes such as configuration & executable building etc. This will eliminate issues during production deployments/fixes/code management and Ops & Dev speak in same language.
However, deep multi-skill of Ops & Dev folks in each other’s areas is something not convincing. At the end of day Development folks will have to take deep dive in design & development of solutions and Ops will have to manage steady state. Here respective specialization is surely required. Any thought…
Well, don’t confuse skills with roles. Good production support requires expertise in both systems but also in applications; implementing APM tools and getting dev expertise onto prod support was a huge factor in improving our uptime at NI. Also, you really want dev/test systems to be built in the same way as production. You need proportionately more “traditional dev” skill set in the dev org and proportionately more “traditional ops” skill set when doing system builds but you a) need some of both skill sets throughout the service lifecycle and b) need collaboration between different teams participating in that lifecycle, if the service is so large it requires multiple teams worth of people.
But this is no different than any other subspecialization. In dev we know who the UI specialist, service specialist, really strong DB person, etc. is. But we don’t put them in different groups, we have however many of each we need for the service at hand. Similarly, instead of siloing off ops, the service team needs the right amount of ops expertise to participate in all the phases – and better operational planning in service design means a lot less traditional ops monkey-work with the service in production.
Pingback: Overcoming the IT-Business divide in an era of big data, Part 2 - The Data Roundtable
I find it all a bit weird. I’ve worked in Niche tech consultancies all of my career. It’s the way we have always worked since it gets the job done, quality can be protected and projects get finished and fully operational. If we didn’t work this way we would never get paid. I’ve been to many customers that are struggling to get things done and 1 of the biggest headaches is dev, admins and ops working against each other all hiding behind superfluous paper work and processes.
Pingback: Why Support Organizations Should Care About DevOps | HDI of the Palm Beaches
This is an excellent writeup, which aptly defines the concepts and role of DevOps. What hurdles have you seen in your areas of implementations? Would you suppose its primarily people, process, automation, or architecture? How did you handle those?
Thanks! For that I guess I’d say “see all the other devops articles on this blog,” I’m not sure I can answer all that just in a comment. People issues are always the blocking factor, however; if you don’t have a people problem then any process or tech problem is just a matter of work to resolve/improve. The lack of shared goals and values among contributors to a system is the key failure point and has to be overcome to garner success. Feel free to ask about points you’d like me to expand on in a full post…
Great Article!
I am completely agreed with the thoughts mentioned in the article.
I believe DevOps is CRISP approach with CALMS as its principles and values
CRISP
C – Collaborative way of working between Dev and Ops (One Team – One Goal)
R – Repeatable process using principles and practices to provide better results to deliver the QUALITY and STABLE product/application
I – Iterative and Incremental approach for continuous improvement
S – Saleable across multiple teams of the product
P – People, Principle, Practices and process oriented disciplinary collaborative approach
CLAMS
C – Culture (promotes collaborative and open culture between Dev and Ops)
A – Automation (automate wherever applicable)
L- Learning (continuous learning & experimentation)
M – Measure (Measure with shared metrics across the Dev and ops for better management)
S – Sharing (Shared delivery process across Dev and Ops to build , deploy, maintain and monitor product with mentality of One Team – One Goal)
After all DevOps is collaboration between Dev and Ops using DevOps values, principles, practices and process together to remove the silos and inflexibility and deliver faster and better product to the end user in real sense.
I appreciate this author’s work in bringing definition to what is rapidly becoming a hackneyed term. Let’s face it. The IT community has been flailing for decades, trying to figure out how to apply principles of business operation to what has been for such a long time a community of high-tech artisans. In its meanderings, it has taken comfort in latching onto a term or a phrase more for its iconic than its actual value. The principles underlying the formulation of a phrase are usually lost in the mire created by persons who don’t care to think critically about what it is that they do for a living or how their role fits into a more global view of an enterprise.
At its core, both DevOps and Agile attempt to woo IT professionals out of their silos and to compel them to talk to each other. The compulsive element is not inherent in the Agile or DevOps process itself but rather in the way either is applied. A manager, for instance, who has been won over to the Agile side of the fence, may choose to employ stand-up meetings, planning poker, and the like, thinking that by requiring his charges to participate, eventually they will see the benefits therefrom. In my experience, it doesn’t happen that way. Application developers, who are herded into a conference room where they are prohibited from sitting while having to listen to their peers repeat mechanically that there are no impediments to getting their work done, usually grouse about having to waste their time doing nothing constructive. They do, after all, have sprint deadlines to meet. Perhaps it would play itself out differently if the minions of IT were treated like valued collaborators instead of easily replaceable cogs in a machine. Nothing breeds contempt faster than being sold a new way of doing things by those who still have a sweatshop management mentality.
For reasons that have little to do with the style of project management employed, the IT world should not be expected to sing “Kum ba yah” anytime soon. At the heart of IT’s problems lies the way that IT management makes choices – choices about hardware, choices about software tools, choices about how it measures value, choices about how it values people. I cannot begin to count the number of IT departments whose applications have been written in a hodgepodge of development languages, which were often selected because a programmer thought that one particular language or another was “cool.” The evidence of this polyglot presence can be seen by simply reading job listings on any of the popular job boards. An advertisement for an application developer might stipulate that the successful applicant must have expert capability in VB6, C#/VB.NET, Python, J2EE, WebLogic, IIS, SAS, Oracle, SQL Server, MySQL…the list goes on and on. What does such a description say about the management of an IT department other than that it has been managed poorly by allowing itself to be pulled first in one direction and then another by the fashions of technology and the smooth talk of sales people? Yes, technology changes, but it is up to those who manage IT departments to discern when changes merit the investment of corporate resources. Too often, that discernment is lacking.
When IT departments are comprised of persons who ply their trades using different technical languages and concerns, should it surprise anyone that cooperation has to be coerced? It’s easy to slip into us-versus-them when there are real reasons to do so. So when a methodology comes along, like Agile or DevOps, that holds the promise that it can overcome the unmanageable, it is no wonder that the very words “Agile” and “DevOps” become imbued with near mythical properties.
Agile and DevOps can bring real value to companies. Of that, there should be no doubt, but the precursor to the adoption of any new project management method should be a focus on fixing the problems of how companies are managed and how people communicate with each other.
A person whom I greatly respect gave me a definition of communication that I have remembered for a very long time. He told me that communication does not occur when Joe delivers a directive to Tim. Communication also does not occur when Joe says something to Tim and then waits to hear Tim echo back the same words. Communication, he said, only occurs when Joe says something to Tim and then can feel within himself how Tim feels when Tim hears Joe’s words and understands their meaning and their intent. If companies relied more on that kind of communication instead of bulletins pinned to a wall, mass email messages sent out to employees, or other artifices that require no personal investment in the success of another, perhaps the principles of Agile and DevOps would seem to be the natural things to implement.
Pingback: Top DevOps Meetups - 49 Meetups For DevOps Pros
Correct me if I’m wrong but it seems more appropriate for large enterprise software. Kind of an overkill and too complicated if we only to mid size software like mobile applications.
You’re wrong… It’s a lot easier to do DevOps in smaller teams (fewer barriers to collaboration); one of my first DevOps gigs was with a single small team. But pretty much any group of techies above about 1 person can suffer from bottlenecks, poor communication, sloppy manual work instead of automation, etc. None of this has anything to do with scale except in that implementation can have special challenges at scale (like Agile).
Pingback: Software Subculture Part 2: DevOps – 201 Digital
Pingback: What’s happening in Service Management in 2016? | Camford MC
How does DevOps fit into “Shift Left” testing methodologies? In addition, how would DevOps look in a Waterfall methodology?
I’m working with a QA team now so expect some full articles on that topic! As to what it would look like in waterfall, it’d look much like it does anyway, just with a handicap from the impediments to everyday collaboration that waterfall produces. When the agile admins were all at NI, we came up with a pre-DevOps implementation that we used in a waterfall shop – a systems development process that we shared with our dev team that set collaboration points from the SDLC design phase on, documented a bunch of concerns for them to take into account early (auth, resiliency, backups, etc…). We also implemented a lot of automation and tools that bridged dev and ops (Splunk for sharing logs, Opnet Panorama as an APM tool to give devs production views into app problems). We got business buyin to the concept that availability, performance, etc. were a shared goal they expected all teams to deliver. It helped out our performance, uptime, etc. a good bit, but it was still very labor intensive. When we got to do it in an agile team it was about 200% more effective, however.
Some of the shortfall was process, though some was just understaffing – if we had one devops engineer per dev team, plus a group of three or so for automation development, we probably could have closer approached where we needed to be. But in waterfall/shared services organizations that never happens – “six admins for 12 dev teams, that seems like enough, despite the fact that even the dev teams say that’s where the bottleneck is” – and you get blockages. The organizational and budgetary structures that tend to come with a waterfall organization basically guarantee waste and bottlenecks. Doing some Lean analysis (value stream mapping etc.) might provide data as ammo to alleviate some of that without a structure change. But a job change is always also an option.
Pingback: What we can learn from the iOS update that bricked iPhones - test IO blog
Pingback: DevOps, Burnout, and the Search for the Holy Grail – paulsbruce.io (input) => output
Pingback: DevOps OV – gav100
Pingback: Who Are These Developers Anyway? – From Chemistry to Clouds
Pingback: Using Docker commands to manage Windows Server 2016 Containers - 4sysops
Pingback: ¿Qué diferencias hay entre Dev y DevOps? - Guiadev
This is an amazing article!! If there is no buy in for DevOps from all concerned parties you can aggravate what is already a very fragile situation between Devs and Ops. Management, if they are interested not just in lining their pockets, needs to adapt to this DevOps principle. At same time there needs to be balance and pragmatism on implementing it.
Pingback: DevOps – Traditional and Modern Approaches - MSys
Pingback: Impact on DevOps – Successful Outsourcing - Haut Tech
Pingback: Trick Question: What is DevOps? - DevOps.com
Not surprising to see such a complex essay from a Systems person. The view from a programmer perspective is much simpler. DevOps is a name for a problem. The Dev is not an adective, i.e. DevOps as a type of Ops. It is a label meant to speak to legacy enterprise IT organizations, delivering the message that an 80/20 funding split between organizationally separate Operations and Applications groups is suicide. As computing systems and infrastructure become more software-defined, they actually allow more clear interface and isolation of an application from the physical system and infrastructure, allowing software development to scale and deploy without any requirement of a system administrator. The environment in which software runs is logical, software defined, virtual…. DevOps refers to a business problem where the coupling between physical systems and software has become entrenched, presumably by the legacy Ops/Apps enterprise IT model, and the Ops folks are too big, too old, not programmers, etc. Thus preventing a healthy abstracted environment from appearing in the Apps platform. There will always be physical computing systems and infrastructure, and now systems administration will support the software infrastructure that provides the programming teams with an logical environment that they control. But both development and deployment of software, and configuration of the logical system and infrastructure, now become Apps issues. Hence the 80/20 Ops/Apps IT organizations need to adapt. Ops focus changing to include design, dev, and delivery and support of the logical systems and infrastructure. Apps focus changing to include design, configuration of systems environment and dependencies, and deployment. User support is more likely traced back to the application team, since system and infrastructure are better controlled. Hence expect system administrator to have less time dealing with end users, and more time addressing design concerns and technologies behind the logical systems, and new needs like increasing reliability of the physical configuration at scale, through automation tools.
Pingback: An Overview of DevOps - Rich Murphy Writes
Hi iam a Oracle Dba
Could u Plz tell me , Dev-ops suitable for me r not.
if yes,plz tell me pre-requisites for Dev-ops
Pingback: Intro to DevOps – JBoss Middleware Blog
Some people said that philosophy will be dead because of The Mathematics. But there’s still Agile and DevOps authors making philosophy exist.
Could you provide author/year info for people who’d like to cite this? Thanks!
Oh sure, I guess it doesn’t show since it’s a page and not a post. It’s by me, Ernest Mueller, originally published Aug 2, 2010 but revised various times since then.
Very good Article !! Provides a very good relation between DevOps and Agile .. And the real time challenges/issues posted by all also helps as a guidance for us as we are also entering the DevOps world !!
Pingback: 3 challenges facing telecom operators in shift to devops – RCR Wireless News | Farmissy
Hi..I am hearing about Devops but i did not understand “what is Devops”. I have 2 years of working experience as PHP Developer and i had completed my software testing training. So i have software testing knowledge. I want to take Devops Training. Can you suggest me, “Is it right to do the training?”. Please Suggest Me..
Pingback: ZK Research » Posts » Step Up Your Digital Game with Team Collaboration
Pingback: Can DevOps and Remote Work learn from each other? - Dreaming in DevOps
Pingback: Episode 46 – Is DevOps a good career for me?
Pingback: Tech Culture Series: Being Technical in the Tech Space - Geek Moms & Company
Pingback: A sneak peak into how we build the Planday product: Part I - Planday
Pingback: DevOps Scares Me - Part 1 | AppDynamics | The APM Blog
DevOps, similar to Agile and its various flavors, is quite childish and a very immature approach/method/philosophy to the technology space. Its popular for sure, but I equate its popularity to the snowflake culture that has and is invading tech. Look at me, recognize me, adore me, I’m so great and need a new title. Any resumes/CV’s with “devops” listed are first to the trash bin. Give me real tech folks, dirtied and soiled hands, battle-scarred and hungry for more without the need for such pampering terms. It’s called get ‘er done and guess what, it’s get it done right or get out. No thanks. Interestingly, at many of the professional conferences, this is looked at, along with agile, as a very sad state of affairs.
I would like to strongly disagree to that. Rather devs with “dev ops” tag are moved to the top of the list and not to the trash. It’s not necessarily that developers have to battle out in tbe battlefield. DevOps is just the solution to avoid this battle and ensure smooth integration and delivery of software. This is done so that devs can be more busy at researching new stuffs and writing logics that matter.
Thanks
Pingback: 5 Project Management Developments for 2017 | The Fast Track
Pingback: Data Science and DevOps: A Success Story - Blue Yonder Technology Blog
Pingback: A sneak peak into how we build the Planday product: Part I
Pingback: Practical Octopus Deploy - Introduction | Russ Warner
DevOps is useful and new generation web, full stack developers… working on different IT infrastructure (cloud based containers & machines) and programming in different (many) languages, and compute different databases… 🙂
It is the best article I’ve read about DevOps. Fantastic!
Nice article thanks
I’m in customer service – a very operational role – but with a fascination for coding and orchestration.
I learned terms like “test driven development” existed after i already naturally applied it.
DevOps can increase the savviness of especially millinials in operations even those with limited or no interest in technical.
Pingback: Mystery of DevOps - Codeogre
Pingback: What is DevOps? – TechyBob.com
Pingback: A practical approach to DevOps adoption -
Nice approach to describe DevOps. I would say that DevOps is a modern approach on application lifecycle management that has many connections and it is trying to further This article is a due clarification of some common misunderstanding that random business and marketing campaign spread everywhere.
Pingback: Web Application Security: The New Way Forward – Marlax Technologies Bangladesh
Pingback: IDG Contributor Network: The evolution of devops from ‘Kumbaya’ to value | Newz
One thing I didn’t see here that I think is a very important part of DevOps is to have the developers design for deployment. I think of this as the next step beyond TDD; before you write the code, you write the tests, but before you write the tests, you write the deployment tools (or at least have a good sense of how they’re going to work).
Taking deployment into account from the start has a huge an effect on design as does taking automated testing into account from the start.
This can be a pretty hard sell, of course, especially in organizations where they replace the “Ops Department” sign with “DevOps Department,” add a few tools like Chef or CloudFormation, and think they’re done.
Pingback: How we’re deploying agile practices at Gemalto – Data Core Systems
Pingback: Why a DevOps culture is important to ECS Digital - ECS Digital
Pingback: Should you become a DevOps engineer? | Logz.io
Thanks for this great article. I am finally working in a new shop that is doing Agile and the term DevOps seems to get thrown around quite a bit. Next time it is used I am going to see if it makes sense and if not ask the person to clarify. Lots of new terms in the new role but also trying to grasp Agile better first hand. I had a good high level understanding before. I have share this with a co-worker and also shared this on my LinkedIn page.
Pingback: DevOps In the Wild – LaunchCode Blog
Pingback: What does DevOps really mean? part 3 | IntegrationQA
Pingback: 5 DevOps Terms That We All Use, Yet No One Can Define - DevOps.com
Pingback: Web Application Security: The New Way Forward - Signal Sciences
I have never seen two people that describe “DevOps” exactly the same! The DevOps mindset has a really wide spectrum and requires a multi-disciplinary understanding to be able to provide real solutions for real problems.
Well and here is my DevOps definition: “DevOps is the cement that holds the bricks of software development together.”
Nice explanation about devops