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
83
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
110
How Tooling will make or Break Serverless Infrastructure
flomotlik
1
62
Other Decks in Technology
See All in Technology
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
Zennのパフォーマンスモニタリングでやっていること
ryosukeigarashi
0
150
複雑なState管理からの脱却
sansantech
PRO
1
150
強いチームと開発生産性
onk
PRO
35
11k
日経電子版のStoreKit2フルリニューアル
shimastripe
1
140
『Firebase Dynamic Links終了に備える』 FlutterアプリでのAdjust導入とDeeplink最適化
techiro
0
130
IBC 2024 動画技術関連レポート / IBC 2024 Report
cyberagentdevelopers
PRO
1
110
Introduction to Works of ML Engineer in LY Corporation
lycorp_recruit_jp
0
140
生成AIが変えるデータ分析の全体像
ishikawa_satoru
0
170
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
10
1.1k
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
28
13k
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
190
Featured
See All Featured
Become a Pro
speakerdeck
PRO
25
5k
Thoughts on Productivity
jonyablonski
67
4.3k
Designing on Purpose - Digital PM Summit 2013
jponch
115
7k
Site-Speed That Sticks
csswizardry
0
28
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Optimizing for Happiness
mojombo
376
70k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Designing Experiences People Love
moore
138
23k
A Philosophy of Restraint
colly
203
16k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
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