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

Servers are Dead, long live the Service

Servers are Dead, long live the Service

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

7a9e2c47c8719d221fd711b135b33341?s=128

Florian Motlik

June 05, 2015
Tweet

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

  5. 5

  6. Austrian 6

  7. Boston Alps of MIT 7

  8. 8

  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