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.

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