Servers are Dead, long live the Service

Leave servers behind and start using more advanced cloud services to become more productive

Transcript

1. Servers are Dead, long live the Service flo@codeship.com @flomotlik
2. CTO at Codeship 2
3. Codeship (Landing page screenshot) 3
4. Codeship 4
6. Austrian 6
7. Boston Alps of MIT 7
9. Talk then QA (I ask you questions too) 9
10. Software touches everything 10
11. Software is/will be base of most industries 11
12. Netflix eats TV Uber eats Transportation Amazon eats everything 12
13. Constant Pressure on Company and Product 13
14. Recent Blogposts • http://nginx.com/blog/adopting-microservices-at-netflix- lessons-for-team-and-process-design/ • Optimize for Speed, not Efficiency • http://steveblank.com/2015/03/11/fear-of-failure-and-lack- of-speed-in-a-large-corporation/ • Accepting failure and running at speed are part of an innovation culture 14
15. Differentiate through better Software Development, not just better Software 15
16. Read “The Phoenix Project” 16
17. Lack of great software engineers 17
18. Who struggles with finding great Talent? 18
19. Competition in software industry moves fast 19
20. e.g. Stripe attacking Paypal 20
21. 1. Software is everywhere 2. Not enough developers 3. Lots of competition 21
22. Productivity and Focus of existing team priority #1 22
23. Otherwise you’re open for attacks 23
24. The top lesson that Cockcroft learned at Netflix is that speed wins in the marketplace 24
25. Best way to optimise a task? 25
26. Stop doing it 26
27. Outsource what isn’t at your core 27
28. Outsource to Services and Automation 28
29. The Revolution has happened 29
30. The Cloud: Judgement Day the day our machines got self aware 30
31. Virtualisation is old (actually very very old) 31
32. Separation of responsibility is old 32
33. Accessibility is the Revolution 33
34. 1. Low cost to start 2. For any team size 3. With complete automation 34
35. Decouple growth of team from growth of infrastructure 35
36. A single specialist in Java distributed systems is managing the entire Netflix Cassandra cluster without any commercial storage tools or help from engineers specializing in storage, SAN, or backup. 36
37. Optimise time by dedicating engineers to product growth 37
38. Infrastructure is “just” software 38
39. 39 In Cloud environment Percentage of engineering time dedicated to product and infrastructure 0 25 50 75 100 Number of engineers 20 50 90 150 Infrastructure development Product development
40. 40 Non Cloud Percentage of engineering time dedicated to product and infrastructure 25 50 75 100 Number of engineers 20 50 90 150 Infrastructure development Product development
41. <5% infrastructure development is not good enough 41
42. Whats next? 42
43. The Service: Salvation the day we lost control and gained focus 43
44. The Cloud is still full of servers 44
45. Servers develop personalities 45
46. They can misbehave 46
47. – TOO MANY PEOPLE “Log into XYZ to debug and fix Issue A happening on that machine” 47
48. 48 http://upload.wikimedia.org/wikipedia/commons/5/52/Red_flag_II.svg
49. 1. Lack of Data 2. Lack of Automation 3. Why even possible? 49
50. Don’t care about servers 50
51. Servers != Notebooks 51 http://commons.wikimedia.org/wiki/File:Written_in_moleskine.JPG
52. Servers = Post-it notes 52 http://commons.wikimedia.org/wiki/File:PostItNotePad.JPG
53. Why don’t servers matter? 53
54. All about the customer experience (within budget) 54
55. Amount of infrastructure is discussion between our app, our metrics and our budget limit. 55
56. Set an SLA and be done with it 56
57. What do you mean by Service? 57
58. IaaS PaaS SOA Micro-Service 58
59. Minimise Code to whats necessary for fulfilling one specific piece of work 59
60. No Infrastructure, just Code and dependencies 60
61. All about What, not How 61
62. Communication is done through service provider 62
63. Based on “standard” languages to minimise lock-in 63
64. 1. Automated Scaling 2. Automated Healing 3. Planned obsolescence 64
65. MSaaS™ (Micro Service as a Service) 65
66. I know, I’m not helping 66
67. Locked in How to keep the keys to the castle 67
68. #1 pushback whenever I talk to Tech Leadership (#2 for developers) 68
69. 1. Inertia 2. Code-level 3. Architectural 69
70. Inertia 70
71. Code lock-in 71
72. Google App-Engine did it wrong 72
73. Building on top of “standard” frameworks (e.g. Lambda starting with Node) 73
74. 74 Control over Infrastructure Lifetime of Infrastructure
75. Architectural lock-in 75
76. !! Assumptions !! 76
77. Small codebase = “Easy” to move 77
78. Easily extendable communication layer necessary 78
79. 79 Control over Infrastructure Lifetime of Infrastructure
80. Clear path for moving some pieces out of service necessary 80
81. Diverse Infrastructure 81
82. Communication between services is hard 82
83. 1. abstract 2. easy to use 3. extendable 83
84. HTTP an option, but also has its issues 84
85. e.g. explicit downtime handling 85
86. Service has more control over our infrastructure, can help with that 86
87. Keeping overview on Infrastructure 87
88. Timing and dependencies between events 88
89. Relationships between events 89
90. Understand impact of new service early is hard 90
91. Greater insight and control of service can help getting overview 91
92. Recap 92
93. Software is everywhere 93
94. Productivity wins 94
95. Outsource where possible 95
96. Competitors have made that choice for you 96
97. Build mix of monolith and micro-services 97
98. Other opinions available 98
99. Other opinions available https://speakerdeck.com/a_matsuda/the-recipe-for-the-worlds- largest-rails-monolith 99
100. Help out! 100
101. Tell your stories, let us all learn together 101
102. So many open questions to explore 102
103. QA I question, you answer 103
104. 1. Are you building micro-services? 2. Where did you start splitting? 3. Which technologies/services? 4. Happy with the results? 104