Downloaded 85 times
Uploaded byUwe Friedrichsen
Devops for Developers
The document outlines how developers can create applications that meet operational needs, emphasizing principles of manageability, resilience, and transparency. It details the top needs of system administrators and the main challenges developers face, as well as providing eleven design principles for devops-ready applications. The emphasis is on understanding both developer and admin perspectives to enhance application functionality and operational efficiency.
More Related Content
Devops for Developers
- 1. Devops for Developers HowDev can write applications ready for Ops Uwe Friedrichsen, codecentric AG, 2013-2014
- 2. @ufried Uwe Friedrichsen |uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com
- 3.
- 4.
- 5. It‘s all aboutproduction!
- 6.
- 7.
- 8. Admin Closer to RealityPoint of View
- 9. Top 5 Needsof an Admin 1. Give me my peace and quiet! 2. Don‘t make me think! 3. Let me see that everything is fine! 4. Show me the problem – now! 5. Tell me what to do!
- 10. Top 5 Needsof an Admin (translated) 1. Give me my peace and quiet! (The application should just run smoothly) 2. Don‘t make me think! (Rollout, setup and operation of the application should be easy) 3. Let me see that everything is fine! (The application should show its state) 4. Show me the problem – now! (The application should provide concise error messages and enable easy root cause drilldown) 5. Tell me what to do! (The application should be documented properly – including error handling instructions)
- 11. Top 3 DevChallenges 1. Manageability 2. Resilience 3. Transparency 4. Documentation
- 12. 11 Design Principles forDevOps-ready Applications • Manageability (4) • Resilience (5) • Transparency (2)
- 13.
- 14.
- 15. • One-click deployment • Preserve settings • Provide rollbacks (or roll-forward)
- 16.
- 17. • Avoid multipleconfiguration procedures • Define default value handling • Organize change traceability • Notification about new parameters
- 18.
- 19. • Context-related parameters Donot stage – managed by stage admin • Application-related parameters Must be staged – managed by application admin • Business-related parameters Must be staged – managed by business admin
- 20.
- 21. • Think aboutbackup purpose • Define backup strategy • Provide tooling
- 22.
- 23.
- 24. • Divide systemin failure units • Isolate failure units • Define fallback strategy
- 25.
- 26. • Elaborate usecase Minimize MTTR / scale transactions / handle response errors / … • Define routing & balancing strategy Round robin / master-slave / fan-out & quickest one wins / … • Consider admin involvement Automatic vs. manual / notification – monitoring / …
- 27.
- 28. • Isolate failureunits (complements bulkheads) • Go asynchronous wherever possible • Use timeouts & circuit breakers • Make actions idempotent
- 29.
- 30. • What willyou do if a request fails? • Consider failure handling from the very beginning • Supplement with general failure handling strategies
- 31.
- 32. • Define scalingstrategy • Think full stack • Apply D-I-D rule • Design for elasticity
- 33.
- 34.
- 35. • Think aboutrequired metrics • Design hook or event mechanism • Plan for changing metrics • Consider event sourcing
- 36.
- 37. • Consider logmessage structure All required information / machine readable / human readable • Define logging policy Debug and less: developers perspective / Info and more: operations perspective
- 38. 11 Design Principles • Manageability • Deployment • Configuration • Configuration Parameter Types • Backup • Resilience • Bulkheads • Redundancy • Loose Coupling • Fallbacks • Scalability • Transparency • Monitoring • Logging
- 39. Wrap-up • Dev oftendoes not know Ops • Know the needs of an admin • Face the challenges for a developer • Apply the design principles … and then you‘re ready for DevOps
- 40. @ufried Uwe Friedrichsen |uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com