1. CLOUDIFY YOUR
BUSINESS
Wayne walls
cloud evangelist
Wednesday, August 21, 13

2. Wednesday, August 21, 13

3. 3
Self-Service
Wednesday, August 21, 13

4. 4
On-Demand
Wednesday, August 21, 13

5. 5
Metered
Wednesday, August 21, 13

6. 6
Resource Pooling
Wednesday, August 21, 13

7. 7
Broad Network Access
Wednesday, August 21, 13

8. NIST SAys...
8
Wednesday, August 21, 13

9. NIST says...
9
Wednesday, August 21, 13

10. NIST says...
10
Wednesday, August 21, 13

11. 11
Wednesday, August 21, 13

12. 12
Financial Services
Data Analysis & Forecasting
MapReduce Data Analytics
Distributed, Web 2.0 Apps
REVOLUTIONARY
Wednesday, August 21, 13

13. 13
SAP
PeopleSoft
SharePoint
SQL
Home Grown
Client-Server Based
EVOLUTIONARY
Wednesday, August 21, 13

14. 14
Big Promise of Cloud
Wednesday, August 21, 13

15. 15
Scale!
Wednesday, August 21, 13

16. 16
High-Availability vs Service Resiliency
Wednesday, August 21, 13

17. 17
What is HA?
Active/Passive
Active/Active
Wednesday, August 21, 13

18. 18
:Problem:
Single Point of Failure
Wednesday, August 21, 13

19. 19
:Solution:
MAKE TWO OF ‘EM!
Wednesday, August 21, 13

20. 20
Hammer & Nail Solution
Wednesday, August 21, 13

21. 21
High-Availability has Problems
Wednesday, August 21, 13

22. 22
Fails In Terrible Ways &
Doesn’t Really Scale
Wednesday, August 21, 13

23. 23
Two Options to “HA”
Wednesday, August 21, 13

24. 24
Take a non-distributed system and drop HA
on top of it
Option #1
Wednesday, August 21, 13

25. 25
NFS
Wednesday, August 21, 13

26. 26
Mean Time Between Failures
(MTBF)
Wednesday, August 21, 13

27. 27
Wednesday, August 21, 13

28. 28
Mean Time To Recovery
(MTTR)
Wednesday, August 21, 13

29. 29
Expected failures of a traditional HA system are
catastrophic
Wednesday, August 21, 13

30. 29
Expected failures of a traditional HA system are
catastrophic
Wednesday, August 21, 13

31. 29
Expected failures of a traditional HA system are
catastrophic
System not designed to be distributed
Wednesday, August 21, 13

32. 29
Expected failures of a traditional HA system are
catastrophic
System not designed to be distributed
Wednesday, August 21, 13

33. 29
Expected failures of a traditional HA system are
catastrophic
System not designed to be distributed
Failure forces it to be distributed
Wednesday, August 21, 13

34. 29
Expected failures of a traditional HA system are
catastrophic
System not designed to be distributed
Failure forces it to be distributed
Wednesday, August 21, 13

35. 29
Expected failures of a traditional HA system are
catastrophic
System not designed to be distributed
Failure forces it to be distributed
Cannot take distributed failure conditions into account
Wednesday, August 21, 13

36. 29
Expected failures of a traditional HA system are
catastrophic
System not designed to be distributed
Failure forces it to be distributed
Cannot take distributed failure conditions into account
Wednesday, August 21, 13

37. 29
Expected failures of a traditional HA system are
catastrophic
System not designed to be distributed
Failure forces it to be distributed
Cannot take distributed failure conditions into account
Best case scenario: complete failure
Wednesday, August 21, 13

38. 30
Take a distributed system and make the right
tradeoffs
Option #2
Wednesday, August 21, 13

39. 31
Service Resiliency
Wednesday, August 21, 13

40. 32
Examples
Wednesday, August 21, 13

41. 33
Percona XtraDB
Cassandra
Riak
Wednesday, August 21, 13

42. 34
Ceph
GlusterFS
Wednesday, August 21, 13

43. 35
Constant Health Checks
Wednesday, August 21, 13

44. 36
What is in a Running Application?
Wednesday, August 21, 13

45. 37
Availability vs Reliability
Wednesday, August 21, 13

46. 38
Wednesday, August 21, 13

47. 38
Reliability is the likelihood that a given component or system will be
functioning when needed as measured over a given period of time.
Wednesday, August 21, 13

48. 38
Reliability is the likelihood that a given component or system will be
functioning when needed as measured over a given period of time.
Availability is the percentage of times that a given system will be
functioning as required.
Wednesday, August 21, 13

49. 39
Server Service
Wednesday, August 21, 13

50. 40
Hardware does not get a pass...
Wednesday, August 21, 13

51. 41
Think availability from the service
layer(s) perspective
Wednesday, August 21, 13

52. 42
Wednesday, August 21, 13

53. 43
Apps in a Cloudy World
Wednesday, August 21, 13

54. 44
Greenfield vs Legacy
Wednesday, August 21, 13

55. 45
Greenfield
Wednesday, August 21, 13

56. 45
Greenfield
1. Focus on the service, not the server
Wednesday, August 21, 13

57. 45
Greenfield
1. Focus on the service, not the server
2. Identify & tear apart stateless and stateful parts of your application
Wednesday, August 21, 13

58. 45
Greenfield
1. Focus on the service, not the server
2. Identify & tear apart stateless and stateful parts of your application
3. Make stateful parts redundant using distributed data stores
Wednesday, August 21, 13

59. 45
Greenfield
1. Focus on the service, not the server
2. Identify & tear apart stateless and stateful parts of your application
3. Make stateful parts redundant using distributed data stores
4. Know the dependencies of your system and the impact of failure
Wednesday, August 21, 13

60. 45
Greenfield
1. Focus on the service, not the server
2. Identify & tear apart stateless and stateful parts of your application
3. Make stateful parts redundant using distributed data stores
4. Know the dependencies of your system and the impact of failure
5. Use micro-services to make dependencies explicit
Wednesday, August 21, 13

61. 46
Legacy
Wednesday, August 21, 13

62. 46
Legacy
1. Cloud Instances != server
Wednesday, August 21, 13

63. 46
Legacy
1. Cloud Instances != server
2. Plan to reduce mean time to recovery (MTTR)
Wednesday, August 21, 13

64. 46
Legacy
1. Cloud Instances != server
2. Plan to reduce mean time to recovery (MTTR)
3. "We're HA, we're all good." -> Wrong.
Wednesday, August 21, 13

65. 46
Legacy
1. Cloud Instances != server
2. Plan to reduce mean time to recovery (MTTR)
3. "We're HA, we're all good." -> Wrong.
4. Think about stateful vs stateless parts of your application and
work piece by piece
Wednesday, August 21, 13

66. 46
Legacy
1. Cloud Instances != server
2. Plan to reduce mean time to recovery (MTTR)
3. "We're HA, we're all good." -> Wrong.
4. Think about stateful vs stateless parts of your application and
work piece by piece
5. Be creative about trade-offs: many apps that run on more than one
server have some type of common backend (NFS)
Wednesday, August 21, 13

67. Thank You!
Wednesday, August 21, 13