Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ITERATORSI T E R A T O R S @luksow
Microservices 101
opportunities, dilemmas and problems
Łukasz Sowa, 4Developers 2015
ITERATORSI T E R A T O R S @luksow
Hi, I'm Łukasz
●
Co-founder, engineer @ Iterators (http://iterato.rs)
●
Highly concurre...
ITERATORSI T E R A T O R S @luksow
What's in it for you?
●
Learn
– What are microservices?
– Why they might be useful?
– W...
ITERATORSI T E R A T O R S @luksow
What are microservices?
●
Architectural style (MSA)
●
System is composed of multiple se...
ITERATORSI T E R A T O R S @luksow
Why? Why now?
●
Post-SOA (or SOA done right?)
●
DevOps revolution (provisioning, deploy...
ITERATORSI T E R A T O R S @luksow
Let's design!
Design a system that allows users to login/register using FB, email-passw...
ITERATORSI T E R A T O R S @luksow
Opportunities
Why people love microservices?
ITERATORSI T E R A T O R S @luksow
Technical advantages
●
Horizontal scaling performance→
●
Designing for failure resilien...
ITERATORSI T E R A T O R S @luksow
Cultural advantages (1)
Any organization that designs a system (defined
more broadly he...
ITERATORSI T E R A T O R S @luksow
Cultural advantages (2)
●
Siloed teams vs cross-functional teams
●
Less communication o...
ITERATORSI T E R A T O R S @luksow
Cultural advantages (3)
●
Easy to understand
●
Dispose/rewrite vs refactor
●
Polyglot e...
ITERATORSI T E R A T O R S @luksow
Dilemmas
Decisions, decisions, decisions...
ITERATORSI T E R A T O R S @luksow
Communication, protocols
●
Communication - most important MSA concern
●
Microservices ≠...
ITERATORSI T E R A T O R S @luksow
Synchronous vs asynchronous
●
Request-response
●
ASAP response
●
“Asking”
●
Fail-fast
●...
ITERATORSI T E R A T O R S @luksow
Protocols in action
auth-fb auth-pass auth-codes
btc-users
btc-ws
identity
metrics
sess...
ITERATORSI T E R A T O R S @luksow
Guarantees
●
What guarantees do you need?
– What's the cost of a single message being l...
ITERATORSI T E R A T O R S @luksow
Shared vs private data stores
●
Source of truth
●
Strong
contract/protocol
●
Convenient...
ITERATORSI T E R A T O R S @luksow
Private data stores
auth-fb auth-pass auth-codes
btc-users
btc-ws
identity
metrics
sess...
ITERATORSI T E R A T O R S @luksow
Shared data stores
auth-fb auth-pass auth-codes
btc-users
btc-ws
metrics
session
btc-ma...
ITERATORSI T E R A T O R S @luksow
Size & structure
●
How big is microservice?
– ~100 lines rule is a lie
– Up to a couple...
ITERATORSI T E R A T O R S @luksow
Size & structure - example
Name Structured? LoC / eLoC
auth-fb Yes 215 / 189
auth-pass ...
ITERATORSI T E R A T O R S @luksow
Code sharing
Sometimes the same code is required in two or
more services – how to share...
ITERATORSI T E R A T O R S @luksow
Polyglot vs monoculture
●
Tower of Babel problem
●
Unmaintainable code rewrites costs→ ...
ITERATORSI T E R A T O R S @luksow
Testing
●
Don't test
– “This big” correctness rule
– Run in production, rollback on pro...
ITERATORSI T E R A T O R S @luksow
Problems
Distributed systems are hard
ITERATORSI T E R A T O R S @luksow
Operations
●
Infrastructure, different machine utilization strategies
●
Provisioning
●
...
ITERATORSI T E R A T O R S @luksow
Complexity
●
Complexity never goes away
●
Code complexity communication complexity→
●
I...
ITERATORSI T E R A T O R S @luksow
Distributed computing
●
Fallacies of distributed computing (Peter Deutsch, 1994)
– The ...
ITERATORSI T E R A T O R S @luksow
Contracts
●
What API should I have?
●
Who are my collaborators?
●
How can I contact the...
ITERATORSI T E R A T O R S @luksow
Versioning
●
How to handle changes?
●
How to handle external (ex. API) changes?
●
Keep ...
ITERATORSI T E R A T O R S @luksow
Monitoring, metrics
●
Monitor/measure all the things!
●
(You should be doing it in mono...
ITERATORSI T E R A T O R S @luksow
Logging & debugging
●
How do you debug distributed system?
●
Next to impossible, comple...
ITERATORSI T E R A T O R S @luksow
Security
●
Larger network larger attack surface→
●
Ex. internal API leakage
auth-fb aut...
ITERATORSI T E R A T O R S @luksow
Frontend
●
No microservices solution for frontend
●
Visual coherency coupling→
●
Monoli...
ITERATORSI T E R A T O R S @luksow
Conclusions
tldr;
ITERATORSI T E R A T O R S @luksow
Is it worth it? When?
●
For problems that microservices likely solve
●
If you're workin...
ITERATORSI T E R A T O R S @luksow
How to start?
●
Try gradually migrating from monolith, don't
start from scratch
●
Make ...
ITERATORSI T E R A T O R S @luksow
What to remember?
●
Microservices are hard
– Operations
– Complexity
– Distribution
●
B...
ITERATORSI T E R A T O R S @luksow
Thanks!
●
Łukasz Sowa
●
http://luksow.com
●
http://iterato.rs
●
contact@luksow.com
●
@l...
Upcoming SlideShare
Loading in …5
×

4Developers 2015: Mikroserwisy - szanse, dylematy i problemy - Łukasz Sowa

274 views

Published on

Łukasz Sowa

Language: Polish

Mikroserwisy to ostatnio jeden z najgorętszych tematów poruszanych w dyskusjach na temat architektury systemów. W środowisku programistów daje się odczuć zachwyt i ekscytację zaletami tego podejścia. Rzadko wspomina się jednak o dylematach i problemach, z którymi mierzą się zespoły tworzące architekturę mikroserwisową. W mojej prezentacji postaram się przedstawić możliwie najpełniejszy obraz tego co może spotkać lidera zespołu, architekta i programistę mikroserwisów.
Odpowiem na pytania:
- Co to są mikroserwisy?
- Co oferują w stosunku do tradycyjnego, monolitycznego podejścia?
- Jakie kwestie należy rozstrzygnąć projektując system operaty na mikroserwisach?
- Na jakie problemy można trafić?

Published in: Software
  • Be the first to comment

  • Be the first to like this

4Developers 2015: Mikroserwisy - szanse, dylematy i problemy - Łukasz Sowa

  1. 1. ITERATORSI T E R A T O R S @luksow Microservices 101 opportunities, dilemmas and problems Łukasz Sowa, 4Developers 2015
  2. 2. ITERATORSI T E R A T O R S @luksow Hi, I'm Łukasz ● Co-founder, engineer @ Iterators (http://iterato.rs) ● Highly concurrent & distributed systems ● Pizza, beer & football lover ● http://luksow.com ● contact@luksow.com ● @luksow
  3. 3. ITERATORSI T E R A T O R S @luksow What's in it for you? ● Learn – What are microservices? – Why they might be useful? – What questions do they bring up? – What's hard about them? ● Takeaways – Feel enthusiastic but cautious about microservices – Be able to design your next project using microservices
  4. 4. ITERATORSI T E R A T O R S @luksow What are microservices? ● Architectural style (MSA) ● System is composed of multiple services – Small* – Independently deployed – Communicate using (lightweight) protocols – Organized around business capabilities ● Bounded Context (DDD) or Single Responsibility Principle (OO) implemented in architecture
  5. 5. ITERATORSI T E R A T O R S @luksow Why? Why now? ● Post-SOA (or SOA done right?) ● DevOps revolution (provisioning, deployment) ● Cheap hardware ● Existing systems got too big and too boring? ● Innovation market got immensely demanding (Netflix, Gilt, Tumblr, Amazon, SoundCloud)
  6. 6. ITERATORSI T E R A T O R S @luksow Let's design! Design a system that allows users to login/register using FB, email-password or codecard. Authenticated user can subscribe to different events from BTC markets (ex. rate changed, volume over N, ask below M etc.) and get real-time alerts about them. Make sure to gather relevant business metrics. auth-fb auth-pass auth-codes btc-users btc-ws identity metrics session token frontend btc-market load balancer
  7. 7. ITERATORSI T E R A T O R S @luksow Opportunities Why people love microservices?
  8. 8. ITERATORSI T E R A T O R S @luksow Technical advantages ● Horizontal scaling performance→ ● Designing for failure resilience→ auth-fb auth-pass auth-codes btc-users btc-ws identity metrics session token frontend btc-market load balancer btc-wsbtc-ws Scaling X Resilience
  9. 9. ITERATORSI T E R A T O R S @luksow Cultural advantages (1) Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure. Melvin Conway, How Do Committees Invent, 1968
  10. 10. ITERATORSI T E R A T O R S @luksow Cultural advantages (2) ● Siloed teams vs cross-functional teams ● Less communication overhead ● Business-oriented teams – microbusinesses ● The True Way of (scrum) team scaling ● Agility + autonomy → short time-to-market MGR UX FE DEV BE DEV DBA OPS QA vs
  11. 11. ITERATORSI T E R A T O R S @luksow Cultural advantages (3) ● Easy to understand ● Dispose/rewrite vs refactor ● Polyglot environment, better tools utilization ● Mythical reusability? ● Fun!
  12. 12. ITERATORSI T E R A T O R S @luksow Dilemmas Decisions, decisions, decisions...
  13. 13. ITERATORSI T E R A T O R S @luksow Communication, protocols ● Communication - most important MSA concern ● Microservices ≠ REST ● Plethora of possibilities – Universal: REST+JSON/XML, MQs, binary TCP/UDP, ... simple, decoupled,→ polyglot but low-level, full of boilerplate, possible code duplication – Platform-specifc: Akka, Finagle, … easier to code & maintain, code reuse→ but tightly coupled, platform-dependant, not polyglot ● Prefer universal & lightweight (UNIX - smart endpoints, dumb pipes) ● Microservices are mostly REST ● Remember about Postel's law
  14. 14. ITERATORSI T E R A T O R S @luksow Synchronous vs asynchronous ● Request-response ● ASAP response ● “Asking” ● Fail-fast ● Easy to reason about ● Timeouts? ● Don't scale Ex. REST, ... ● Message passing ● Deferred processing ● “Telling” ● Unnatural ● Complicated, hard to debug ● Recovering from failures ● Scale Ex. WebSockets, MQs, Akka, UDP, ...
  15. 15. ITERATORSI T E R A T O R S @luksow Protocols in action auth-fb auth-pass auth-codes btc-users btc-ws identity metrics session token btc-market REST/JSON WebSockets REST/JSON Akka AkkaHTTP Keep-Alive
  16. 16. ITERATORSI T E R A T O R S @luksow Guarantees ● What guarantees do you need? – What's the cost of a single message being lost? – What happens if system is in inconsistent state? – … ● No ACID (atomicity, consistency, isolation, durability) ● But CAP theorem (consistency, availability, partition tolerance) ● Eventual consistency, 2PC, 3PC, Paxos & others are your friends now ● What do you need? What can/cannot you afford? ● And no, you can't have everything
  17. 17. ITERATORSI T E R A T O R S @luksow Shared vs private data stores ● Source of truth ● Strong contract/protocol ● Convenient ● Coupling ● Don't scale ● Ownership issues ● Service becomes an abstraction over DS ● Polyglot persistence ● Decoupling ● Scale ● Truth is distributed ● Façade issues ● Recommended
  18. 18. ITERATORSI T E R A T O R S @luksow Private data stores auth-fb auth-pass auth-codes btc-users btc-ws identity metrics session token btc-market MongoDB Redis PostgreSQL PostgreSQL PostgreSQL MongoDB Event journal
  19. 19. ITERATORSI T E R A T O R S @luksow Shared data stores auth-fb auth-pass auth-codes btc-users btc-ws metrics session btc-market MongoDB token Redis PostgreSQL PostgreSQL PostgreSQL identity MongoDB Event journal
  20. 20. ITERATORSI T E R A T O R S @luksow Size & structure ● How big is microservice? – ~100 lines rule is a lie – Up to a couple of thousands LOC in most cases – Rule: as short as possible but as big as necessary ● Clean & structured vs short & hacky Resources Service Domain Repositories Data mappers Gateways Applicationvs ● Well-structured ● Requires time to analyse ● Easy to maintain ● Longer ● Unstructured ● Understandable at a glance ● Hard to maintain ● Much shorter
  21. 21. ITERATORSI T E R A T O R S @luksow Size & structure - example Name Structured? LoC / eLoC auth-fb Yes 215 / 189 auth-pass Yes 301 / 258 auth-codes Yes 337 / 299 identity No 77 / 66 session No 48 / 43 token Yes 182 / 167 metrics No 160 / 150 btc-ws No 155 / 140 btc-users Yes 153 / 141 btc-market No 51 / 40 TOTAL 5 Yes / 5 No 1679 / 1493
  22. 22. ITERATORSI T E R A T O R S @luksow Code sharing Sometimes the same code is required in two or more services – how to share it? ● Shared library coupling, not polyglot→ ● Nanoservice maintenance burden, performance→ ● Copy-paste duplication, more code to maintain→ No good answer here (3rd is the most popular)
  23. 23. ITERATORSI T E R A T O R S @luksow Polyglot vs monoculture ● Tower of Babel problem ● Unmaintainable code rewrites costs→ → ● Multiple platforms lots of ops costs→ → ● But you want to use best tools and have fun ● Make recommendations about defaults – and innovate from there – “We use Scala for such tasks unless there's a better solution” – “PostgreSQL is our default database because XYZ” – “We prefer Redis with Rediscala library for caching”
  24. 24. ITERATORSI T E R A T O R S @luksow Testing ● Don't test – “This big” correctness rule – Run in production, rollback on problems ● Test – good ol' style – Unit tests, integration tests, component tests, contract tests, end-to- end tests – Favour black-box tests ● Test – in a distributed system way – No way to really do that – Chaos monkey
  25. 25. ITERATORSI T E R A T O R S @luksow Problems Distributed systems are hard
  26. 26. ITERATORSI T E R A T O R S @luksow Operations ● Infrastructure, different machine utilization strategies ● Provisioning ● Deployment pipeline ● Monitoring ● Service discovery & confguration management ● Code templates with boilerplate ● Close collaboration of developers & operations DevOps→ ● Costs time & money
  27. 27. ITERATORSI T E R A T O R S @luksow Complexity ● Complexity never goes away ● Code complexity communication complexity→ ● It's easy to make (worse) spaghetti there as well ● MSA requires more code to be written (boilerplate) ● More work at the initial stage (foundations) ● Avoid nanoservices maintenance burden→
  28. 28. ITERATORSI T E R A T O R S @luksow Distributed computing ● Fallacies of distributed computing (Peter Deutsch, 1994) – The network is reliable – Latency is zero – Bandwidth is infnite – The network is secure – Topology doesn't change – There is one administrator – Transport cost is zero – The network is homogeneous ● Ex. RPC (vs local call) – It can fail – It can timeout (and still execute successfully!) – It is a couple of magnitudes slower
  29. 29. ITERATORSI T E R A T O R S @luksow Contracts ● What API should I have? ● Who are my collaborators? ● How can I contact them? ● Make product owners defne API & protocols ● Service discovery & confguration management (ex. ZooKeeper, Consul.io) ● Think about help from providers (libraries, stubs, ex. Swagger, pact)
  30. 30. ITERATORSI T E R A T O R S @luksow Versioning ● How to handle changes? ● How to handle external (ex. API) changes? ● Keep multiple versions in production ● Observe their behaviour ● Let the load balancers do the heavy lifting ● Embrace it to do A/B testing
  31. 31. ITERATORSI T E R A T O R S @luksow Monitoring, metrics ● Monitor/measure all the things! ● (You should be doing it in monolith anyway) ● System metrics, health monitoring ● Business metrics ● Keep yourself informed about anomalies ● Observe analyse react→ →
  32. 32. ITERATORSI T E R A T O R S @luksow Logging & debugging ● How do you debug distributed system? ● Next to impossible, completely different from monolith ● Centralized logging with correlation id and efficient search (no, grep doesn't work anymore) ● Tracing whenever possible ● Again, monitor/measure everything (including network traffic)
  33. 33. ITERATORSI T E R A T O R S @luksow Security ● Larger network larger attack surface→ ● Ex. internal API leakage auth-fb auth-pass auth-codes btc-users btc-ws identity metrics session token btc-market Internal API External API
  34. 34. ITERATORSI T E R A T O R S @luksow Frontend ● No microservices solution for frontend ● Visual coherency coupling→ ● Monoliths (ex. SPA) ● Fragments
  35. 35. ITERATORSI T E R A T O R S @luksow Conclusions tldr;
  36. 36. ITERATORSI T E R A T O R S @luksow Is it worth it? When? ● For problems that microservices likely solve ● If you're working on a well-funded, innovative products, in a big teams ● If you have certain DevOps maturity ● If you can write proper monoliths ● If you're not expecting a free lunch
  37. 37. ITERATORSI T E R A T O R S @luksow How to start? ● Try gradually migrating from monolith, don't start from scratch ● Make sure you have DevOps capabilities ● Reorganize teams around features ● Think in microservices, not in monolith ● Don't do “new architecture”, “new platform”, “new languages” all at once
  38. 38. ITERATORSI T E R A T O R S @luksow What to remember? ● Microservices are hard – Operations – Complexity – Distribution ● But they can be very rewarding – Team scaling & developer happiness – Scaling – Resilience
  39. 39. ITERATORSI T E R A T O R S @luksow Thanks! ● Łukasz Sowa ● http://luksow.com ● http://iterato.rs ● contact@luksow.com ● @luksow Questions?

×