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.

Kevin Webber

May 05, 2016

More Decks by Kevin Webber

Other Decks in Programming


  1. 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
  2. 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)
  3. 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)
  4. 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
  5. Elements of SOA » Inter-operable services » Formal contracts (e.g,

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

    the spirit of SOA » Central control + location transparency » Rigid specifications + flexibility » Transactions + distribution » Etc
  7. 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
  8. ESB Stateful: process choreography (BPM), complex event processing (CEP), reliable

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

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

    measurement, optimization » enterprise scope » spanning systems, employees, customers, partners
  11. "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.
  12. 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
  13. We need to build applications... » that exploit clusters »

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

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

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

    replicas provide elasticity and resilience » Support multiple versions of a service, etc
  17. 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
  18. 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))
  19. 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!
  20. Summary » Microservice architecture (MSA) is not a new concept

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