Successfully reported this slideshow.

Microservices 101: opportunities, dilemmas and problems

8

Share

YouTube videos are no longer supported on SlideShare

View original on YouTube

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...
Loading in …3
×
1 of 40
1 of 40

Microservices 101: opportunities, dilemmas and problems

8

Share

Download to read offline

Presentation from 4Developers 2015. Topics covered:
– What are microservices?
– Why they might be useful?
– What questions do they bring up?
– What's hard about them?

Presentation from 4Developers 2015. Topics covered:
– What are microservices?
– Why they might be useful?
– What questions do they bring up?
– What's hard about them?

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Microservices 101: opportunities, dilemmas and problems

  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?

×