Servers are Dead, long live the Service

Slide 1

Slide 1 text

Servers are Dead, long live the Service [email protected] @flomotlik

Slide 2

Slide 2 text

CTO at Codeship 2

Slide 3

Slide 3 text

Codeship (Landing page screenshot) 3

Slide 4

Slide 4 text

Codeship 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Austrian 6

Slide 7

Slide 7 text

Boston Alps of MIT 7

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Talk then QA (I ask you questions too) 9

Slide 10

Slide 10 text

Software touches everything 10

Slide 11

Slide 11 text

Software is/will be base of most industries 11

Slide 12

Slide 12 text

Netflix eats TV Uber eats Transportation Amazon eats everything 12

Slide 13

Slide 13 text

Constant Pressure on Company and Product 13

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Differentiate through better Software Development, not just better Software 15

Slide 16

Slide 16 text

Read “The Phoenix Project” 16

Slide 17

Slide 17 text

Lack of great software engineers 17

Slide 18

Slide 18 text

Who struggles with finding great Talent? 18

Slide 19

Slide 19 text

Competition in software industry moves fast 19

Slide 20

Slide 20 text

e.g. Stripe attacking Paypal 20

Slide 21

Slide 21 text

1. Software is everywhere 2. Not enough developers 3. Lots of competition 21

Slide 22

Slide 22 text

Productivity and Focus of existing team priority #1 22

Slide 23

Slide 23 text

Otherwise you’re open for attacks 23

Slide 24

Slide 24 text

The top lesson that Cockcroft learned at Netflix is that speed wins in the marketplace 24

Slide 25

Slide 25 text

Best way to optimise a task? 25

Slide 26

Slide 26 text

Stop doing it 26

Slide 27

Slide 27 text

Outsource what isn’t at your core 27

Slide 28

Slide 28 text

Outsource to Services and Automation 28

Slide 29

Slide 29 text

The Revolution has happened 29

Slide 30

Slide 30 text

The Cloud: Judgement Day the day our machines got self aware 30

Slide 31

Slide 31 text

Virtualisation is old (actually very very old) 31

Slide 32

Slide 32 text

Separation of responsibility is old 32

Slide 33

Slide 33 text

Accessibility is the Revolution 33

Slide 34

Slide 34 text

1. Low cost to start 2. For any team size 3. With complete automation 34

Slide 35

Slide 35 text

Decouple growth of team from growth of infrastructure 35

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Optimise time by dedicating engineers to product growth 37

Slide 38

Slide 38 text

Infrastructure is “just” software 38

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

<5% infrastructure development is not good enough 41

Slide 42

Slide 42 text

Whats next? 42

Slide 43

Slide 43 text

The Service: Salvation the day we lost control and gained focus 43

Slide 44

Slide 44 text

The Cloud is still full of servers 44

Slide 45

Slide 45 text

Servers develop personalities 45

Slide 46

Slide 46 text

They can misbehave 46

Slide 47

Slide 47 text

– TOO MANY PEOPLE “Log into XYZ to debug and fix Issue A happening on that machine” 47

Slide 48

Slide 48 text

48 http://upload.wikimedia.org/wikipedia/commons/5/52/Red_flag_II.svg

Slide 49

Slide 49 text

1. Lack of Data 2. Lack of Automation 3. Why even possible? 49

Slide 50

Slide 50 text

Don’t care about servers 50

Slide 51

Slide 51 text

Servers != Notebooks 51 http://commons.wikimedia.org/wiki/File:Written_in_moleskine.JPG

Slide 52

Slide 52 text

Servers = Post-it notes 52 http://commons.wikimedia.org/wiki/File:PostItNotePad.JPG

Slide 53

Slide 53 text

Why don’t servers matter? 53

Slide 54

Slide 54 text

All about the customer experience (within budget) 54

Slide 55

Slide 55 text

Amount of infrastructure is discussion between our app, our metrics and our budget limit. 55

Slide 56

Slide 56 text

Set an SLA and be done with it 56

Slide 57

Slide 57 text

What do you mean by Service? 57

Slide 58

Slide 58 text

IaaS PaaS SOA Micro-Service 58

Slide 59

Slide 59 text

Minimise Code to whats necessary for fulfilling one specific piece of work 59

Slide 60

Slide 60 text

No Infrastructure, just Code and dependencies 60

Slide 61

Slide 61 text

All about What, not How 61

Slide 62

Slide 62 text

Communication is done through service provider 62

Slide 63

Slide 63 text

Based on “standard” languages to minimise lock-in 63

Slide 64

Slide 64 text

1. Automated Scaling 2. Automated Healing 3. Planned obsolescence 64

Slide 65

Slide 65 text

MSaaS™ (Micro Service as a Service) 65

Slide 66

Slide 66 text

I know, I’m not helping 66

Slide 67

Slide 67 text

Locked in How to keep the keys to the castle 67

Slide 68

Slide 68 text

#1 pushback whenever I talk to Tech Leadership (#2 for developers) 68

Slide 69

Slide 69 text

1. Inertia 2. Code-level 3. Architectural 69

Slide 70

Slide 70 text

Inertia 70

Slide 71

Slide 71 text

Code lock-in 71

Slide 72

Slide 72 text

Google App-Engine did it wrong 72

Slide 73

Slide 73 text

Building on top of “standard” frameworks (e.g. Lambda starting with Node) 73

Slide 74

Slide 74 text

74 Control over Infrastructure Lifetime of Infrastructure

Slide 75

Slide 75 text

Architectural lock-in 75

Slide 76

Slide 76 text

!! Assumptions !! 76

Slide 77

Slide 77 text

Small codebase = “Easy” to move 77

Slide 78

Slide 78 text

Easily extendable communication layer necessary 78

Slide 79

Slide 79 text

79 Control over Infrastructure Lifetime of Infrastructure

Slide 80

Slide 80 text

Clear path for moving some pieces out of service necessary 80

Slide 81

Slide 81 text

Diverse Infrastructure 81

Slide 82

Slide 82 text

Communication between services is hard 82

Slide 83

Slide 83 text

1. abstract 2. easy to use 3. extendable 83

Slide 84

Slide 84 text

HTTP an option, but also has its issues 84

Slide 85

Slide 85 text

e.g. explicit downtime handling 85

Slide 86

Slide 86 text

Service has more control over our infrastructure, can help with that 86

Slide 87

Slide 87 text

Keeping overview on Infrastructure 87

Slide 88

Slide 88 text

Timing and dependencies between events 88

Slide 89

Slide 89 text

Relationships between events 89

Slide 90

Slide 90 text

Understand impact of new service early is hard 90

Slide 91

Slide 91 text

Greater insight and control of service can help getting overview 91

Slide 92

Slide 92 text

Recap 92

Slide 93

Slide 93 text

Software is everywhere 93

Slide 94

Slide 94 text

Productivity wins 94

Slide 95

Slide 95 text

Outsource where possible 95

Slide 96

Slide 96 text

Competitors have made that choice for you 96

Slide 97

Slide 97 text

Build mix of monolith and micro-services 97

Slide 98

Slide 98 text

Other opinions available 98

Slide 99

Slide 99 text

Other opinions available https://speakerdeck.com/a_matsuda/the-recipe-for-the-worlds- largest-rails-monolith 99

Slide 100

Slide 100 text

Help out! 100

Slide 101

Slide 101 text

Tell your stories, let us all learn together 101

Slide 102

Slide 102 text

So many open questions to explore 102

Slide 103

Slide 103 text

QA I question, you answer 103

Slide 104

Slide 104 text

1. Are you building micro-services? 2. Where did you start splitting? 3. Which technologies/services? 4. Happy with the results? 104