This document discusses how Amazon achieved business agility through continuous delivery practices like frequent releases, automated testing, immutable infrastructure, and treating infrastructure as code. It emphasizes reducing waste and failure through resiliency, visibility, and immunity enabled by cloud services. Continuous delivery is achieved through automation at all stages from building to deploying to monitoring. The future directions discussed are taking these practices further with microservices, Docker/LXC containers, and generating new projects and deploying them with a single click.

1. The Path to
Business Agility
“How Amazon
made us Boring”
AWS Summit Sydney 2014

2. Agenda
• Why boring
• Why agility
• Why cloud
• Why continuous
• Why stop

3. Today’s format
Some business reasoning,
technology frameworks
& engineering practice

4. Our Vision
4
“There has to be a better way”

5. So… Why boring?
• Multiple release per week
• 5 minute deployments to prod
• Single click environment builds
“If it hurts, do it more often” – Jez Humble
So now it’s all a bit

6. What does agility mean
For technology, we need to be more
effective
- It’s all about building better brakes
For business, the world it’s a changing
- The winners will be the people who can constantly learn and adapt

7. Why cloud and in particular AWS
Cost is a factor, but…
Its all about REDUCING waste

8. It’s ok to fail. Deal with it.
Your infrastructure and apps need resiliancy, visibility and immunity

9. Infrastructure Resiliancy
Autoscaling, Autohealing

10. Visibility with monitoring
Splunk, New Relic

11. Immunity to others’ failure
Circuit breaker, feature degradation

12. Sleep easy

13. Sleep easy

14. Continuous delivery enablers
Automate, automate, automate
Make infrastructure a non event
Take technology out of the picture

15. GM of Digital Channels
15
Vinnie Picture red button

16. Why can’t we deploy at midday?

17. One click environments

18. Infrastructure as code

19. Automated testing
Unit, integration, acceptance, canary, smoke...

20. Always deployable master
Use feature toggles/branches

21. Build artifacts once

22. Build pipeline
Gated quality control

23. Zero downtime deployments
Several approaches possible

24. “Done” means “released”

25. Deployments are a non-event
Anyone can do it (really)

26. Deployments are a non-event
Anyone can do it (really)

27. Mixed platform ecosystems
Amazon is not just for bespoke Rails Apps
You need to know when to compromise
How can we leverage AWS
capabilities and services for COTS

28. COTS Automation
They said we were crazy...

29. Challenges with COTS products
Hard
coded
server
lists
Non-­‐disposable
servers
Product
configura7on
not
always
scriptable
Presenta7on
informa7on
in
footer

30. What’s next
Micro services
30
Splunk for business
Cross platform CI
More frequent change
Big Data and Spot instances

31. PaaS / NoOps
Zero to Hero in less than 1 day

32. Immutable Servers
Don’t try to change me, love me as I am…

33. Foundation Image
Standard operating platform delivered as AMI for downstream projects

34. The future: Docker / LXC
Lightweight kernel level containers

35. Application kick-start
Tooling to generate a project skeleton plus all supporting infrastructure for
a new app

36. The dream
1. Enter project name
2. Generate
3. Deploy

37. The dream
1. Enter project name
2. Generate
3. Deploy

38. Thank you
Questions?
Charles Blaxland cblaxland@dius.com.au
@ampedandwired
Craig Rees craig.rees@vodafone.com.au