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.

Microservices 101: opportunities, dilemmas and problems

1,614 views

Published on

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?

Published in: Software

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?

×