Upgrade to Pro — share decks privately, control downloads, hide ads and more …
Sign up for free

Micro Services

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers. →
Avatar for Will Hamill Will Hamill
March 13, 2014
Programming
120
1

Micro Services

Presentation given at Codeslice event on micro-services.

Avatar for Will Hamill

Will Hamill

March 13, 2014

More Decks by Will Hamill

See All by Will Hamill
Understanding Tech Strategy with Wardley Maps
Avatar for Will Hamill willhamill
1
330
Splitting the Monolith
Avatar for Will Hamill willhamill
0
320
Making Yourself Redundant
Avatar for Will Hamill willhamill
0
110
Agile Antipatterns
Avatar for Will Hamill willhamill
0
150
Building your Technical Profile
Avatar for Will Hamill willhamill
0
79
Agile Architecture
Avatar for Will Hamill willhamill
0
130
Agile 101
Avatar for Will Hamill willhamill
4
230

Other Decks in Programming

See All in Programming
Vue Fes Japan 2026 タイムテーブル徹底解説
Avatar for 448jp | OKI Yoshiya 448jp
1
570
Workers Cache を知る
Avatar for syumai syumai
0
310
Augmenting AI with the Power of Jakarta EE
Avatar for ivargrimstad ivargrimstad
0
350
モデルのリファクタリングが難しいと思ったら、そもそも複雑だったのはビジネス仕様だった ? / is-the-business-domain-the-real-complexity
Avatar for hatsu hatsu38
0
430
【高い買い物LT会】初任給で話題の国産フィジカルAIを買った話
Avatar for 赤神青空 akagami
PRO
0
180
海上で動くGoサーバー: goroutineとchannelでさばく航行データストリーム
Avatar for Atsuki Seo atsuki_seo
0
1k
Augmenting AI with the Power of Jakarta EE
Avatar for ivargrimstad ivargrimstad
0
350
Ghostty + Neovimで作る 透明でカッコ良い開発環境
Avatar for Kanade Nonomura j341nono
0
140
標準パッケージに uuid が追加された 背景から見る Go らしい意思決定 / go_127_uuid_decision
Avatar for convto convto
5
9.1k
Omarchy Tokyo やると聞いて UMPC 買ってセットアップしてきた
Avatar for Fumiaki MATSUSHIMA mtsmfm
0
190
Augmenting AI with the Power of Jakarta EE
Avatar for ivargrimstad ivargrimstad
0
420
技術的負債の返済は、AI時代の複利で効く投資 — 経営としての意思決定とその遂行
Avatar for curekoshimizu curekoshimizu
1
2k

Featured

See All Featured
Bootstrapping a Software Product
Avatar for Garrett Dimon garrettdimon
PRO
306
120k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
Avatar for Kenny Baas-Schwegler baasie
0
710
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
Avatar for Eileen M. Uchitelle eileencodes
28
3.7k
Darren the Foodie - Storyboard
Avatar for Kevinho.art khoart
PRO
4
4k
SEO Brein meetup: CTRL+C is not how to scale international SEO
Avatar for Linda Hogenes lindahogenes
2
2.9k
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
Avatar for Liv Day livdayseo
0
200
Test your architecture with Archunit
Avatar for Yoan thirion
2
2.4k
Improving Core Web Vitals using Speculation Rules API
Avatar for Sergey Chernyshev sergeychernyshev
21
1.6k
Neural Spatial Audio Processing for Sound Field Analysis and Control
Avatar for NII S. Koyama's Lab skoyamalab
0
530
Exploring anti-patterns in Rails
Avatar for Elle Meredith aemeredith
4
520
Primal Persuasion: How to Engage the Brain for Learning That Lasts
Avatar for Mike Taylor tmiket
0
490
Design in an AI World
Avatar for tapps tapps
1
340

Transcript

  1. μServices { } March 2014 Will Hamill

  2. DISCLAIMER: I am not an expert We are working (somewhat)

    in this direction on some projects But this is based mostly on content from QCon London 2014

  3. Applications are getting larger

  4. Services are getting smaller

  5. Services have been getting smaller for some time

  6. Monolithic

  7. Layered

  8. Service-Oriented

  9. Micro-Services

  10. How?

  11. A micro-service typically does only one thing User Authentication and

    Role Based Authorisation Service User Authentication Role Based Authorisation

  12. Anatomy of a micro service HTTP Logic Monitoring Storage

  13. Techs: no hard and fast rules Simpler, lighter, self-contained services

    need simpler and lighter technologies
  14. None

  15. Why?

  16. Simplicity (at the service level)

  17. 3,000 LOC vs 200 LOC 100 LOC 500 LOC 400

    LOC 200 LOC

  18. Scale (distribute load and apps across machines)

  19. Scaling the monolith

  20. Scaling the monolith

  21. Scaling the monolith …

  22. Scaling micro-services

  23. Scaling micro-services

  24. Scaling micro-services

  25. Scaling micro-services …

  26. Scale 2: Scale Harder (many teams one on project)

  27. Division of labour

  28. Division of labour

  29. Responding to change (decoupling delivery)

  30. Release Schedule Every 6 months

  31. Every 2 weeks Every week Every 4 weeks About every

    4 days

  32. Fault tolerance (fault acceptance)

  33. Fragile Robust Antifragile

  34. Who?

  35. Netflix Twitter Amazon Yammer MailOnline

  36. Not Quite There Yet

  37. BandwagonDB

  38. DRY-ed Out “core”

  39. Service-Oriented Monolith

  40. Difficulties

  41. Testing everything is harder (but testing services is easier)

  42. Fast, automated deployment and application monitoring are super-important

  43. Versioning can be tricky www.semver.org

  44. Conway’s Law

  45. This Is New

  46. This is an emerging approach Find which tradeoffs work best

    for your particular situation

  47. “It depends” ¯\_(ツ)_/¯

  48. Further Reading http://www.infoq.com/presentations/Micro-Services http://vimeo.com/user22258446/review/79288222/cbb24b224c http://yobriefca.se/blog/2013/04/29/micro-service-architecture/ http://martinfowler.com/articles/microservices.html http://davidmorgantini.blogspot.co.uk/2013/08/micro-services- introduction.html http://qconlondon.com/dl/qcon-london-2014/slides/ AdrianCockcroft_MigratingToMicroservices.pdf

  49. None