$30 off During Our Annual Pro Sale. View Details »

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
Tweet

More Decks by Kevin Webber

Other Decks in Programming

Transcript

  1. View Slide

  2. View Slide

  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

    View Slide

  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)

    View Slide

  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)

    View Slide

  6. View Slide

  7. A recap of heritage
    systems

    View Slide

  8. View Slide

  9. View Slide

  10. View Slide

  11. View Slide

  12. View Slide

  13. View Slide

  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

    View Slide

  15. What is SOA?

    View Slide

  16. Elements of SOA
    » Inter-operable services
    » Formal contracts (e.g,
    WSDL)
    » Multiple protocols (e.g,
    SOAP, RPC, REST, CORBA,
    etc)
    » Location transparency
    » ESB

    View Slide

  17. SOA framework
    » Problems arise when we
    attempt to contradict the
    spirit of SOA
    » Central control +
    location transparency
    » Rigid specifications +
    flexibility
    » Transactions +
    distribution
    » Etc

    View Slide

  18. The bad parts of SOA

    View Slide

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

    View Slide

  20. View Slide

  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

    View Slide

  22. ESB
    Stateful:
    process choreography (BPM), complex event processing
    (CEP), reliable delivery, transaction management,
    split and merge (conflating, windowing, ordering)

    View Slide

  23. heritage systems
    » Productivity depends on
    working within the system
    context
    » ESB and other heritage
    systems infrastructure
    creates difficult
    productivity barriers for
    developers

    View Slide

  24. BPM
    » business activity flows
    » modeling, automation, execution, control,
    measurement, optimization
    » enterprise scope
    » spanning systems, employees, customers, partners

    View Slide

  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.

    View Slide

  26. How does microservice
    architecture (MSA) help?

    View Slide

  27. View Slide

  28. View Slide

  29. View Slide

  30. View Slide

  31. View Slide

  32. View Slide

  33. View Slide

  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

    View Slide

  35. Cloud ready
    infrastructure

    View Slide

  36. We need to build applications...
    » that exploit clusters
    » that exploit multi-core CPUs
    » that work across async boundaries
    » that process streams

    View Slide

  37. Physical
    infrastructure
    » Nodes across multiple DCs
    are considered part of the
    same system
    » Physical infrastructure
    abstracted away from system
    world view

    View Slide

  38. Cluster
    infrastructure
    » Nodes can join or leave the
    cluster
    » Services are rebalanced
    across the cluster
    » Node failure doesn't equal
    system failure

    View Slide

  39. Service
    infrastructure
    » View the world through
    services
    » Service replicas provide
    elasticity and resilience
    » Support multiple versions
    of a service, etc

    View Slide

  40. Rethinking SOA with MSA

    View Slide

  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

    View Slide

  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))

    View Slide

  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!

    View Slide

  44. Transactions
    » transaction management (2PC) becomes the saga
    pattern

    View Slide

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

    View Slide

  46. Summary
    » Microservice architecture
    (MSA) is not a new concept
    » MSA is the evolution of SOA
    for a modern world
    (expectations, hardware,
    size)

    View Slide

  47. View Slide

  48. View Slide