DevOps started out as “Agile Systems Administration”. In 2008, Andrew Shafer did a talk called “Agile Infrastructure” addressing issues around involving more of the company in the same disciplines as programmers.
In 2009, Patrick Debois created “DevOpsDays” conference to help to bring it to light. However, it wouldn’t begin to trend until about 2010, when people would begin to describe it as a standalone discipline.
Today, DevOps goes beyond just developers, systems administration and infrastructure, its about dev, ops, agile, cloud, open source and business, everything.
DevOps is a movement. There’s no certificate, role, set of tools or prescriptive process. There’s no specification, it’s not a product, or job title. There’s no one true voice on what DevOps is or isn’t. It’s about attitude, ideas, customs and behaviours. Culture, paradigms and philosophy. It’s a way of thinking, a way of doing and a way of being. Practicing as well as preaching. It’s a conversation. It’s about taking the best experiences and sharing those with others.
Author of this article here! I definitely want to know if there's anything anyone thinks I missed - I wound up doing a pretty deep dive into how "DevOps" is being defined and applied, but it was largely from the perspective of people hiring, and I suspect that people with different perspectives will also have different opinions.
That (or something like that) does tend to the accepted definition of DevOps! The problem is that it's a rather abstract definition, and there isn't a lot of consensus on how to apply it.
Perhaps because it sounds like a corporate mission statement? So vague and open to interpretation, it is practically meaningless.
Let's talk about what DevOps means in the real world: cloud infrastructure operations, systems administration, automation / scripting, continuous integration / deployment, etc.
This takes a variety of forms.
Type A company: Embeds "DevOps" folks working side-by-side with other engineers.
Type B company: It has a dedicated "DevOps team" which is siloed. Requests are routed and responded to in an untimely manner, just like the IT/IS departments of old.
Type C company: Developers are expected to pick up infrastructure stuff as they go along. "Devs doing Ops."
Amazon has been doing a version of DevOps for almost two decades due to the convergence of several of Amazon's core concepts: the Two-Pizza Team, the "Ownership" leadership principle in action (relatively large amount of freedom for a team to do whatever it needs to succeed), an internal mandate for Service-Oriented architecture, and developers holding the pager for their own work (again, Ownership).
This effectively meant that a small team was completely responsible for the design, development, implementation, testing, deployment, and real-time support of a service that provided unique capabilities to the rest of the company or to customers. It created a STRONG incentive to test because if your team's service failed, the team's developers would be paged (frequently in the middle of the night) to immediately fix the service and get it working again.
Development teams have access to a mature set of tools and infrastructure that make it relatively easy to move very quickly to design, develop, test, and deploy services to production as fast as the team is able to.
8 comments
[ 27.3 ms ] story [ 1315 ms ] threadIn 2009, Patrick Debois created “DevOpsDays” conference to help to bring it to light. However, it wouldn’t begin to trend until about 2010, when people would begin to describe it as a standalone discipline.
Today, DevOps goes beyond just developers, systems administration and infrastructure, its about dev, ops, agile, cloud, open source and business, everything.
DevOps is a movement. There’s no certificate, role, set of tools or prescriptive process. There’s no specification, it’s not a product, or job title. There’s no one true voice on what DevOps is or isn’t. It’s about attitude, ideas, customs and behaviours. Culture, paradigms and philosophy. It’s a way of thinking, a way of doing and a way of being. Practicing as well as preaching. It’s a conversation. It’s about taking the best experiences and sharing those with others.
"DevOps is the union of people, process, and products to enable continuous delivery of value to our end users."
Let's talk about what DevOps means in the real world: cloud infrastructure operations, systems administration, automation / scripting, continuous integration / deployment, etc.
This takes a variety of forms.
Type A company: Embeds "DevOps" folks working side-by-side with other engineers.
Type B company: It has a dedicated "DevOps team" which is siloed. Requests are routed and responded to in an untimely manner, just like the IT/IS departments of old.
Type C company: Developers are expected to pick up infrastructure stuff as they go along. "Devs doing Ops."
Others I've missed...
This effectively meant that a small team was completely responsible for the design, development, implementation, testing, deployment, and real-time support of a service that provided unique capabilities to the rest of the company or to customers. It created a STRONG incentive to test because if your team's service failed, the team's developers would be paged (frequently in the middle of the night) to immediately fix the service and get it working again.
Development teams have access to a mature set of tools and infrastructure that make it relatively easy to move very quickly to design, develop, test, and deploy services to production as fast as the team is able to.