Seven Cloud Sins of DevOps
0 likes303 views
The document outlines seven anti-patterns, referred to as 'sins', in the context of DevOps practices, providing solutions for each. These sins include issues like 'lust', 'gluttony', and 'greed', with proposed fixes such as effective resource allocation, measuring infrastructure utilization, and encouraging collaboration. The aim is to foster better decision-making and implementation strategies while emphasizing the importance of honesty and practicality.
![About me
{
“First name”: “Taras”,
“Last name”: “Slipets”,
“Occupation”: “Senior Software Engineer”,
“Company”: “Flixbus”,
“Interests”: [
“Software Engineering”,
“Music”,
“Skiing”
]
}
45](https://image.slidesharecdn.com/sevencloudsinsofdevops-191125092037/85/Seven-Cloud-Sins-of-DevOps-45-320.jpg)
Seven Cloud Sins of DevOps
- 1. Seven Cloud Sins of DevOps
- 3. 3 What we will talk about
- 4. Agenda ● 7 “sins” - 7 anti-patterns ○ Name ○ Case ○ Explanation ○ Fix ● Summary and Q&A 4
- 5. #1: Lust 5
- 6. 6 Data Scientist - The Sexiest Job of the 21st Century October 2012
- 7. 7
- 8. 8
- 9. Ways to fix ● Sharpen your real business cases for ML/AI ● Analyse which AWS services are already in place to serve your actual needs ● Explicitly allocate both development and infrastructure resources for R&D incubation projects ● Measure an impact periodically and adjust the plan 9
- 10. #2: Gluttony 10
- 11. 11
- 13. When you actually need 13 https://medium.com/employbl/tutorial-for-building-a-web-application-with-amazon-s3-lambda-dynamodb-and-api-gateway-6d3ddf77f15a
- 15. Ways to fix ● Measure your infrastructure REAL utilisation ● Use existing out-of-the-box tools ● Use integration with Ops monitoring and alerting tools ● Use resources utilisation forecasting feature 15
- 16. #3: Greed 16
- 20. Ways to fix ● Leave room for manual experiments ● Encourage learning from each other ● Use out-of-the-box tools for security audit in the Cloud ● Design and build your systems with security in mind 20
- 21. #4: Sloth 21
- 22. All works in our manually setup VMs 22
- 23. Why move to containers or k8s? 23
- 24. 24
- 26. Ways to fix ● Load testing ● Configure auto-scaling ● Configure resource utilisation costs thresholds and alarms ● Chaos engineering is a big plus 26
- 27. #5: Wrath 27
- 28. CTO has just returned from a conference 28
- 29. Why we still use those old services? 29 https://dilbert.com/strip/2014-02-02#disqus_comments
- 30. Ways to fix ● Don’t make emotional decisions ● Do practical PoC to compare existing solutions with suggested ● Talk in numbers and money 30
- 31. #6: Envy 31
- 32. 32
- 33. Let’s move to another Cloud provider 33 Icon made by https://www.flaticon.com/authors/eucalyp
- 34. It’s cheaper 34
- 35. Is it really cheaper? ● Infrastructure costs ● Education costs ● Migration costs ● Development costs 35
- 36. Ways to fix ● Consciously (re)evaluate your actual business cases ● Compare costs for single cloud provider vs heterogeneous Cloud ● Be honest to yourself - include costs and efforts for the team to learn, install and use new tech stacks 36
- 37. #7: Pride 37
- 38. We are the smartest team in the world 38
- 39. We can implement everything on our own 39
- 40. Are you really smarter? 40
- 41. Ok, if you really are 41
- 42. Ways to fix ● Investigate existing tools before start your own implementation ● Compare multiple potential solutions options ● Manage expectations ● Deal with “brilliant jerks” on individual level 42
- 43. Summary ● Get full context ● Measure before improve ● Listen to advices, but tailor tools to your needs ● Do not make emotional decisions ● Be honest to yourself 43
- 44. Q&A 44
- 45. About me { “First name”: “Taras”, “Last name”: “Slipets”, “Occupation”: “Senior Software Engineer”, “Company”: “Flixbus”, “Interests”: [ “Software Engineering”, “Music”, “Skiing” ] } 45