DevOps
- Way of thinking
- Job title
- Set of tools
- Automation
- An outgrowth of Agile development
What has changed?
- Benefits of agile development also useful for operations
- Changes in operating environments are occurring more frequently due to security and cost considerations
- Difficult to predict how software will perform at scale
- Continual delivery
Process Model Characteristics
- Heavyweight vs. Lightweight
- Planning vs. Doing
- Efficiency (skillset, personnel, time to market)
- Single vs. Multiple passes
- Role of Maintenance
- View of Evolution
Waterfall Model
- Heavyweight, single-pass, strong planning-based approach
- The "Big Bang" approach described in Head First book exhibits similar
characteristics
- Extreme amounts of time spent on planning compared to implementation
- Each phase is completed and verified before the start of another phase
- Personnel become experts in individual phases
- Formal artifacts required for each step
- Feedback to the previous step
Traditional Operations Environment
- Complete requirements are gathered before starting any part of the project
- Large updates, changes
- Measuring productivity by "bugs fixed", e.g., tickets/issues closed
- Large initial investment in resources (hardware, software, personnel) before any results
- Manager-directed teams
- What does this sound like?
Prototyping
- Idea: It is difficult to determine requirements without a running
system, so build a prototype to get the requirements
- "Build one to throw away"
- Develop the first version cheaply: Very high-level languages, fewer
features (particularly non-functional requirements of speed,
robustness, quality)
- Heavyweight, two-pass approach with more feedback
- Good idea, but not good enough. It is still necessary to gather all
requirements during the prototype
- Another issue: perception of a prototype as a completed system
Agile Methods
- Lightweight, doing (vs. planning), multiple pass, evolutionary approach
- Strongly iterative and evolutionary
- "World is fundamentally chaotic", "Change is inevitable", "Deliver value to the customer"
- Individuals and interactions are more important than processes
and tools
- Working software is more important than comprehensive
documentation
- Customer collaboration is more important than contract
negotiation
- Responding to change is more important than following a plan
Agile Operations
- Welcome change in requirements/functions
- Deliver working software frequently with new functionality
- Self-organizing teams
- Developers work directly with other parts of the company
- Measure progress by the amount of functionality
Reality for Development
- Companies are already following an agile (e.g., iterative) process
- Companies think they are following an agile (e.g., iterative) process
- Companies want to be following an agile (e.g., iterative) process
Reality for Operations
- Few companies are already following an agile (e.g., iterative) process for operations
- Some companies would like to convert to an agile (e.g., iterative) process for operations
- Most companies are following a waterfall (e.g., non-iterative) process for operations
Why?
- Many operations processes grew out of an ad-hoc approach
- Many operators do not have a formal background that would even include agile
- Operation tends to be managed (and follow) what the rest of the company does, which tends not to be agile
- Operators are often trained in fields where agile is not discussed
- Resistance to change and change is more difficult in operations, e.g., threatens jobs