Upgrade to Pro — share decks privately, control downloads, hide ads and more …

High Performance Tips for Building Applications in the Cloud

High Performance Tips for Building Applications in the Cloud

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

Branislav Bujisic

October 03, 2019
Tweet

More Decks by Branislav Bujisic

Other Decks in Technology

Transcript

  1. 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
  2. Steps to the cloud 1. Modern Technology Skillset 2. Update

    development practices 3. Normalize and standardize 4. Automate 5. Commodify
  3. Ensure your applications and tool sets are built for the

    cloud, not simply adapted from legacy architectures
  4. How legacy are you? » Unsupported runtime versions » Unsupported

    application versions » Inappropriate data models » Tightly coupled architectures » Root access installers » Stateful applications on disk
  5. Cloud native design patterns Design for... • Continuous Integration and

    Deployment • Microservices • Immutable containers • APIs • Antifragile systems
  6. 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
  7. Give developers the freedom to make the changes required for

    a cloud native, DevOps driven approach
  8. 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
  9. 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
  10. 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...
  11. 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...
  12. 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...
  13. 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
  14. • Reduction in licencing costs • Hire for a smaller

    skillset • Create cross-functional teams • Lower risk • Required for Automation Benefits of standardization
  15. What to standardize » Operating systems » Development standards &

    practices (e.g. coding standards) » Testing practices » Deployment patterns » Operations practices » System configurations
  16. 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
  17. Keep everything in version control » Application code » Application

    configuration » Infrastructure configuration * but not Secrets
  18. Reduce waste by automating as much as possible, with the

    aim of having production-like environments.
  19. 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
  20. 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
  21. 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
  22. • Self-service • On-demand environments • Choose PaaS or SaaS,

    over IaaS • Build your own or outsource Commodification