High Performance Tips for Building Applications in the Cloud

Or, How I learned to stop worrying and deployed on a Friday.

Transcript

1. Building applications in the cloud High performance tips Branislav Bujisic
2. Or, How I learned to stop worrying and deployed on a Friday.
4. What is High Performance?
6. Bruce McLaren (1937-1970)
9. What is the best-selling car of all time?
11. Eiji Toyoda (1913-2013)
12. Kaizen (改善) “improvement”
13. Improvement over Innovation Process over Creativity
14. Plan Do Check Adjust https://commons.wikimedia.org/wiki/File:PDCA-Multi-Loop.png
15. Elimination of waste • Effort • Duplication • Errors
16. High performance is the ability to execute quickly, consistently, and in a sustained way to reduce waste
17. High performance in the cloud Can we measure it?
18. High-performers deploy more frequently
19. High vs low High Medium Low Deploy Frequency More than once per day Once a week to once a month Once a week to once a month (but less often) Lead time Less than one hour One week to a month One week to a month (but less often) Mean Time to Recover Less than one hour Less than one day One day to one week
20. 96x High-performers recover faster.
21. How do you get there?
22. Steps to the cloud 1. Modern Technology Skillset 2. Update development practices 3. Normalize and standardize 4. Automate 5. Commodify
23. #1 Modern skill set
24. Ensure your applications and tool sets are built for the cloud, not simply adapted from legacy architectures
25. How legacy are you? » Unsupported runtime versions » Unsupported application versions » Inappropriate data models » Tightly coupled architectures » Root access installers » Stateful applications on disk
26. Cloud native design patterns Design for... • Continuous Integration and Deployment • Microservices • Immutable containers • APIs • Antifragile systems
27. Antifragile systems benefit from chaos - Assume failure will happen - Fail fast - Fail often Measure Mean Time to Recovery, not Mean Time Between Errors Antifragile systems
28. Chaos Animals
29. #2 Development practices
30. Give developers the freedom to make the changes required for a cloud native, DevOps driven approach
31. Practices » Make a change without approval » Reuse deployment patterns » Test infrastructure changes as part of development » Post-incident reviews » Build pipelines » Changes during business hours » Isolation testing » Optimized batch sizing
32. Optimizing batch size • Make changes as small as is efficient • Test them in isolation. Deploy in isolation. • Teams must be able to work on the entire lifecycle of the task • Application architecture must support small changes
33. One change affecting one thing = 1 test One change affecting two things = 2 tests Two changes affecting one thing = Two changes affecting two things = Ch-ch-ch-ch-changes...
34. One change affecting one thing = 1 test One change affecting two things = 2 tests Two changes affecting one thing = 3 tests Two changes affecting two things = Ch-ch-ch-ch-changes...
35. One change affecting one thing = 1 test One change affecting two things = 2 tests Two changes affecting one thing = 3 tests Two changes affecting two things = 6 tests Ch-ch-ch-ch-changes...
36. For things not to fail, they must be tested. To test things properly, you need: • Automated tests • Virtualized services • Accurate test data • Production-like environments Test right
37. #3 Normalization & standardization
38. Reduce complexity (and waste) to its minimum through standardisation
39. • Reduction in licencing costs • Hire for a smaller skillset • Create cross-functional teams • Lower risk • Required for Automation Benefits of standardization
40. What to standardize » Operating systems » Development standards & practices (e.g. coding standards) » Testing practices » Deployment patterns » Operations practices » System configurations
41. How do High Performers compare on standardisation metrics – from the Puppet State of DevOps Report 23x 44x 27x Deployment patterns are reused Testing patterns are reused Configurations in a Config Management tool High performance
42. Keep everything in version control » Application code » Application configuration » Infrastructure configuration * but not Secrets
43. #4 Automation
44. Reduce waste by automating as much as possible, with the aim of having production-like environments.
45. Continuous Integration -- integrate the code into a shared repository and build and test each change automatically, as early as possible, usually several times a day. Continuous Delivery -- the software can be released to production at any time, often by automatically pushing changes to a staging system. Continuous Deployment pushes changes to the production automatically. CI / CD
46. Deploying to production should not be your first production deploy. The purpose of deployment is to validate the running application AND its deployment. Production-like environments should be automatically replicable Your first deploy should be the infrastructure. Production-like environments
47. 3x to 15x Faster deployment * measured by Platform.sh customers
48. CI made dead simple with Drupal 8, GitLab and Platform.sh Tomorrow, Oct 4, 3:45 PM-4:30 PM Boiler Room B Let’s talk more about CI/CD practices
49. #5 Commodification
50. Make the full toolstack available on-demand for anyone
51. • Self-service • On-demand environments • Choose PaaS or SaaS, over IaaS • Build your own or outsource Commodification
52. High performance is the ability to execute quickly, consistently, and in a sustained way
53. Deploy fast, deploy often Deploy Friday.
54. Branislav Bujisic branislav@platform.sh https://twitter.com/bbujisic https://platform.sh
55. Questions? Comments? Rotten tomatoes?