microservices, monoliths, soa and how we got here
TRANSCRIPT
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
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)
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)
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
Elements of SOA
» Inter-operable services
» Formal contracts (e.g, WSDL)
» Multiple protocols (e.g, SOAP, RPC, REST, CORBA, etc)
» Location transparency
» ESB
SOA framework
» Problems arise when we attempt to contradict the spirit of SOA
» Central control + location transparency
» Rigid specifications + flexibility
» Transactions + distribution
» Etc
ESBStateless:
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
ESBStateful:
process choreography (BPM), complex event processing (CEP), reliable delivery, transaction management, split and merge (conflating, windowing, ordering)
heritage systems
» Productivity depends on working within the system context
» ESB and other heritage systems infrastructure creates difficult productivity barriers for developers
BPM
» business activity flows
» modeling, automation, execution, control, measurement, optimization
» enterprise scope
» spanning systems, employees, customers, partners
"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.
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
We need to build applications...
» that exploit clusters
» that exploit multi-core CPUs
» that work across async boundaries
» that process streams
Physical infrastructure
» Nodes across multiple DCs are considered part of the same system
» Physical infrastructure abstracted away from system world view
Cluster infrastructure
» Nodes can join or leave the cluster
» Services are rebalanced across the cluster
» Node failure doesn't equal system failure
Service infrastructure
» View the world through services
» Service replicas provide elasticity and resilience
» Support multiple versions of a service, etc
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
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))
Modeling» process choreography (BPM)
becomes DDD (domain driven design)
» single canonical model becomes many canonical models
» ubiquitous language
» well defined interfaces
Summary» Microservice architecture
(MSA) is not a new concept
» MSA is the evolution of SOA for a modern world (expectations, hardware, size)