Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices, Monoliths, SOA, and how we got here

Microservices, Monoliths, SOA, and how we got here

A bit of history of application development, from the early days of monoliths and SOA to the emergence of Microservice architectures. We will review the drawbacks of heritage architectures and how the principles of Reactive can help you build isolated services that are scalable, resilient to failure, and combine with other services to form a cohesive whole.

665a7ca82af87606f4fc83b3d94b5fd5?s=128

Kevin Webber

May 05, 2016
Tweet

More Decks by Kevin Webber

Other Decks in Programming

Transcript

  1. None
  2. None
  3. Expectations are changing » real-time (latency of 1 second, not

    1 day) » users are always connected » mission-critical use cases » consistent experience more important than peak performance
  4. We used to write programs... » for single servers and

    VMs » for single cores » that expect local communications (call stack) » that expect small data snapshots (data fits into memory)
  5. Now we write programs... » that must exploit clusters »

    that must exploit multi- core CPUs (even on cell phones!) » that must work across async boundaries (threads, networks) » that must process streams (i.e, data without limits)
  6. None
  7. A recap of heritage systems

  8. None
  9. None
  10. None
  11. None
  12. None
  13. None
  14. heritage applications » Single points of failure » Difficult to

    scale (shared mutable state, etc) » Different non-functional requirements (reads, writes, compute) & optimized for none! » Long, risky release cycles
  15. What is SOA?

  16. Elements of SOA » Inter-operable services » Formal contracts (e.g,

    WSDL) » Multiple protocols (e.g, SOAP, RPC, REST, CORBA, etc) » Location transparency » ESB
  17. SOA framework » Problems arise when we attempt to contradict

    the spirit of SOA » Central control + location transparency » Rigid specifications + flexibility » Transactions + distribution » Etc
  18. The bad parts of SOA

  19. “Architecture is hard enough without adding unnecessary complexity.” Ross Mason,

    CTO, MuleSoft
  20. None
  21. ESB Stateless: messaging, message exchange patterns (sync req/resp, async p2p

    messaging, pub/sub, streams), routing, service orchestration (service aggregation), security (encryption and signing), monitoring, protocol conversion, legacy adapters, payload transformation, schema validation, governance (the ability to apply business rules uniformly), service catalog
  22. ESB Stateful: process choreography (BPM), complex event processing (CEP), reliable

    delivery, transaction management, split and merge (conflating, windowing, ordering)
  23. heritage systems » Productivity depends on working within the system

    context » ESB and other heritage systems infrastructure creates difficult productivity barriers for developers
  24. BPM » business activity flows » modeling, automation, execution, control,

    measurement, optimization » enterprise scope » spanning systems, employees, customers, partners
  25. "Jack of all trades, master of none, often times better

    than the master of one." Give up control to gain flexibility. Embrace new patterns to achieve balance.
  26. How does microservice architecture (MSA) help?

  27. None
  28. None
  29. None
  30. None
  31. None
  32. None
  33. None
  34. Microservices » Ubiquitous language » Well defined models & boundaries

    » Single responsibility » Independently deployable, scalable, resilient » Communicate via async messaging » Own their data » Don't expose a public API
  35. Cloud ready infrastructure

  36. We need to build applications... » that exploit clusters »

    that exploit multi-core CPUs » that work across async boundaries » that process streams
  37. Physical infrastructure » Nodes across multiple DCs are considered part

    of the same system » Physical infrastructure abstracted away from system world view
  38. Cluster infrastructure » Nodes can join or leave the cluster

    » Services are rebalanced across the cluster » Node failure doesn't equal system failure
  39. Service infrastructure » View the world through services » Service

    replicas provide elasticity and resilience » Support multiple versions of a service, etc
  40. Rethinking SOA with MSA

  41. API Gateway » Some ESB functionality is moved into API

    gateways » routing, service aggregation, security (encryption and signing), protocol conversion, legacy adapters, payload transformation, service catalog
  42. Microservices » Microservices become the core communication abstraction within a

    system » async p2p, pub/sub » streams (split and merge (conflating, windowing, ordering), complex event processing (CEP))
  43. Modeling » process choreography (BPM) becomes DDD (domain driven design)

    » single canonical model becomes many canonical models » ubiquitous language » well defined interfaces » a new business process is just another service!
  44. Transactions » transaction management (2PC) becomes the saga pattern

  45. Both service-level and infrastructure » security (encryption and signing) »

    monitoring
  46. Summary » Microservice architecture (MSA) is not a new concept

    » MSA is the evolution of SOA for a modern world (expectations, hardware, size)
  47. None
  48. None