Are You Dev'ing the Right Ops

This is a DevOps talk by someone who'll often proclaim "I don't believe in DevOps" to dig deeper into the conversation about what does DevOps actually mean.
Instead of focusing on tools and cool tech we need to focus on our teams building the best software they possibly can. Sometimes this means not playing with the "bright, shiny" or building it just because we can. Our workloads live at different levels of abstraction, and we should understand how to run them with the minimal amount of DevOps work. Avoid the yak shave and dev only the right ops.

Delivered at ConFoo 2019 in Montréal.

Transcript

1. Are You Dev’ing The Right Ops Chuck D’Antonio @crdant
2. About Me • Platform architect at Pivotal • 24 years in technology • Primarily development, architecture, and management experience • First job as a network and systems administrator (along with webmaster, desk side support, DBA…) • Father of 2(+1) • Ambitious home cook and bartender • Open water swimmer
3. This is a DevOps talk… …by (and for) someone who doesn’t believe in DevOps (the way lots of people use it)
4. What DevOps Doesn’t Mean to Me A New Team or Job* A New Name for Old Jobs Bright, Shiny Toys If you don’t change the way your team works, you won’t get any benefit You need to know what’s new and exciting, but not deliver all of it We’re not looking for a DevOps team full of DevOps Engineers *I’ll make an exception for SREs
5. What DevOps Means to Me • Value ease of administration and troubleshooting • Implement extensive telemetry • Build and deploy platforms to enable developer self-service Use techniques that allow developers to deliver faster and higher quality systems to improve operations Collaboration Between Developers & Operators CHARACTERISTICS CHARACTERISTICS CHARACTERISTICS • Agile development methods • Lean product management • Shared ownership • Infrastructure changes as version-controlled code • A cultural change not a technological fix • Favor direct communication • Include operations experience in balanced teams Eliminate the wall between teams that build systems and teams that operate so that production is painless Teams consider build features into their products that make them easier to operate and troubleshoot. Applying Development Ideas to Operations Building Software that’s Easier to Operate
6. Agile Doesn’t Have a Brain • WHICH features should we build? • DID we build the right ones? • DID we design them well? • DID we optimize them to achieve maximum value for our customers and our business? https://www.jeffgothelf.com/blog/agile-doesnt-have-a-brain/ DevOps SRE
7. How do we give it a brain?
9. Products… Projects… • Succeed when they deliver value to our business • Succeed when they meet a negotiated scope • Start their lives when they go into production • End their lives when they go into production • Continue to evolve and add business value • Stop evolving after the project is declared “done” • Are a collaboration between users and product team • Are a negotiation between “IT” and “the business” • Focus on understanding and solving the problem • Focus on delivering on- time and on-budget • Cohesive team that manages product until product is discontinued • Team formed to deliver project and then disbanded Products, Not Projects A Product-Oriented Approach • Driven by customer and business value, quick feedback loops and iteration • Understand and solve the underlying problem rather than addressing the symptoms • Focus on incrementally delivering a “whole product” including improved business process, new business opportunities, and reduced costs • Forge relationships that enables new business value with improved product offerings • Keep teams together and focused on the product for its entire lifetime
10. Lean Product Process MVP Data Pivot or Persevere Idea Build Measure Learn Generate
11. Balanced Product Teams Desireability Will users want to use this product? Feasibility Can this product be built and maintained. Viability Is there a market for this product? Product
 Management Product
 Design Engineering Empathy Value Quality Product
12. Some Ideas for Your Products Platform Uptime Anti-Fragility A baseline level of uptime and reliability that teams can expect on regardless of infrastructure guarantees FEATURES FEATURES FEATURES Provide a common foundation for software delivery and management across the organization Your systems should get stronger in the face of failure. Inject failure into your environment to improve it. • Invest in chaos engineering • Inject failure into everything whether you build it or not • Support product team failure testing and resiliency planning • Build redundancy to improve on infrastructure SLAs • Focus in mean team to recovery over reducing failures • Includes triage and support • This is more than just a runtime • Standardize the things that matter and leave the things that don’t flexible • Minimize what developers need to thing about
13. Deployment Abstractions Bare Metal Virtual Machine Container Application Function
14. Container Orchestrator CONTAINER How the runtime influences your work Developer Provides Application
 Platform APPLICATION Serverless Functions FUNCTION IaaS ORCHESTRATOR CONTAINER IMAGES, 
 BUILD & REGISTRY CONTAINER SECURITY MONITORING & LOGGING Operator Maintains APPLICATION PLATFORM APPLICATION SECURITY FUNCTION RUNTIME Container Scheduling Primitives for Network, Routing, Logs & Metrics Tool Provides Container Orchestrator Application Platform Container Image & build L7 Network & Routing Logs, Metrics, Monitoring Services Marketplace Team, Quotas & Usage Function scheduling Function exec services Container Orchestrator
15. Which abstractions should you support?
16. Ask Your Product Teams
17. • Lightweight event responses • Services with sporadic demand • Simple scheduled/batch tasks Long running processes with relatively standardized loads. Containers GUIDELINES GUIDELINES GUIDELINES Workload Characteristics • Interactive applications • Long running event flows • Microservices • Extensive batch tasks • Internally managed persistence • Custom networking needs • Assumptions about file system • Commercial packages Services that require explicit control over their operating environment Short running processes that have unpredictable workloads. Applications Functions
19. When Should I Take On This Responsibility Core Domain Essential for you to differentiate and generate value Supporting Domain Essential for you to differentiate and generate value Generic Domain Non value add Build It Perfectly Invest in getting your core domains absolutely perfect Build Just Enough Invest in something “good enough” for your teams Buy It Minimize your team’s investment of time and energy
20. How do we know what features to add to the platform?
21. Ask Your Product Teams
22. Evolving Capabilities as Products Enable Productize Champion TRIGGER Initial teams TRIGGER Demand increases and you need to scale out your capabilities TRIGGER Multiple teams across the organization RESPONSIBILITIES Identify demand Define a roadmap Support emerging teams RESPONSIBILITIES Enhance capabilities Provide expertise Transfer skills and knowledge RESPONSIBILITIES Continue to evolve products Targeted coaching and support Simplify self-service