http://www.grahamlea.com/2013/02/what-is-devops-in-bullet-points-quotes-and-tweets/
For me, I don't think that DevOps is as much a "cultural movement" as it is a logical response to changes in the market, so here are my bullets:
- "Shrink-wrap Software" left engineering groups believing that software needs to be damn near perfect before you can ship it.
- "Perfect" software has always been as mythical as unicorns and leprechauns, and chasing it has always been a fallacy.
- It's known that buggy, crappy software doesn't sell (without massive marketing efforts).
- SaaS has changed the way engineers can think about the "perfection" level of their software.
- It's easier to fix bugs, apply security updates, add features, etc., if your software is running on machines you control and not buried behind firewalls in the inner sanctum of an enterprise data center.
- Most engineers cannot be trusted to have unfettered access to change software, once deployed into production. No offense intended, but if you're offended, I was probably talking about you.
- Even if "most" were "some" or even "occasionally", you still can't identify which ones can be trusted and which ones can't, so you have to build process and access firewalls to protect your operational service platforms.
- You need people with the "operations mentality":
- motivated by successful delivery of a service
- enchanted with thoughts of high availability and service resilience in the face of every variable that could change
- paranoid that anything that could go wrong, will
- Things in data centers (or the cloud) tend to go wrong when humans are responsible for changing things.
- Classic "operations" techs/engineers have been more focused on infrastructure, networks, physical security, server hardware, etc. -- all of which you now inherit or are no longer material as services move to "the cloud".
- Agile development practices are shifting teams away from building "products" and toward building "service features". This more modular approach means you have the option to consider releasing features independently of "product releases".
- Some companies are releasing changes to their services multiple times a day. Whether you use it or not, having the ability to do multiple releases a day is VERY VALUABLE!
- Consider only the bug fix scenario — VERY VALUABLE!
- All of these changes in IT, development practices, market expectations, and product delivery combine to force companies to reconsider how they deliver their software-based products and/or services
- Reconsidering is necessary only for the existing, transitioning company. Start-ups are viewing this brave new world as a massive removal of barriers to entry in even the biggest and most complex marketplaces.
- Start-ups are looking at this new world order not as "How do my staffing needs change?" but rather as "What minimal functions do I need in my organization to guarantee that my customers can get to their service in almost any situation?"
- DevOps largely incorporates those minimal functions into a role.
- What are the responsibilities of a real DevOps team?
- Procedurally keep the developers from making arbitrary changes whenever they feel like it.
- Understand how "servers" get deployed in the infrastructure that you're using (e.g., Amazon cloud, Rackspace cloud, physical hardware in a hosted data center, virtual machines in a VMware virtual center, etc.), know that server deployment is part of the job, and figure out how to make it as easy and repeatable as possible.
- Understand how applications get deployed on servers deployed in the infrastructure and know that you have to do this a lot. Work with development to get a comprehensive understanding of the app and figure out how to make it as easy and repeatable as possible.
- Know enough about system administration, network administration and application administration to be able to configure your infrastructure appropriately — and troubleshoot typical problems
- Know the application(s), its dependencies, its features, its idiosyncrasies, its performance, its behavior and how to make it sing
- Know how to monitor the application — while running — and the infrastructure it's dependent on to be able to detect anomalies quickly and ultimately, to detect impending problems before they happen (using predictive indicators — it ain't magic, it's science).
- And most importantly, embrace the fact that you've been given an application that's been built and blessed by development, tested and blessed by QA, and accepted by you and your peers as the new basis for the service that you are responsible for running 7x24x365 at 99.999% availability (and note: The .001% downtime must be scheduled.)
