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
JAWS-UG20250116_iOSアプリエンジニアがAWSreInventに行ってきた(真面目編)
totokit4
0
120
最近のSfM手法まとめ - COLMAP / GLOMAPを中心に -
kwchrk
8
1.8k
AWS Community Builderのススメ - みんなもCommunity Builderに応募しよう! -
smt7174
0
120
いま現場PMのあなたが、 経営と向き合うPMになるために 必要なこと、腹をくくること
hiro93n
1
1.4k
embedパッケージを深掘りする / Deep Dive into embed Package in Go
task4233
0
170
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
1
16k
20240522 - 躍遷創作理念 @ PicCollage Workshop
dpys
0
310
チームが毎日小さな変化と適応を続けたら1年間でスケール可能なアジャイルチームができた話 / Building a Scalable Agile Team
kakehashi
1
200
駆け出しリーダーとしての第一歩〜開発チームとの新しい関わり方〜 / Beginning Journey as Team Leader
kaonavi
0
110
カップ麺の待ち時間(3分)でわかるPartyRockアップデート
ryutakondo
0
110
Git scrapingで始める継続的なデータ追跡 / Git Scraping
ohbarye
4
270
AI×医用画像の現状と可能性_2024年版/AI×medical_imaging_in_japan_2024
tdys13
1
1.3k
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
Raft: Consensus for Rubyists
vanstee
137
6.7k
Statistics for Hackers
jakevdp
797
220k
Producing Creativity
orderedlist
PRO
343
39k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
113
50k
A Tale of Four Properties
chriscoyier
157
23k
GitHub's CSS Performance
jonrohan
1030
460k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
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