Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Servers are Dead, long live the Service
Search
Florian Motlik
June 05, 2015
Technology
3
84
Servers are Dead, long live the Service
Leave servers behind and start using more advanced cloud services to become more productive
Florian Motlik
June 05, 2015
Tweet
Share
More Decks by Florian Motlik
See All by Florian Motlik
Serverless and Software Craftsmanship
flomotlik
1
120
How Tooling will make or Break Serverless Infrastructure
flomotlik
1
74
Other Decks in Technology
See All in Technology
なぜfreeeはハブ・アンド・スポーク型の データメッシュアーキテクチャにチャレンジするのか?
shinichiro_joya
2
440
AWS re:Invent 2024 recap in 20min / JAWSUG 千葉 2025.1.14
shimy
1
100
機械学習を「社会実装」するということ 2025年版 / Social Implementation of Machine Learning 2025 Version
moepy_stats
5
970
自社 200 記事を元に整理した読みやすいテックブログを書くための Tips 集
masakihirose
2
330
技術に触れたり、顔を出そう
maruto
1
150
AWSサービスアップデート 2024/12 Part3
nrinetcom
PRO
0
140
20250116_JAWS_Osaka
takuyay0ne
2
200
iPadOS18でフローティングタブバーを解除してみた
sansantech
PRO
1
130
Alignment and Autonomy in Cybozu - 300人の開発組織でアラインメントと自律性を両立させるアジャイルな組織運営 / RSGT2025
ama_ch
1
2.4k
シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、顧客をビックリさせないプロダクトを作り上げているお話 #RSGT2025 / Shift Right
nihonbuson
3
2.1k
KMP with Crashlytics
sansantech
PRO
0
240
[IBM TechXchange Dojo]Watson Discoveryとwatsonx.aiでRAGを実現!座学①
siyuanzh09
0
110
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
41
7.2k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.5k
GraphQLとの向き合い方2022年版
quramy
44
13k
Visualization
eitanlees
146
15k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Docker and Python
trallard
43
3.2k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
What's in a price? How to price your products and services
michaelherold
244
12k
Why Our Code Smells
bkeepers
PRO
335
57k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
230
52k
Being A Developer After 40
akosma
89
590k
Building an army of robots
kneath
302
45k
Transcript
Servers are Dead, long live the Service
[email protected]
@flomotlik
CTO at Codeship 2
Codeship (Landing page screenshot) 3
Codeship 4
5
Austrian 6
Boston Alps of MIT 7
8
Talk then QA (I ask you questions too) 9
Software touches everything 10
Software is/will be base of most industries 11
Netflix eats TV Uber eats Transportation Amazon eats everything 12
Constant Pressure on Company and Product 13
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
Differentiate through better Software Development, not just better Software 15
Read “The Phoenix Project” 16
Lack of great software engineers 17
Who struggles with finding great Talent? 18
Competition in software industry moves fast 19
e.g. Stripe attacking Paypal 20
1. Software is everywhere 2. Not enough developers 3. Lots
of competition 21
Productivity and Focus of existing team priority #1 22
Otherwise you’re open for attacks 23
The top lesson that Cockcroft learned at Netflix is that
speed wins in the marketplace 24
Best way to optimise a task? 25
Stop doing it 26
Outsource what isn’t at your core 27
Outsource to Services and Automation 28
The Revolution has happened 29
The Cloud: Judgement Day the day our machines got self
aware 30
Virtualisation is old (actually very very old) 31
Separation of responsibility is old 32
Accessibility is the Revolution 33
1. Low cost to start 2. For any team size
3. With complete automation 34
Decouple growth of team from growth of infrastructure 35
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
Optimise time by dedicating engineers to product growth 37
Infrastructure is “just” software 38
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 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
<5% infrastructure development is not good enough 41
Whats next? 42
The Service: Salvation the day we lost control and gained
focus 43
The Cloud is still full of servers 44
Servers develop personalities 45
They can misbehave 46
– TOO MANY PEOPLE “Log into XYZ to debug and
fix Issue A happening on that machine” 47
48 http://upload.wikimedia.org/wikipedia/commons/5/52/Red_flag_II.svg
1. Lack of Data 2. Lack of Automation 3. Why
even possible? 49
Don’t care about servers 50
Servers != Notebooks 51 http://commons.wikimedia.org/wiki/File:Written_in_moleskine.JPG
Servers = Post-it notes 52 http://commons.wikimedia.org/wiki/File:PostItNotePad.JPG
Why don’t servers matter? 53
All about the customer experience (within budget) 54
Amount of infrastructure is discussion between our app, our metrics
and our budget limit. 55
Set an SLA and be done with it 56
What do you mean by Service? 57
IaaS PaaS SOA Micro-Service 58
Minimise Code to whats necessary for fulfilling one specific piece
of work 59
No Infrastructure, just Code and dependencies 60
All about What, not How 61
Communication is done through service provider 62
Based on “standard” languages to minimise lock-in 63
1. Automated Scaling 2. Automated Healing 3. Planned obsolescence 64
MSaaS™ (Micro Service as a Service) 65
I know, I’m not helping 66
Locked in How to keep the keys to the castle
67
#1 pushback whenever I talk to Tech Leadership (#2 for
developers) 68
1. Inertia 2. Code-level 3. Architectural 69
Inertia 70
Code lock-in 71
Google App-Engine did it wrong 72
Building on top of “standard” frameworks (e.g. Lambda starting with
Node) 73
74 Control over Infrastructure Lifetime of Infrastructure
Architectural lock-in 75
!! Assumptions !! 76
Small codebase = “Easy” to move 77
Easily extendable communication layer necessary 78
79 Control over Infrastructure Lifetime of Infrastructure
Clear path for moving some pieces out of service necessary
80
Diverse Infrastructure 81
Communication between services is hard 82
1. abstract 2. easy to use 3. extendable 83
HTTP an option, but also has its issues 84
e.g. explicit downtime handling 85
Service has more control over our infrastructure, can help with
that 86
Keeping overview on Infrastructure 87
Timing and dependencies between events 88
Relationships between events 89
Understand impact of new service early is hard 90
Greater insight and control of service can help getting overview
91
Recap 92
Software is everywhere 93
Productivity wins 94
Outsource where possible 95
Competitors have made that choice for you 96
Build mix of monolith and micro-services 97
Other opinions available 98
Other opinions available https://speakerdeck.com/a_matsuda/the-recipe-for-the-worlds- largest-rails-monolith 99
Help out! 100
Tell your stories, let us all learn together 101
So many open questions to explore 102
QA I question, you answer 103
1. Are you building micro-services? 2. Where did you start
splitting? 3. Which technologies/services? 4. Happy with the results? 104