The document discusses the intricacies of utilizing cloud services effectively, emphasizing the importance of understanding your application's performance and the characteristics of cloud resources. It highlights the need for automation, robust design for failure, and careful vendor selection to ensure scalability and reduce costs. Additionally, it stresses the significance of adaptability in cloud infrastructure and learning from experiences to enhance performance and manage challenges.

1. 4/20/2013
Abusing the Cloud
for Fun
& Profit
CoderFaire Atlanta Alan Pinstein, Founder & CTO, TourBuzz
http://www.tourbuzz.net
http://www.showcaseIDX.com
@apinstein
apinstein@mac.com

2. What is the cloud?

3. What is the cloud?

4. Utility Computing
✤ Bare Metal
✤ Dedicated Server
✤ VM/Shared Hosting
✤ SaaS / Software-as-a-Service
✤ PaaS / Platform-as-a-Service
?

5. Know your place in the Stack
✤ Heroku vs EC2

6. Know your place in the Stack
✤ Heroku vs EC2
✤ Don’t try to devops your sysadmin if you
aren’t a sysadmin

7. Know your place in the Stack
✤ Heroku vs EC2
✤ Don’t try to devops your sysadmin if you
aren’t a sysadmin
✤ Move down the stack only as soon as
needed

8. Monetary Considerations
http://readwrite.com/2011/01/02/how-to-save-money-by-migrating

9. Monetary Considerations
✤ No up-front capital costs
http://readwrite.com/2011/01/02/how-to-save-money-by-migrating

10. Monetary Considerations
✤ No up-front capital costs
✤ But, more expensive cost per
unit-of-work
http://readwrite.com/2011/01/02/how-to-save-money-by-migrating

11. Monetary Considerations
✤ No up-front capital costs
✤ But, more expensive cost per
unit-of-work
✤ Matches Cost To Usage, not
Capacity
http://readwrite.com/2011/01/02/how-to-save-money-by-migrating

12. Monetary Considerations
✤ No up-front capital costs
✤ But, more expensive cost per
unit-of-work
✤ Matches Cost To Usage, not
Capacity
✤ Lots of things are metered that
you aren’t used to - “what gets
measured gets managed”
http://readwrite.com/2011/01/02/how-to-save-money-by-migrating

13. Monetary Considerations
✤ No up-front capital costs
✤ But, more expensive cost per
unit-of-work
✤ Matches Cost To Usage, not
Capacity
✤ Lots of things are metered that
you aren’t used to - “what gets
measured gets managed”
✤ Potential lower TCO
http://readwrite.com/2011/01/02/how-to-save-money-by-migrating

14. FreeTier FTW
✤ Heroku: 1 free web worker
https://www.heroku.com/pricing
✤ Mandrill: SMTP SaaS up to 12k/mo
http://mandrill.com/pricing/
✤ AWS: Free Tier
http://aws.amazon.com/free/

15. You cannot do this on your own.

16. Performance Characteristics
✤ You must understand your app’s
performance characteristics

17. Performance Characteristics
✤ You must understand your app’s
performance characteristics
✤ You must understand the performance
characteristics of your cloud resource

18. Performance Characteristics
✤ You must understand your app’s
performance characteristics
✤ You must understand the performance
characteristics of your cloud resource
✤ If they don’t match, and you have
problems...
I TOLD YOU SO.

19. AWS/EBSVolatility
http://www.stratalux.com/2012/08/09/putting-amazon’s-provisioned-iops-to-the-test/

20. Opaque stack: performance tuning is hard
✤ Used to dedicated hardware? Get ready for shared VM
performance volatility!

21. Opaque stack: performance tuning is hard
✤ Used to dedicated hardware? Get ready for shared VM
performance volatility!
✤ No idea what resource limits you’re given

22. Opaque stack: performance tuning is hard
✤ Used to dedicated hardware? Get ready for shared VM
performance volatility!
✤ No idea what resource limits you’re given
✤ Often support is hard to get or cagy about how stuff
works

23. Opaque stack: performance tuning is hard
✤ Used to dedicated hardware? Get ready for shared VM
performance volatility!
✤ No idea what resource limits you’re given
✤ Often support is hard to get or cagy about how stuff
works
✤ Documentation is typically not very detailed

24. Opaque stack: performance tuning is hard
✤ Used to dedicated hardware? Get ready for shared VM
performance volatility!
✤ No idea what resource limits you’re given
✤ Often support is hard to get or cagy about how stuff
works
✤ Documentation is typically not very detailed
✤ See: RapGenius v Heroku

25. ✤ September 18th:
Dedicated (Xen) to AWS/EC2
✤ December 10th:
m1.xlarge > c1.medium
✤ March 3rd:
Offload image processing to
autoscaling Heroku app

26. Should it AutoScale?

27. Should it AutoScale?
✤ Volatile load (minutes/hours/days)

28. Should it AutoScale?
✤ Volatile load (minutes/hours/days)
✤ Volatile load (months/years)

29. Should it AutoScale?
✤ Volatile load (minutes/hours/days)
✤ Volatile load (months/years)
✤ Scaling up vs Scaling down

30. Should it AutoScale?
✤ Volatile load (minutes/hours/days)
✤ Volatile load (months/years)
✤ Scaling up vs Scaling down
✤ Cost

31. Should it AutoScale?
✤ Volatile load (minutes/hours/days)
✤ Volatile load (months/years)
✤ Scaling up vs Scaling down
✤ Cost
✤ Performance

32. Will it AutoScale?

33. Will it AutoScale?
✤ Decouple independent processes

34. Will it AutoScale?
✤ Decouple independent processes
✤ Inter-app communication must be robust
Design for Failure, and Nothing will Fail.

35. Using the Cloud Successfully means
Changing the way you build apps

36. Using the Cloud Successfully means
Changing the way you build apps
✤ Automate everything. You will start from scratch frequently.

37. Using the Cloud Successfully means
Changing the way you build apps
✤ Automate everything. You will start from scratch frequently.
✤ DBA, sysadmin. Implies people doing manual work.

38. Using the Cloud Successfully means
Changing the way you build apps
✤ Automate everything. You will start from scratch frequently.
✤ DBA, sysadmin. Implies people doing manual work.
✤ DEVOPS is sustainable, but requires expertise.

39. Using the Cloud Successfully means
Changing the way you build apps
✤ Automate everything. You will start from scratch frequently.
✤ DBA, sysadmin. Implies people doing manual work.
✤ DEVOPS is sustainable, but requires expertise.
✤ Programmable infrastructure

40. Using the Cloud Successfully means
Changing the way you build apps
✤ Automate everything. You will start from scratch frequently.
✤ DBA, sysadmin. Implies people doing manual work.
✤ DEVOPS is sustainable, but requires expertise.
✤ Programmable infrastructure
✤ Not just for the data center (vagrant)
** go to Nic’s talk later today **

41. Using the Cloud Successfully means
Changing the way you build apps
✤ Automate everything. You will start from scratch frequently.
✤ DBA, sysadmin. Implies people doing manual work.
✤ DEVOPS is sustainable, but requires expertise.
✤ Programmable infrastructure
✤ Not just for the data center (vagrant)
** go to Nic’s talk later today **
✤ Automation is FREEDOM.

42. Using the Cloud Successfully means
Changing the way you build apps
✤ Automate everything. You will start from scratch frequently.
✤ DBA, sysadmin. Implies people doing manual work.
✤ DEVOPS is sustainable, but requires expertise.
✤ Programmable infrastructure
✤ Not just for the data center (vagrant)
** go to Nic’s talk later today **
✤ Automation is FREEDOM.
✤ From vendor lock-in, employee turnover,
cost of starting from scratch

43. Tales from the cloud...

44. Arg.
x1000

45. Arg.
✤ CDN --> many reports of serving
partial content.
x1000

46. Arg.
✤ CDN --> many reports of serving
partial content.
✤ Debugging real problems with
vendors is hard.
x1000

47. Arg.
✤ CDN --> many reports of serving
partial content.
✤ Debugging real problems with
vendors is hard.
✤ We had to revert.
x1000

48. WTF.
$ heroku ps:scale workers=20

49. WTF.
$ heroku ps:scale workers=20

50. WTF.
$ heroku ps:scale workers=20

51. WTF.
$ heroku ps:scale workers=20
$ heroku ps:scale workers=10

52. WTF.
$ heroku ps:scale workers=20
$ heroku ps:scale workers=10

53. WTF.
$ heroku ps:scale workers=20
$ heroku ps:scale workers=10

54. WTF.
$ heroku ps:scale workers=20
$ heroku ps:scale workers=10
#fail

55. WTF!
# mac laptop
~ $ time cat /dev/random | head -c 10000K > /dev/
null
real 1.03s
user 0.00s
sys 1.01s

56. WTF!
# heroku
~ $ time cat /dev/random | head -c 100 > /dev/null
real 0m8.430s
user 0m0.020s
sys 0m0.000s
# mac laptop
~ $ time cat /dev/random | head -c 10000K > /dev/
null
real 1.03s
user 0.00s
sys 1.01s

57. WTF!
# heroku
~ $ time cat /dev/random | head -c 100 > /dev/null
real 0m8.430s
user 0m0.020s
sys 0m0.000s
# mac laptop
~ $ time cat /dev/random | head -c 10000K > /dev/
null
real 1.03s
user 0.00s
sys 1.01s
✤ Heroku has very little entropy
✤ Caused sleep & usleep to be “lazy”; use nanosleep instead.

58. WTF?!
$ s3cmd put file.jpg s3://mybucket/file.jpg
=> 200 OK
$ curl http://mybucket/file.jpg
=> 404 file not found
$ sleep 5 && curl http://mybucket/file.jpg
=> 200 OK
Eventually consistent....

59. Stuff that went right
✤ Increased application performance
✤ Sleep better at night
✤ Save a lot of money
✤ Clear path for scaling as we grow that should avoid hair-on-fire
emergencies
✤ FREEDOM: options and flexibility

60. Plan your trip in the cloud
✤ “Design for failure, and nothing will fail”

61. Plan your trip in the cloud
✤ “Design for failure, and nothing will fail”
✤ Choose vendors carefully

62. Plan your trip in the cloud
✤ “Design for failure, and nothing will fail”
✤ Choose vendors carefully
✤ Expectations - from your team and vendors

63. Plan your trip in the cloud
✤ “Design for failure, and nothing will fail”
✤ Choose vendors carefully
✤ Expectations - from your team and vendors
✤ Architecture

64. Plan your trip in the cloud
✤ “Design for failure, and nothing will fail”
✤ Choose vendors carefully
✤ Expectations - from your team and vendors
✤ Architecture
✤ Contingency plans

65. We are hiring!

66. Q & A
Alan Pinstein
@apinstein
apinstein@mac.com
http://www.tourbuzz.net
http://www.showcaseIDX.com