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

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)
7. A recap of heritage systems
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
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?
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)