SlideShare a Scribd company logo

SOA, Microservices and Event Driven Architecture

Jeppe Cramon, profile picture
Jeppe Cramon

Microservices, event-driven architecture, and service orientation were discussed in the document. The key points covered included: 1) Microservices were developed as a reaction to monolithic architectures that had slow evolution due to poor design. 2) Splitting systems into services does not always provide proper decoupling, and can introduce accidental complexity from distributed service integration if not done properly. 3) Asynchronous event-driven communication using messages is preferable to synchronous request-response for loosely coupled microservices, as it avoids many of the issues that arise from distributed transactions.

Technology
Related topics:
Event-Driven Architecture
1 of 100
1
2
3
4
5
6
7
8
9
Most read
10
11
12
13
14
15
16
Most read
17
18
Most read
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
SOA, Microservices and Event Driven Architecture Jeppe Cramon - @jeppec Cloud Create ApS
@jeppec What are microservices?
@jeppec Microservices is an architectural style 3
@jeppec Microservices were a reaction to the slow evolution pace caused by poor Monolithic design
@jeppec Be careful not to create a distributed monolith
@jeppec When we break up big things into small pieces we invariably push the complexity to their interaction. Michael Feathers https://michaelfeathers.silvrback.com/microservices-until-macro-complexity
@jeppec Don’t split the atom
@jeppec Splitting into Services doesn’t always provide proper decoupling
@jeppec Essential complexity of 2 way integration Component Warehouse Component Order Component Billing UI Send- Invoice Save-Order Order:Save-Order()è call Warehouse:Reserve-Items() call Billing:Send-Invoice() commit() Reserve- Items Local transaction between the 3 Components
@jeppec Let’s (micro)service’ify this
@jeppec Accidental complexity from distributed service integration Warehouse Service Order Service Billing Service UI Send- Invoice Save-Order Reserve- Items Local transaction between 2 local “Services” Remote call
@jeppec Microservices turns a local functional call into a distributed problem
@jeppec With cross SERVICE integration we’re bound by the laws of distributed computing
@jeppec The 11 Fallacies of Distributed Computing These fallacies are assumptions architects, designers and developers of distributed systems are likely to make. The fallacies will be proven wrong in the long run - resulting in all sorts of troubles and pains for the solution and architects who made the assumptions. 1. The network is reliable. 2. Latency is zero. 3. Bandwidth is infinite. 4. The network is secure. 5. Topology doesn't change. 6. There is one administrator. 7. Transport cost is zero. 8. The network is homogeneous. 9. The System is atomic/monolithic 10. The System is Finished 11. Business logic can and should be centralized See https://arnon.me/wp-content/uploads/Files/fallacies.pdf
@jeppec Order:Save-Order()è call Warehouse:Reserve-Items() call Billing:Send-Invoice() if (Billing:Call-Failed:Too-Busy?) Wait-A-While() call Billing:Send-Invoice() if (Billing:Call-Failed:Too-Busy?) Wait-A-Little-While-Longer() call Billing:Send-Invoice() if (Billing:Call-Failed:IO-Error?) Save-We-Need-Check-If-Call-Billing-Succeded-After-All AND We-Need-To-Retry call Order:Save-Order and call Warehouse:Reserve-Items AND Tell-Customer-That-This-Operation-Perhaps-Went-Well if (Billing:Call-Went-Well?) commit() Accidental complexity from distributed service integration Warehouse Service Order Service Billing Service UI Send- Invoice Save-Order Reserve- Items Local transaction between 2 Components
@jeppec “A distributed system is one where a machine I’ve never heard of can cause my program to fail” — Leslie Lamport
@jeppec Service autonomy Order Inventory Shipping Retail System Shipping Order Inventory Retail System Slow/unreliable network Different SLA Slow system
@jeppec Availability goes down (without additional instances of each service) Availability: 99% Availability: 99% Availability: 99% Combined availability: 97%
@jeppec Remote Call Aka. RPC/REST/SOAP/GraphQL/OData… a.k.a. Pull M odel
@jeppec What’s the challenge using state mutating Request/Response calls between distributed components?
@jeppec Synchronous Request/Response lowers our tolerance for faults • When you get an IO error • When servers crash or restarts • When databases are down • When deadlocks occurs in our databases • Do you retry? With synchronous Request/Response we can loose business data if there’s no automatic retry mechanism. Also if the operation we retry isn’t idempotent* we risk having the side effect multiple times! Client Server Processing The same message can be processed more than once *Idempotence describes the quality of an operation in which result and state does not change if the operation is performed more than 1 time Request Processing Duplicated Request Duplicated Response Response
@jeppec Idempotence Don’t press the button twice!
@jeppec What about cascading failures? • In Microservice solutions that predominantly use Request/Response style integration we often see services calling services calling services. • In such a setup one service aggressively retrying failed requests can potentially bring down the other service, which in effect can cause other services to fail, which again can cause other services to fail. • Performance is often also affected • End to end latency can be several seconds • Requires additional implementation code like: • circuit breakers • request/concurrency limiters • infrastructure like a Service Mesh
@jeppec Ensuring transactional consistency becomes much harder
@jeppec Sales system Sales Update customer status (e.g. Gold customer) Bookkeeping Deliver goods Delivery system Deliveries Customer/ CRM system Customers SAP Bookkeeping Complete Purchase Transaction Coordinator Transactional Resource Request-to-Prepare Commit Prepared Done Prepare Phase Commit Phase 2 Phase Commit
@jeppec What’s wrong with distributed transactions? • Transactions lock resources while active • Services are autonomous • Can’t be expected to finish within a certain time interval • Locking keeps other transactions from completing their job • Locking doesn’t scale • X Phase Commit is fragile by design
@jeppec Smaller models & clear data ownership Retail System Pricing Product ProductID Unit Price Promotional Price … Pricing Inventory Product ProductID SKU QOH Location Code … Inventory Sales Product ProductID Name Description Quantity Ordered … Sales Shared Entity identity DDD: Bounded Context Business Capability
@jeppec If we align the problem domain with the solution domain Bounded Context 1 Bounded Context 3 Bounded Context 2 UI BL DAO UI BL DAO UI BL DAO Vertical coupling is unavoidable We want to avoid horizontal coupling
@jeppec What are the solution domain blocks? 29
@jeppec A Service is • The technical authority for a given bounded context • It is the owner of all the data and business rules that support this bounded context – everywhere • It forms a single source of truth for that bounded context http://udidahan.com/2010/11/15/the-known-unknowns-of-soa/
@jeppec We must split into Service that are truly loosely coupled The don’t requrie Request Response style interaction between each other and which don’t require local data duplication of other services data (in order to avoid Request Response calls to other Services)
@jeppec Services are autonomous For a service to be autonomous is must NOT share state DB Service A Service B storeStuff(id, data) handleStuff(id) readStuff(id) : data
@jeppec Services are autonomous Autonomy is essential for Scalability (scale out clustering) Reliability (fail over clustering)
@jeppec Services are autonomous Autonomy is essential for Reusability Adaptability
@jeppec Be aware of Conways Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” Teams are typically aligned with Systems and NOT with Services as they should Said another way: How you organize yourself, determines your architecture
@jeppec Business Capability alignment “The advantage of business capabilities is their remarkable level of stability. If we take a typical insurance organisation, it will likely have sales, marketing, policy administration, claims management, risk assessment, billing, payments, customer service, human resource management, rate management, document management, channel management, commissions management, compliance, IT support and human task management capabilities. In fact, any insurance organisation will very likely have many of these capabilities.” See http://bill-poole.blogspot.dk/2008/07/business- capabilities.html
@jeppec Business – IT alignment • We want the Business and IT to speak the same Ubiquitous language • Want want our architecture to be aligned with the business capabilities • Because these capabilities are stable
@jeppec How should Services communicate?
@jeppec Service communication Model our data and usecases, so that all our overall usecase can be turned into a set of independent transactions that are asynchronously chained. Accept Order ? Receive Payment ? Ship Order
@jeppec But surely RPC is the only way to coordinate this?
@jeppec Synchronous calls are the crystal meth of programming At first you make good progress but then the sheer horror becomes evident when you realise the scalability limitations and how the brittleness holds back both performance and development flexibility. By then it is too late to save. http://www.infoq.com/news/2014/10/thompson-reactive-manifesto-2 We need the reactive properties and then apply protocols for the message interactions. Without considering the protocols of interaction this world of micro-services will become a coordination nightmare. Martin Thompson
@jeppec Coupling matrix* * Modified version of Ian Robinson’s matrix: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/ Behavioral coupling Temporal coupling Low High Low High Reactive/ Event oriented Command oriented Emergency services Distributed 3 layer
@jeppec Events An Event is non-prescriptive of what should happen in other parts of the system. An event will typically be published to multiple consumers/subscribers: • The publisher of the event does not know who the subscribers are • And the publisher doesn’t know what the subscribers intend to do with the event Events always carry a name in its past-tense form: OrderWasAccepted OrderHasShipped CustomerWasReimbursed “An Event describes a FACT, i.e. something that HAS happened”
@jeppec Business Event as JSON Message { EventType: "OrderWasAccepted", CustomerId: "50D1F244-ABBC-4EC7-BDCA-E4934C124A89", OrderId: "C199322A-01F1-4E56-918E-7A63529F8FA3", ShippingAddress: { ... } BillingAddress: { ... } Items: [ { ProductId: "4CD22C4B-600C-4477-B5BF-48ABDEE4DA61", Amount: "100", AmountUnit: "Pieces", UnitPrice: "100,10", UnitCurrency: "EUR" }, { ProductId: "56E6BD19-660C-464A-9120-100DAF579855", Amount: "10", AmountUnit: "Litres", UnitPrice: "56,95", UnitCurrency: "CHF" } ] }
@jeppec Internal vs External Events { EventType: ”OrderWasPaid", CustomerId: "50D1F244-ABBC-4EC7-BDCA-E4934C124A89", OrderId: "C199322A-01F1-4E56-918E-7A63529F8FA3", Amount: ….. } Internal Event: { EventType: "OrderWasPaid", OrderId: "C199322A-01F1-4E56-918E-7A63529F8FA3" } External Event: Don’t share more than absolutely necessary. In many cases EventType, EntityId and a MessageId is sufficient
@jeppec This means we must switch from a Request/Response (pull) to a Reactive (push) model A change with profound consequences
@jeppec Commands & Events • Commands mutate Aggregate state which results in one or more Events being issued/published. Command Event(s) AcceptOrder OrderAccepted ShipOrder OrderShipped AddComment CommentAdded QuarantineReview ReviewQuarantined UnquarantineReview ReviewUnquarantined
@jeppec Example public class OrderService { public void handle(AcceptOrder cmd) { orderRepository.add(new Order(cmd.orderId, cmd.orderLines)); eventBus.publish(new OrderAccepted(cmd.orderId, cmd.orderLines)); } Be aware of the Dual Write problem. Use the Outbox Pattern or Event Sourcing
@jeppec Using Business Events to drive Business Processes Sales Service Shipping Billing Sales Customers Message Channel Online Ordering System Web Shop (Composite UI) Billing Service Warehouse Service <<External>> Order Paid MarkOrderAs Paid The sales fulfillment processing can now begin… Cmd Handler Order Paid Apply
@jeppec Business Processes
@jeppec We need to change focus from short technical transactions To long running business transactions supporting business processes
@jeppec Choreographed Event Driven Processes Sales Service Order Paid Billing Service Shipping Service Warehouse Service Online Ordering System Message Channel (e.g. a Topic) Order Paid Customer Invoiced Order Paid Items Reserved Order Paid Shipping process works as a Finite State Machine (WorkFlow) handling the life cycle of Shipping and thereby forms a very central new Aggregate in the System Items Reserved
@jeppec Topic style asynchronous messaging with a Message broker Aka. Smart pipes and “dumb” endpoints Service X Publisher Data and flow direction Message infrastructure (e.g. Kafka, RabbitMQ, QBus) Service Z Subscriber Service Y Subscriber Service M Subscriber Topic
@jeppec There are only two hard problems in distributed systems 2. Exactly Once Delivery 1. Guaranteed Order of Messages 2. Exactly Once Delivery @mathiasverraes
@jeppec Things are not quite the same In a distributed system the order in which messages arrive is not guaranteed In a distributed systems message delivery can and will fail! Messages can be delivered according to these guarantees: • At Most Once – If you don’t care about loosing messages • Page visits • Ad views • Exactly Once • Not really possible • At Least Once • For everything else – which is why: Everything that can handle messages must be built with idempotency in mind!
@jeppec Process Managers • Process Managers are essential to the coordination and monitoring of long running business processes/transactions • They work as a Finite State Machines (WorkFlow) which handling the life cycle of Process (e.g. Shipping an Order) and thereby forms a very central new Aggregate in the System • They can include manual steps/person intervention • Sometimes these Process Managers belong naturally within a specific Business capability and other times they are truly and thing by themselves and often form new business capabilities that way Many companies derive their competitive advantages from their Processes. A Process Manager allows you coordinate Business Processes on the basis of Events
@jeppec Important! Figure out who owns the process
@jeppec Equally important! Focus on identifying IF you’re within the happy path of the process From a ROI perspective many edge cases are better handled by humans than trying to automate them
@jeppec What about consistency when we’re using aynchronous events?
@jeppec Eventual consistency • Consistency is with each Service • Eventual consistency is between Services • Like in the real world Sales Invoicing Inventory Shipping Order Accepted Invoice Customer Checks Inventory for availability Books truck driver Order Packaged Fetch Package from Inventory Customer Invoiced
@jeppec 61
@jeppec Service and deployment • A Service represents a logical responsibility boundary • Logical responsibility and physical deployment of a Service DOES NOT have to be 1-to-1 • It’s too constraining • We need more degrees of freedom • Philippe Krutchen 4+1 views of architecture: Logical and Physical designs should be independent of each other A service needs to be deployed everywhere its data is needed
@jeppec
@jeppec Service Microservices 1..* Is implemented by A Service is the technical authority of a specific Bounded-Context/Business Capability e.g. Sales, Shipping, Billing Service vs Microservices
@jeppec Service Microservices 1..* Is implemented by Service vs Microservices Microservices are a division of Services along Transactional boundaries (a transaction stays within the boundary of a Microservice) Microservices are the individual deployable units of a Service with their own Endpoints. Could e.g. be the split between Read and Write models (CQRS) - each would be their own Microservices
@jeppec A Service represents a logical boundary 66 Service Microservice Microservice Microservice Microservice
@jeppec Services are the corner stone • We talk in terms of Services capabilities and the processes/use-cases they support • Microservices are an implementation detail • They are much less stable (which is a good thing – it means they’re easier to replace)
@jeppec Service deployment • Many services can be deployed to the same physical server • Many services can be deployed in the same application • Application boundary is a Process boundary which is a physical boundary • A Service is a logical boundary • Service deployment is not restricted to tiers either • Part of service A and B can be deployed to the Web tier • Another part of Service A and B can be deployed to the backend/app-service tier of the same application • The same service can be deployed to multiple tiers / multiple applications • ie. applications and services are not the same and does not share the same boundaries • Multiple services can be “deployed” to the same UI page (service mashup)
@jeppec What about Security Is Security a Service? • If it’s technical YES • Example: Authentication & Authorization • If it’s a business related, i.e. Business rule, – NO • Then it belongs inside the Service responsible for this business capability • Example: Who’s allowed to authorize large transfers or who’s allowed to reimburse the customer
@jeppec There’s cost in deploying 1000’s of microservices (or 100.000’s serverless functions)
@jeppec Autonomous Components Not everything needs to be individually deployable
@jeppec This means they CAN, but they don’t HAVE to be deployed individually. Design for Distribution But take advantage of locality
@jeppec Let’s be even more pragmatic In which case we allow other services to call them using local calls
@jeppec Autonomous Component in code public class PricingEngineAc extends AutonomousComponent { public static AutonomousComponentId SERVICE_AC_ID = SALES_SERVICE_ID.ac(”pricing_engine_ac"); … public PricingEngineAc(CurrencyConverter currencyConverter) { this.currencyConverter = currencyConverter; } @Override public void onInitialize(IConfigureACEnvironment acSetup) { acSetup.withAutonomousComponentId(SERVICE_AC_ID) .usingServiceDataSource() .withBusConfiguration(cfg -> { bus.registerReplayableTopicPublisher(InternalPricingEvents.TOPIC_NAME, replayFromAggregate(Pricing.class) .dispatchAggregateEventsOfType(InternalPricingEvents.class)); bus.subscribeTopic(SERVICE_AC_ID.topicSubscriber(”InventoryEvents"), ExternalInventoryEvents.TOPIC_NAME, new InventoryTopicSubscription(bus)); }) .runOnBusStartup((bus, axonContext) -> { }); } }
@jeppec Autonomous Component • Can be deployed alone or co-located, together with one or more adapters from the same service • Works transparently in a clustered environment Core logic (use case controllers/aggregates) Primary/Driving Adapter GUI / API / … Primary/Driving Port Secondary/Driven Adapter Database/Notifications/… Secondary/Driven Port
@jeppec Alternative visualization of a Layered architecture Infrastructure Data Access Logic Business Logic User Interface Tests DB File WebService The application is built around data access and other infrastructure. Because of this coupling, when data access, web services, etc. change, the business logic layer will also have to change
@jeppec Clean Architecture / Onion Architecture Domain Model (Entities, Aggregates) Use Cases Controllers D e v i c e s External Interfaces DB File WebService P r e s e n t e r s G ateways W eb DB U I Enterprise Business Rules Application Business Rules Interface Adapters Frameworks & Drivers
@jeppec Autonomous Components can be co-deployed together with Application backends web_shop (Spring Boot fat–jar) pricing_engine_ac discounts_ac webshop_basket_adapters api_products product_details_ac product_details_adapters frontend api_pricing app libs products pricing branding Docker is NOT a requirement - KISS
@jeppec Application in code @Configuration @ComponentScan(basePackages = { "com.mycoolshop.webshop", "com.mycoolshop.adapters", "com.mycoolshop.itops.spring" }) public class Application extends IAmASpringBootApplication { @Override protected ApplicationIdentifier getApplicationIdentifier() { return ApplicationIdentifier.from(”WebShop"); } @Override protected Collection<AutonomousComponent> getAutonomousComponentsHostedInThisApplication() { CurrencyExchangeRateAc currencyExchangeRateAc = new CurrencyExchangeRateAc(); return list( new PricingEngineAc(currencyExchangeRateAc.getCurrencyConverter()), new DiscountsAc(currencyExchangeRateAc.getCurrencyConverter()), new InventoryAc(), new CustomersAc(), currencyExchangeRateAc ); } public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
@jeppec AC, autonomy and “shared” service data Service DB DB Autonomous Component Autonomous Component Autonomous Component Autonomous Component DB
@jeppec 50 shades of inter service AC Autonomy* Endpoint Process Database Storage Shared Shared Shared Shared Own Shared Shared Shared Own Own Shared Shared Own Shared Own Shared Own Own Own Shared Own Own Own Own Lower Autonomy Higher Autonomy * No RPC in use!
@jeppec How do we bring things together for our users without introducing unnecessary coupling?
How to avoid recoupling when we decoupled?
@jeppec Let’s look at Applications
@jeppec iOS Home Banking Customer information Legal and contract information Accounts
@jeppec iOS Home banking Customer information Legal and contract information Accounts Credit card Mortgage loans Web banking portal Bank Back-office application
@jeppec Let’s assume we have these services Currency Service Customer Service Identity Management Service Sales Service Inventory Service Products Service IT Operations Shipping Service Web Shop
@jeppec Back-end for Front-end? Client Remote Facade DTOs Identity Management Service Customer Service Products Service Sales Service Inventory Service Shipping Service Currency Service IT Operations
@jeppec Realization A Service can own its own Business UI components
@jeppec Service A Service B Service C IT-OPS Web shop Warehouse Back office App logic (Layered, CQRS,…) Warehouse Storage UI Components A Services owns its UI Components
@jeppec
@jeppec
@jeppec Composite page example Page Context: {id: ISBN-10 0-321-83457-7 } Images Books Reviews Pricing Inventory OthersAlsoBought Pricing Reviews Books Images Books
@jeppec A Service represents a logical boundary Service Microservice Autonomous Component Adapter UI component
@jeppec An Application is the plate where Components are co-deployed Sales service components Inventory service components …
@jeppec An UI is composed of widgets from different services
@jeppec Service Widget Service Widget Page Service Widget Service Widget Service Widget • Overall structure of the page is “owned” by the application. • Each service widget is independent Composite page layout Service Widget Service Widget Service Widget Service Widget
@jeppec
@jeppec Page Rendering Example Page Ctrl Sales Service UI Broker Customer Service Pricing Service Product Service Page Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl 1. Backend API Backend API Backend API Backend API 2. 3. 4. 5. 5. 6. 7. 7. 7. 7. 5. 8. 8. 8. 8.
@jeppec For more see Blog: https://cramonblog.wordpress.com/ Homepage: http://cloudcreate.dk/ Twitter: @jeppec

More Related Content

PDF
CQRS and event sourcing
Jeppe Cramon
 
PDF
The Dual write problem
Jeppe Cramon
 
PDF
Introduction to Event-Driven Architecture
Solace
 
PPTX
Updated: Should you be using an Event Driven Architecture
Jeppe Cramon
 
KEY
Event Driven Architecture
Stefan Norberg
 
PPTX
Distributed tracing 101
Itiel Shwartz
 
PDF
SRE & Kubernetes
Afkham Azeez
 
KEY
Event Driven Architecture
Chris Patterson
 
CQRS and event sourcing
Jeppe Cramon
 
The Dual write problem
Jeppe Cramon
 
Introduction to Event-Driven Architecture
Solace
 
Updated: Should you be using an Event Driven Architecture
Jeppe Cramon
 
Event Driven Architecture
Stefan Norberg
 
Distributed tracing 101
Itiel Shwartz
 
SRE & Kubernetes
Afkham Azeez
 
Event Driven Architecture
Chris Patterson
 

What's hot (20)

PPTX
Introduction to microservices
Anil Allewar
 
PPTX
Event driven architecture
Shadrach Jabonir
 
PPTX
DevOps seminar ppt
DurgashambaviAmarnen
 
PDF
Microservices architecture
Abdelghani Azri
 
PDF
Event-Driven Architecture (EDA)
WSO2
 
PDF
Process Automation: an Update from the Trenches
Kris Verlaenen
 
PDF
Event Storming and Saga
Araf Karsh Hamid
 
PDF
Understanding MicroSERVICE Architecture with Java & Spring Boot
Kashif Ali Siddiqui
 
PPTX
Microservice vs. Monolithic Architecture
Paul Mooney
 
PDF
Introduction to Spring webflux
Knoldus Inc.
 
PDF
A Pattern Language for Microservices
Chris Richardson
 
PPTX
Microservice architecture design principles
Sanjoy Kumar Roy
 
PPSX
Agile, User Stories, Domain Driven Design
Araf Karsh Hamid
 
PPSX
Microservices, DevOps & SRE
Araf Karsh Hamid
 
PPTX
Introduction To Microservices
Lalit Kale
 
PDF
Cloud-Native Observability
Tyler Treat
 
PPTX
Stability Patterns for Microservices
pflueras
 
PDF
Exploring the power of OpenTelemetry on Kubernetes
Red Hat Developers
 
PDF
Service Mesh with Apache Kafka, Kubernetes, Envoy, Istio and Linkerd
Kai Wähner
 
PPTX
Introduction to Microservices
Roger van de Kimmenade
 
Introduction to microservices
Anil Allewar
 
Event driven architecture
Shadrach Jabonir
 
DevOps seminar ppt
DurgashambaviAmarnen
 
Microservices architecture
Abdelghani Azri
 
Event-Driven Architecture (EDA)
WSO2
 
Process Automation: an Update from the Trenches
Kris Verlaenen
 
Event Storming and Saga
Araf Karsh Hamid
 
Understanding MicroSERVICE Architecture with Java & Spring Boot
Kashif Ali Siddiqui
 
Microservice vs. Monolithic Architecture
Paul Mooney
 
Introduction to Spring webflux
Knoldus Inc.
 
A Pattern Language for Microservices
Chris Richardson
 
Microservice architecture design principles
Sanjoy Kumar Roy
 
Agile, User Stories, Domain Driven Design
Araf Karsh Hamid
 
Microservices, DevOps & SRE
Araf Karsh Hamid
 
Introduction To Microservices
Lalit Kale
 
Cloud-Native Observability
Tyler Treat
 
Stability Patterns for Microservices
pflueras
 
Exploring the power of OpenTelemetry on Kubernetes
Red Hat Developers
 
Service Mesh with Apache Kafka, Kubernetes, Envoy, Istio and Linkerd
Kai Wähner
 
Introduction to Microservices
Roger van de Kimmenade
 
Ad

Similar to SOA, Microservices and Event Driven Architecture (20)

PPTX
Should you be using an event driven architecture - IDA IT (short version)
Jeppe Cramon
 
PPTX
Alternative microservices - one size doesn't fit all
Jeppe Cramon
 
PPTX
What 5 years of implementation microservices has taught me
Jeppe Cramon
 
PPTX
The "Why", "What" & "How" of Microservices - short version
INPAY
 
PDF
CWIN17 Utrecht / cg u services - frank van der wal
Capgemini
 
PPTX
The "Why", "What" and "How" of Microservices
INPAY
 
PPTX
Jeffrey Richter
CodeFest
 
PPTX
Microservices for performance - GOTO Chicago 2016
Peter Lawrey
 
PDF
MuCon 2015 - Microservices in Integration Architecture
Kim Clark
 
PDF
Devoxx London 2017 - Rethinking Services With Stateful Streams
Ben Stopford
 
PDF
How to Migrate Applications Off a Mainframe
VMware Tanzu
 
PPTX
Should you be using an event driven architecture?
Jeppe Cramon
 
PDF
We are drowning in complexity—can we do better?
Jonas Bonér
 
PPTX
CQRS recipes or how to cook your architecture
Thomas Jaskula
 
PDF
Richardrodger nodeday-2014-final
Richard Rodger
 
PDF
Richardrodger nodeday-2014-final
Richard Rodger
 
PPTX
SQLBits VI - Improving database performance by removing the database
Simon Munro
 
PDF
Streaming is a Detail
HostedbyConfluent
 
PDF
Advanced web application architecture - Talk
Matthias Noback
 
PPT
VMWare Wpg Jeff Franz-Lien
jfranzlien
 
Should you be using an event driven architecture - IDA IT (short version)
Jeppe Cramon
 
Alternative microservices - one size doesn't fit all
Jeppe Cramon
 
What 5 years of implementation microservices has taught me
Jeppe Cramon
 
The "Why", "What" & "How" of Microservices - short version
INPAY
 
CWIN17 Utrecht / cg u services - frank van der wal
Capgemini
 
The "Why", "What" and "How" of Microservices
INPAY
 
Jeffrey Richter
CodeFest
 
Microservices for performance - GOTO Chicago 2016
Peter Lawrey
 
MuCon 2015 - Microservices in Integration Architecture
Kim Clark
 
Devoxx London 2017 - Rethinking Services With Stateful Streams
Ben Stopford
 
How to Migrate Applications Off a Mainframe
VMware Tanzu
 
Should you be using an event driven architecture?
Jeppe Cramon
 
We are drowning in complexity—can we do better?
Jonas Bonér
 
CQRS recipes or how to cook your architecture
Thomas Jaskula
 
Richardrodger nodeday-2014-final
Richard Rodger
 
Richardrodger nodeday-2014-final
Richard Rodger
 
SQLBits VI - Improving database performance by removing the database
Simon Munro
 
Streaming is a Detail
HostedbyConfluent
 
Advanced web application architecture - Talk
Matthias Noback
 
VMWare Wpg Jeff Franz-Lien
jfranzlien
 
Ad

Recently uploaded (20)

PDF
Shreyas Phanse Resume: Experienced Backend Engineer | Java • Spring Boot • Ka...
SHREYAS PHANSE
 
PDF
Advanced methodologies resolving dimensionality complications for autism neur...
IAESIJAI
 
PDF
Encapsulation theory and applications.pdf
gurumoop
 
PPT
“AI and Expert System Decision Support & Business Intelligence Systems”
ZubinRadhakrishnan
 
PDF
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Akar16
 
PPTX
Digital-Transformation-Roadmap-for-Companies.pptx
David Malick Dieng
 
PDF
NewMind AI Monthly Chronicles - July 2025
NewMind AI
 
PDF
Empathic Computing: Creating Shared Understanding
Mark Billinghurst
 
PPTX
PA Analog/Digital System: The Backbone of Modern Surveillance and Communication
AVTRON Technologies LLC
 
PDF
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
Peter Tan
 
PDF
Mobile App Security Testing_ A Comprehensive Guide.pdf
flufftailshop
 
PDF
Electronic commerce courselecture one. Pdf
OmerMohamed64
 
PDF
Chapter 3 Spatial Domain Image Processing.pdf
Getnet Tigabie Askale -(GM)
 
PDF
TokAI - TikTok AI Agent : The First AI Application That Analyzes 10,000+ Vira...
SOFTTECHHUB
 
PPTX
Detection-First SIEM: Rule Types, Dashboards, and Threat-Informed Strategy
ReZa AdineH
 
PDF
Review of recent advances in non-invasive hemoglobin estimation
IAESIJAI
 
PDF
Spectral efficient network and resource selection model in 5G networks
IAESIJAI
 
PDF
Approach and Philosophy of On baking technology
30anthuong17
 
PDF
Dropbox Q2 2025 Financial Results & Investor Presentation
Dropbox
 
PDF
Network Security Unit 5.pdf for BCA BBA.
Serpent6
 
Shreyas Phanse Resume: Experienced Backend Engineer | Java • Spring Boot • Ka...
SHREYAS PHANSE
 
Advanced methodologies resolving dimensionality complications for autism neur...
IAESIJAI
 
Encapsulation theory and applications.pdf
gurumoop
 
“AI and Expert System Decision Support & Business Intelligence Systems”
ZubinRadhakrishnan
 
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Akar16
 
Digital-Transformation-Roadmap-for-Companies.pptx
David Malick Dieng
 
NewMind AI Monthly Chronicles - July 2025
NewMind AI
 
Empathic Computing: Creating Shared Understanding
Mark Billinghurst
 
PA Analog/Digital System: The Backbone of Modern Surveillance and Communication
AVTRON Technologies LLC
 
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
Peter Tan
 
Mobile App Security Testing_ A Comprehensive Guide.pdf
flufftailshop
 
Electronic commerce courselecture one. Pdf
OmerMohamed64
 
Chapter 3 Spatial Domain Image Processing.pdf
Getnet Tigabie Askale -(GM)
 
TokAI - TikTok AI Agent : The First AI Application That Analyzes 10,000+ Vira...
SOFTTECHHUB
 
Detection-First SIEM: Rule Types, Dashboards, and Threat-Informed Strategy
ReZa AdineH
 
Review of recent advances in non-invasive hemoglobin estimation
IAESIJAI
 
Spectral efficient network and resource selection model in 5G networks
IAESIJAI
 
Approach and Philosophy of On baking technology
30anthuong17
 
Dropbox Q2 2025 Financial Results & Investor Presentation
Dropbox
 
Network Security Unit 5.pdf for BCA BBA.
Serpent6
 

SOA, Microservices and Event Driven Architecture

  • 1. SOA, Microservices and Event Driven Architecture Jeppe Cramon - @jeppec Cloud Create ApS
  • 3. @jeppec Microservices is an architectural style 3
  • 4. @jeppec Microservices were a reaction to the slow evolution pace caused by poor Monolithic design
  • 5. @jeppec Be careful not to create a distributed monolith
  • 6. @jeppec When we break up big things into small pieces we invariably push the complexity to their interaction. Michael Feathers https://michaelfeathers.silvrback.com/microservices-until-macro-complexity
  • 8. @jeppec Splitting into Services doesn’t always provide proper decoupling
  • 9. @jeppec Essential complexity of 2 way integration Component Warehouse Component Order Component Billing UI Send- Invoice Save-Order Order:Save-Order()è call Warehouse:Reserve-Items() call Billing:Send-Invoice() commit() Reserve- Items Local transaction between the 3 Components
  • 11. @jeppec Accidental complexity from distributed service integration Warehouse Service Order Service Billing Service UI Send- Invoice Save-Order Reserve- Items Local transaction between 2 local “Services” Remote call
  • 12. @jeppec Microservices turns a local functional call into a distributed problem
  • 13. @jeppec With cross SERVICE integration we’re bound by the laws of distributed computing
  • 14. @jeppec The 11 Fallacies of Distributed Computing These fallacies are assumptions architects, designers and developers of distributed systems are likely to make. The fallacies will be proven wrong in the long run - resulting in all sorts of troubles and pains for the solution and architects who made the assumptions. 1. The network is reliable. 2. Latency is zero. 3. Bandwidth is infinite. 4. The network is secure. 5. Topology doesn't change. 6. There is one administrator. 7. Transport cost is zero. 8. The network is homogeneous. 9. The System is atomic/monolithic 10. The System is Finished 11. Business logic can and should be centralized See https://arnon.me/wp-content/uploads/Files/fallacies.pdf
  • 15. @jeppec Order:Save-Order()è call Warehouse:Reserve-Items() call Billing:Send-Invoice() if (Billing:Call-Failed:Too-Busy?) Wait-A-While() call Billing:Send-Invoice() if (Billing:Call-Failed:Too-Busy?) Wait-A-Little-While-Longer() call Billing:Send-Invoice() if (Billing:Call-Failed:IO-Error?) Save-We-Need-Check-If-Call-Billing-Succeded-After-All AND We-Need-To-Retry call Order:Save-Order and call Warehouse:Reserve-Items AND Tell-Customer-That-This-Operation-Perhaps-Went-Well if (Billing:Call-Went-Well?) commit() Accidental complexity from distributed service integration Warehouse Service Order Service Billing Service UI Send- Invoice Save-Order Reserve- Items Local transaction between 2 Components
  • 16. @jeppec “A distributed system is one where a machine I’ve never heard of can cause my program to fail” — Leslie Lamport
  • 17. @jeppec Service autonomy Order Inventory Shipping Retail System Shipping Order Inventory Retail System Slow/unreliable network Different SLA Slow system
  • 18. @jeppec Availability goes down (without additional instances of each service) Availability: 99% Availability: 99% Availability: 99% Combined availability: 97%
  • 20. @jeppec What’s the challenge using state mutating Request/Response calls between distributed components?
  • 21. @jeppec Synchronous Request/Response lowers our tolerance for faults • When you get an IO error • When servers crash or restarts • When databases are down • When deadlocks occurs in our databases • Do you retry? With synchronous Request/Response we can loose business data if there’s no automatic retry mechanism. Also if the operation we retry isn’t idempotent* we risk having the side effect multiple times! Client Server Processing The same message can be processed more than once *Idempotence describes the quality of an operation in which result and state does not change if the operation is performed more than 1 time Request Processing Duplicated Request Duplicated Response Response
  • 23. @jeppec What about cascading failures? • In Microservice solutions that predominantly use Request/Response style integration we often see services calling services calling services. • In such a setup one service aggressively retrying failed requests can potentially bring down the other service, which in effect can cause other services to fail, which again can cause other services to fail. • Performance is often also affected • End to end latency can be several seconds • Requires additional implementation code like: • circuit breakers • request/concurrency limiters • infrastructure like a Service Mesh
  • 25. @jeppec Sales system Sales Update customer status (e.g. Gold customer) Bookkeeping Deliver goods Delivery system Deliveries Customer/ CRM system Customers SAP Bookkeeping Complete Purchase Transaction Coordinator Transactional Resource Request-to-Prepare Commit Prepared Done Prepare Phase Commit Phase 2 Phase Commit
  • 26. @jeppec What’s wrong with distributed transactions? • Transactions lock resources while active • Services are autonomous • Can’t be expected to finish within a certain time interval • Locking keeps other transactions from completing their job • Locking doesn’t scale • X Phase Commit is fragile by design
  • 27. @jeppec Smaller models & clear data ownership Retail System Pricing Product ProductID Unit Price Promotional Price … Pricing Inventory Product ProductID SKU QOH Location Code … Inventory Sales Product ProductID Name Description Quantity Ordered … Sales Shared Entity identity DDD: Bounded Context Business Capability
  • 28. @jeppec If we align the problem domain with the solution domain Bounded Context 1 Bounded Context 3 Bounded Context 2 UI BL DAO UI BL DAO UI BL DAO Vertical coupling is unavoidable We want to avoid horizontal coupling
  • 29. @jeppec What are the solution domain blocks? 29
  • 30. @jeppec A Service is • The technical authority for a given bounded context • It is the owner of all the data and business rules that support this bounded context – everywhere • It forms a single source of truth for that bounded context http://udidahan.com/2010/11/15/the-known-unknowns-of-soa/
  • 31. @jeppec We must split into Service that are truly loosely coupled The don’t requrie Request Response style interaction between each other and which don’t require local data duplication of other services data (in order to avoid Request Response calls to other Services)
  • 32. @jeppec Services are autonomous For a service to be autonomous is must NOT share state DB Service A Service B storeStuff(id, data) handleStuff(id) readStuff(id) : data
  • 33. @jeppec Services are autonomous Autonomy is essential for Scalability (scale out clustering) Reliability (fail over clustering)
  • 34. @jeppec Services are autonomous Autonomy is essential for Reusability Adaptability
  • 35. @jeppec Be aware of Conways Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” Teams are typically aligned with Systems and NOT with Services as they should Said another way: How you organize yourself, determines your architecture
  • 36. @jeppec Business Capability alignment “The advantage of business capabilities is their remarkable level of stability. If we take a typical insurance organisation, it will likely have sales, marketing, policy administration, claims management, risk assessment, billing, payments, customer service, human resource management, rate management, document management, channel management, commissions management, compliance, IT support and human task management capabilities. In fact, any insurance organisation will very likely have many of these capabilities.” See http://bill-poole.blogspot.dk/2008/07/business- capabilities.html
  • 37. @jeppec Business – IT alignment • We want the Business and IT to speak the same Ubiquitous language • Want want our architecture to be aligned with the business capabilities • Because these capabilities are stable
  • 39. @jeppec Service communication Model our data and usecases, so that all our overall usecase can be turned into a set of independent transactions that are asynchronously chained. Accept Order ? Receive Payment ? Ship Order
  • 40. @jeppec But surely RPC is the only way to coordinate this?
  • 41. @jeppec Synchronous calls are the crystal meth of programming At first you make good progress but then the sheer horror becomes evident when you realise the scalability limitations and how the brittleness holds back both performance and development flexibility. By then it is too late to save. http://www.infoq.com/news/2014/10/thompson-reactive-manifesto-2 We need the reactive properties and then apply protocols for the message interactions. Without considering the protocols of interaction this world of micro-services will become a coordination nightmare. Martin Thompson
  • 42. @jeppec Coupling matrix* * Modified version of Ian Robinson’s matrix: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/ Behavioral coupling Temporal coupling Low High Low High Reactive/ Event oriented Command oriented Emergency services Distributed 3 layer
  • 43. @jeppec Events An Event is non-prescriptive of what should happen in other parts of the system. An event will typically be published to multiple consumers/subscribers: • The publisher of the event does not know who the subscribers are • And the publisher doesn’t know what the subscribers intend to do with the event Events always carry a name in its past-tense form: OrderWasAccepted OrderHasShipped CustomerWasReimbursed “An Event describes a FACT, i.e. something that HAS happened”
  • 44. @jeppec Business Event as JSON Message { EventType: "OrderWasAccepted", CustomerId: "50D1F244-ABBC-4EC7-BDCA-E4934C124A89", OrderId: "C199322A-01F1-4E56-918E-7A63529F8FA3", ShippingAddress: { ... } BillingAddress: { ... } Items: [ { ProductId: "4CD22C4B-600C-4477-B5BF-48ABDEE4DA61", Amount: "100", AmountUnit: "Pieces", UnitPrice: "100,10", UnitCurrency: "EUR" }, { ProductId: "56E6BD19-660C-464A-9120-100DAF579855", Amount: "10", AmountUnit: "Litres", UnitPrice: "56,95", UnitCurrency: "CHF" } ] }
  • 45. @jeppec Internal vs External Events { EventType: ”OrderWasPaid", CustomerId: "50D1F244-ABBC-4EC7-BDCA-E4934C124A89", OrderId: "C199322A-01F1-4E56-918E-7A63529F8FA3", Amount: ….. } Internal Event: { EventType: "OrderWasPaid", OrderId: "C199322A-01F1-4E56-918E-7A63529F8FA3" } External Event: Don’t share more than absolutely necessary. In many cases EventType, EntityId and a MessageId is sufficient
  • 46. @jeppec This means we must switch from a Request/Response (pull) to a Reactive (push) model A change with profound consequences
  • 47. @jeppec Commands & Events • Commands mutate Aggregate state which results in one or more Events being issued/published. Command Event(s) AcceptOrder OrderAccepted ShipOrder OrderShipped AddComment CommentAdded QuarantineReview ReviewQuarantined UnquarantineReview ReviewUnquarantined
  • 48. @jeppec Example public class OrderService { public void handle(AcceptOrder cmd) { orderRepository.add(new Order(cmd.orderId, cmd.orderLines)); eventBus.publish(new OrderAccepted(cmd.orderId, cmd.orderLines)); } Be aware of the Dual Write problem. Use the Outbox Pattern or Event Sourcing
  • 49. @jeppec Using Business Events to drive Business Processes Sales Service Shipping Billing Sales Customers Message Channel Online Ordering System Web Shop (Composite UI) Billing Service Warehouse Service <<External>> Order Paid MarkOrderAs Paid The sales fulfillment processing can now begin… Cmd Handler Order Paid Apply
  • 51. @jeppec We need to change focus from short technical transactions To long running business transactions supporting business processes
  • 52. @jeppec Choreographed Event Driven Processes Sales Service Order Paid Billing Service Shipping Service Warehouse Service Online Ordering System Message Channel (e.g. a Topic) Order Paid Customer Invoiced Order Paid Items Reserved Order Paid Shipping process works as a Finite State Machine (WorkFlow) handling the life cycle of Shipping and thereby forms a very central new Aggregate in the System Items Reserved
  • 53. @jeppec Topic style asynchronous messaging with a Message broker Aka. Smart pipes and “dumb” endpoints Service X Publisher Data and flow direction Message infrastructure (e.g. Kafka, RabbitMQ, QBus) Service Z Subscriber Service Y Subscriber Service M Subscriber Topic
  • 54. @jeppec There are only two hard problems in distributed systems 2. Exactly Once Delivery 1. Guaranteed Order of Messages 2. Exactly Once Delivery @mathiasverraes
  • 55. @jeppec Things are not quite the same In a distributed system the order in which messages arrive is not guaranteed In a distributed systems message delivery can and will fail! Messages can be delivered according to these guarantees: • At Most Once – If you don’t care about loosing messages • Page visits • Ad views • Exactly Once • Not really possible • At Least Once • For everything else – which is why: Everything that can handle messages must be built with idempotency in mind!
  • 56. @jeppec Process Managers • Process Managers are essential to the coordination and monitoring of long running business processes/transactions • They work as a Finite State Machines (WorkFlow) which handling the life cycle of Process (e.g. Shipping an Order) and thereby forms a very central new Aggregate in the System • They can include manual steps/person intervention • Sometimes these Process Managers belong naturally within a specific Business capability and other times they are truly and thing by themselves and often form new business capabilities that way Many companies derive their competitive advantages from their Processes. A Process Manager allows you coordinate Business Processes on the basis of Events
  • 58. @jeppec Equally important! Focus on identifying IF you’re within the happy path of the process From a ROI perspective many edge cases are better handled by humans than trying to automate them
  • 59. @jeppec What about consistency when we’re using aynchronous events?
  • 60. @jeppec Eventual consistency • Consistency is with each Service • Eventual consistency is between Services • Like in the real world Sales Invoicing Inventory Shipping Order Accepted Invoice Customer Checks Inventory for availability Books truck driver Order Packaged Fetch Package from Inventory Customer Invoiced
  • 62. @jeppec Service and deployment • A Service represents a logical responsibility boundary • Logical responsibility and physical deployment of a Service DOES NOT have to be 1-to-1 • It’s too constraining • We need more degrees of freedom • Philippe Krutchen 4+1 views of architecture: Logical and Physical designs should be independent of each other A service needs to be deployed everywhere its data is needed
  • 64. @jeppec Service Microservices 1..* Is implemented by A Service is the technical authority of a specific Bounded-Context/Business Capability e.g. Sales, Shipping, Billing Service vs Microservices
  • 65. @jeppec Service Microservices 1..* Is implemented by Service vs Microservices Microservices are a division of Services along Transactional boundaries (a transaction stays within the boundary of a Microservice) Microservices are the individual deployable units of a Service with their own Endpoints. Could e.g. be the split between Read and Write models (CQRS) - each would be their own Microservices
  • 66. @jeppec A Service represents a logical boundary 66 Service Microservice Microservice Microservice Microservice
  • 67. @jeppec Services are the corner stone • We talk in terms of Services capabilities and the processes/use-cases they support • Microservices are an implementation detail • They are much less stable (which is a good thing – it means they’re easier to replace)
  • 68. @jeppec Service deployment • Many services can be deployed to the same physical server • Many services can be deployed in the same application • Application boundary is a Process boundary which is a physical boundary • A Service is a logical boundary • Service deployment is not restricted to tiers either • Part of service A and B can be deployed to the Web tier • Another part of Service A and B can be deployed to the backend/app-service tier of the same application • The same service can be deployed to multiple tiers / multiple applications • ie. applications and services are not the same and does not share the same boundaries • Multiple services can be “deployed” to the same UI page (service mashup)
  • 69. @jeppec What about Security Is Security a Service? • If it’s technical YES • Example: Authentication & Authorization • If it’s a business related, i.e. Business rule, – NO • Then it belongs inside the Service responsible for this business capability • Example: Who’s allowed to authorize large transfers or who’s allowed to reimburse the customer
  • 70. @jeppec There’s cost in deploying 1000’s of microservices (or 100.000’s serverless functions)
  • 71. @jeppec Autonomous Components Not everything needs to be individually deployable
  • 72. @jeppec This means they CAN, but they don’t HAVE to be deployed individually. Design for Distribution But take advantage of locality
  • 73. @jeppec Let’s be even more pragmatic In which case we allow other services to call them using local calls
  • 74. @jeppec Autonomous Component in code public class PricingEngineAc extends AutonomousComponent { public static AutonomousComponentId SERVICE_AC_ID = SALES_SERVICE_ID.ac(”pricing_engine_ac"); … public PricingEngineAc(CurrencyConverter currencyConverter) { this.currencyConverter = currencyConverter; } @Override public void onInitialize(IConfigureACEnvironment acSetup) { acSetup.withAutonomousComponentId(SERVICE_AC_ID) .usingServiceDataSource() .withBusConfiguration(cfg -> { bus.registerReplayableTopicPublisher(InternalPricingEvents.TOPIC_NAME, replayFromAggregate(Pricing.class) .dispatchAggregateEventsOfType(InternalPricingEvents.class)); bus.subscribeTopic(SERVICE_AC_ID.topicSubscriber(”InventoryEvents"), ExternalInventoryEvents.TOPIC_NAME, new InventoryTopicSubscription(bus)); }) .runOnBusStartup((bus, axonContext) -> { }); } }
  • 75. @jeppec Autonomous Component • Can be deployed alone or co-located, together with one or more adapters from the same service • Works transparently in a clustered environment Core logic (use case controllers/aggregates) Primary/Driving Adapter GUI / API / … Primary/Driving Port Secondary/Driven Adapter Database/Notifications/… Secondary/Driven Port
  • 76. @jeppec Alternative visualization of a Layered architecture Infrastructure Data Access Logic Business Logic User Interface Tests DB File WebService The application is built around data access and other infrastructure. Because of this coupling, when data access, web services, etc. change, the business logic layer will also have to change
  • 77. @jeppec Clean Architecture / Onion Architecture Domain Model (Entities, Aggregates) Use Cases Controllers D e v i c e s External Interfaces DB File WebService P r e s e n t e r s G ateways W eb DB U I Enterprise Business Rules Application Business Rules Interface Adapters Frameworks & Drivers
  • 78. @jeppec Autonomous Components can be co-deployed together with Application backends web_shop (Spring Boot fat–jar) pricing_engine_ac discounts_ac webshop_basket_adapters api_products product_details_ac product_details_adapters frontend api_pricing app libs products pricing branding Docker is NOT a requirement - KISS
  • 79. @jeppec Application in code @Configuration @ComponentScan(basePackages = { "com.mycoolshop.webshop", "com.mycoolshop.adapters", "com.mycoolshop.itops.spring" }) public class Application extends IAmASpringBootApplication { @Override protected ApplicationIdentifier getApplicationIdentifier() { return ApplicationIdentifier.from(”WebShop"); } @Override protected Collection<AutonomousComponent> getAutonomousComponentsHostedInThisApplication() { CurrencyExchangeRateAc currencyExchangeRateAc = new CurrencyExchangeRateAc(); return list( new PricingEngineAc(currencyExchangeRateAc.getCurrencyConverter()), new DiscountsAc(currencyExchangeRateAc.getCurrencyConverter()), new InventoryAc(), new CustomersAc(), currencyExchangeRateAc ); } public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
  • 80. @jeppec AC, autonomy and “shared” service data Service DB DB Autonomous Component Autonomous Component Autonomous Component Autonomous Component DB
  • 81. @jeppec 50 shades of inter service AC Autonomy* Endpoint Process Database Storage Shared Shared Shared Shared Own Shared Shared Shared Own Own Shared Shared Own Shared Own Shared Own Own Own Shared Own Own Own Own Lower Autonomy Higher Autonomy * No RPC in use!
  • 82. @jeppec How do we bring things together for our users without introducing unnecessary coupling?
  • 83. How to avoid recoupling when we decoupled?
  • 84. @jeppec Let’s look at Applications
  • 85. @jeppec iOS Home Banking Customer information Legal and contract information Accounts
  • 86. @jeppec iOS Home banking Customer information Legal and contract information Accounts Credit card Mortgage loans Web banking portal Bank Back-office application
  • 87. @jeppec Let’s assume we have these services Currency Service Customer Service Identity Management Service Sales Service Inventory Service Products Service IT Operations Shipping Service Web Shop
  • 88. @jeppec Back-end for Front-end? Client Remote Facade DTOs Identity Management Service Customer Service Products Service Sales Service Inventory Service Shipping Service Currency Service IT Operations
  • 89. @jeppec Realization A Service can own its own Business UI components
  • 90. @jeppec Service A Service B Service C IT-OPS Web shop Warehouse Back office App logic (Layered, CQRS,…) Warehouse Storage UI Components A Services owns its UI Components
  • 93. @jeppec Composite page example Page Context: {id: ISBN-10 0-321-83457-7 } Images Books Reviews Pricing Inventory OthersAlsoBought Pricing Reviews Books Images Books
  • 94. @jeppec A Service represents a logical boundary Service Microservice Autonomous Component Adapter UI component
  • 95. @jeppec An Application is the plate where Components are co-deployed Sales service components Inventory service components …
  • 96. @jeppec An UI is composed of widgets from different services
  • 97. @jeppec Service Widget Service Widget Page Service Widget Service Widget Service Widget • Overall structure of the page is “owned” by the application. • Each service widget is independent Composite page layout Service Widget Service Widget Service Widget Service Widget
  • 99. @jeppec Page Rendering Example Page Ctrl Sales Service UI Broker Customer Service Pricing Service Product Service Page Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl 1. Backend API Backend API Backend API Backend API 2. 3. 4. 5. 5. 6. 7. 7. 7. 7. 5. 8. 8. 8. 8.
  • 100. @jeppec For more see Blog: https://cramonblog.wordpress.com/ Homepage: http://cloudcreate.dk/ Twitter: @jeppec