INPAY, profile picture
Uploaded byINPAY
868 views

The "Why", "What" & "How" of Microservices - short version

The document discusses the benefits of using a microservices architecture, including improved ability to adapt to changes quickly through reduced coupling between services, and outlines key considerations for how to structure microservices including ensuring each service owns its own data and communicating between services asynchronously using events rather than synchronous requests.

Embed presentation

1 / 141
2 / 141
3 / 141
4 / 141
5 / 141
6 / 141
7 / 141
8 / 141
9 / 141
10 / 141
11 / 141
12 / 141
13 / 141
14 / 141
15 / 141
16 / 141
17 / 141
18 / 141
19 / 141
20 / 141
21 / 141
22 / 141
23 / 141
24 / 141
25 / 141
26 / 141
27 / 141
28 / 141
29 / 141
30 / 141
31 / 141
32 / 141
33 / 141
34 / 141
35 / 141
36 / 141
37 / 141
38 / 141
39 / 141
40 / 141
41 / 141
42 / 141
43 / 141
44 / 141
45 / 141
46 / 141
47 / 141
48 / 141
49 / 141
50 / 141
51 / 141
52 / 141
53 / 141
54 / 141
55 / 141
56 / 141
57 / 141
58 / 141
59 / 141
60 / 141
61 / 141
62 / 141
63 / 141
64 / 141
65 / 141
66 / 141
67 / 141
68 / 141
69 / 141
70 / 141
71 / 141
72 / 141
73 / 141
74 / 141
75 / 141
76 / 141
77 / 141
78 / 141
79 / 141
80 / 141
81 / 141
82 / 141
83 / 141
84 / 141
85 / 141
86 / 141
87 / 141
88 / 141
89 / 141
90 / 141
91 / 141
92 / 141
93 / 141
94 / 141
95 / 141
96 / 141
97 / 141
98 / 141
99 / 141
100 / 141
101 / 141
102 / 141
103 / 141
104 / 141
105 / 141
106 / 141
107 / 141
108 / 141
109 / 141
110 / 141
111 / 141
112 / 141
113 / 141
114 / 141
115 / 141
116 / 141
117 / 141
118 / 141
119 / 141
120 / 141
121 / 141
122 / 141
123 / 141
124 / 141
125 / 141
126 / 141
127 / 141
128 / 141
129 / 141
130 / 141
131 / 141
132 / 141
133 / 141
134 / 141
135 / 141
136 / 141
137 / 141
138 / 141
139 / 141
140 / 141
141 / 141
The “Why”, “What” and of Microservices Jeppe Cramon - @jeppec Chief Architect - INPAY “How”
WHY WOULD WE WANT TO USE MICROSERVICES?
Most feel stuck with a monolith and are look for a way out “The” DB UI Logic Data Access
Microservices promise a solution to our problem Monolith Microservice Microservice Microservice MicroserviceMicroservice Microservice Microservice
Microservices as an architectural style 5
ARCHITECTURE IS ESSENTIAL Because it influences how fast we can respond to changes and what the cost of those changes are
ULTIMATELY WE WANT TO BE ABLE TO ADAPT TO CHANGES IN A CONSTANT AMOUNT OF TIME
E.G. IF YOUR PRICING MODEL WAS WRONG – YOU SHOULD BE ABLE TO CHANGE AND REDEPLOY IT IN HOURS/DAYS
SOME ORGANIZATIONS CALCULATE CHANGE TIMES IN MONTHS OR YEARS
WE ALL WANT TO MOVE FAST But can’t always move fast - for various reasons…
THE MAIN MAIN IMPEDIMENT TO OBTAINING HIGH VELOCITY IS
High coupling
Coupling causes ripple effect – much like circles in the water • You want to change a little thing and all of a sudden you need to change 25 other seemingly unrelated things • Zero coupling is impossible • Question is what is the right level of coupling? • This highly depends on how likely the component/system/service is to change and what parts that change together
The playing field Zero coupling The monolith (an indivisible unit)
It usually starts simple “The” DB UI Logic Data Access
Next step is spaghetti in layers
And finally we end up with a Big Ball Of Mud
MICROSERVICES TELL US TO MAKE THINGS SMALLER Adhering to the Single Responsibility Principle (SRP) – “A Microservice should have one reason – and only one reason – to change”
THERE IS VALUE IN MAKING THINGS SMALLER For one thing it is easier to reason about them in isolation It’s easier to replace them – since coupling is explicit
HOW SMALL SHOULD A MICROSERVICE BE?
BUT I’VE HEARD THAT A “MICROSERVICE SHOULD BE NO LARGER THAN 100 LINES OF CODE!?”
SIZE THIS AND SIZE THAT! BE CAREFUL If Microservices are good, then Nanoservices must be even better? Why not one-liner services?
AKA SERVERLESS 23 https://www.linkedin.com/pulse/how-i-decided-use-serverlessnanoservices-architecture-benefield
AKA SERVERLESS 24 https://www.linkedin.com/pulse/how-i-decided-use-serverlessnanoservices-architecture-benefield
Nano Services Unless we have a very good reason for doing so, we risk building services that are so fine-grained that their costs outweigh their utility* *Read Arnon Rotem-Gal-Oz’s Nano Services Anti Pattern:http://arnon.me/wp-content/uploads/2010/10/Nanoservices.pdf
IS YOUR MICROSERVICE VALUABLE? The value of a microservice must exceed the cost of building & operating it. Microservices entail costs for serializations, deserializations, security, communication, maintenance, configuration, deployment, monitoring, etc.
Let’s transform our monolith to microservices “The” DB UI Logic Microservices Data Access Microservices UI-3 MS-3 MS-C UI-2 MS-D UI-4 MS-4MS-2 MS-B MS-E UI-1 UI-5 MS-5MS-1 MS-A
BEWARE… 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
Let’s zoom in on the data tier MS-A “The” DB MS-C MS-D MS-B MS-E
IF OUR MONOLITHS CODE IS COUPLED AND MESSY Chances are that the data(base) model is equally coupled and messy
We start with a simple model
And as time goes by…
It gets more and more complicated
And finally we drown
AND WE END UP WITH ONE DOMAIN MODEL TO RULE THEM ALL
THE MENTAL CAPACITY REQUIRED TO UNDERSTAND THIS DOMAIN MODEL IS HUGE
TO UNDERSTAND ANY PART IN ISOLATION, REQUIRES YOU TO UNDERSTAND THE ENTIRE MODEL - AS EVERYTHING IS COUPLED TO EACH OTHER
Side effect: Our queries get messy
SOA PRINCIPLE SERVICES ARE AUTONOMOUS Autonomy means that our service is independent and self- contained and as far as possible doesn’t directly depend on other services to be functional.
Service autonomy Component B Component C Component A System X Service A Component B Component C System X Slow/unreliable network Different SLA Slow system
SERVICES ARE AUTONOMOUS For a service to be autonomous is MUST own its data Shipping DB
SERVICES ARE AUTONOMOUS For a service to be autonomous is must NOT share state
SERVICES ARE AUTONOMOUS Autonomy is essential for Scalability (scale out clustering) Reliability (fail over clustering)
SERVICES ARE AUTONOMOUS Autonomy is essential for Reusability Adaptability
Let’s refactor the data tier MS-C MS-D MS-B MS-E MS-A A’s DB B’s DB C’s DB D’s DB E’s DB UI Logic Microservices Data Access Microservices UI-3 MS-3 MS-C UI-2 MS-D UI-4 MS-4MS-2 MS-B MS-E UI-1 UI-5 MS-5MS-1 MS-A A’s DB B’s DB C’s DB D’s DB E’s DB
THIS IS ALSO KNOWN AS A DISTRIBUTED MONOLITH
Things that are not Services • A Service with only functionality (and no data) is a FUNCTION • Like: check if order is valid • A Service that only has data is a DATABASE • Like: Entity CRUD • A database already has a nice API - we don’t need to bubble wrap it with REST or Asynchronous messages • Don’t split the atom – we need cohesion as well as decoupling! • If we want datastore abstraction (so we can swap out Postgresql with Mongo or Redis) there this little pattern called Respository. This is typically seen in a lot of layered SOA usages where a function calls a function that calls a function that calls a database
Let’s refactor the “microservices” UI Microservices UI-3 MS-3 UI-2 UI-4 MS-4MS-2 UI-1 UI-5 MS-5MS-1 1’s DB 2’s DB 3’s DB 4’s DB 5’s DB
SRP What about cross Service relationships? Customer Orders Products
Microservices == distributed objects? Service star chart
Reality rears it’s ugly head
WHAT’S WRONG WITH USING RPC/REST/… BETWEEN SERVICES?
Synchronous calls lower 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 style Service interaction we can loose business data, there’s no automatic retry or we risk creating data more than once because idempotence* often is an after though 53 Client Server Duplicated Response Duplicated Request Processing Response Request 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
Also remember: REST isn’t magic!
WITH CROSS SERVICE INTEGRATION WE’RE BOUND BY THE LAWS OF DISTRIBUTED COMPUTING
The 8 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. See http://www.rgoarchitects.com/Files/fallacies.pdf for a walkthrough of the fallacies and why they’re fallacies
A DISTRIBUTED SYSTEM IS ONE WHERE A MACHINE I’VE NEVER HEARD OF CAN CAUSE MY PROGRAM TO FAIL. — Leslie Lamport
Essential complexity of 2 way integration Component C Component B Component A UI Service Service B:Service() call C:Service() call A:Service() commit() Service Local transaction between System A, B and C
B:Service() call C:Service() call A:Service() if (A:Call-Failed:Too-Busy?) Wait-A-While() call A:Service() if (A:Call-Failed:Too-Busy?) Wait-A-Little-While-Longer() call A:Service() if (A:Call-Failed:IO-Error?) Save-We-Need-Check-If-Call-A-Succeded-After-All AND We-Need-To-Retry call C:Service and call B:Service AND Tell-Customer-That-This-Operation-Perhaps-Went-Well if (A:Call-Went-Well?) commit() Accidental complexity from distributed service integration Component C Component B System A UI Service Service Service Local transaction between System B and C
Consequence: Availability goes down (without additional instances of each service) Service A Service B Service C Availability: 99% Availability: 99% Availability: 99% Combined availability: 97%
DECIDE IF YOU CAN LIVE WITH THE CONSEQUENCES OF COUPLING SERVICES TO EACH OTHER USING REQUEST/RESPONSE Different situations – different tradeoffs
HOW CAN WE BUILD SERVICES THAT DON’T EXPERIENCE THESE PROBLEMS?
GUIDANCE CAN BE FOUND IN Pat Hellands “Life Beyond Distributed Transactions? An Apostate ‘s Opinion” Link: http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf
Life Beyond Distributed Transactions? According to Pat Helland, we must find the solution to our problem by looking at: 1. How do we split our data / services 2. How do we identify our data 3. How do we communicate between our services
1. How do we split our data / services Data must be collected in pieces called aggregates. These aggregates should be limited in size (but not smaller), so that, after a transaction they are consistent. Rule of thumb: One transaction involves only one aggregate.
DOMAIN DRIVEN DESIGN The term Aggregate comes from DDD
Aggregates Invoice InvoiceLine * Account * What: • Cluster coherent Entities and Value Objects, with complex associations into Aggregates with well defined boundaries. • Choose one entity to be root and control access to objects inside the boundary through the root. Motivation: Control invariants and consistency through the aggregate root. Enables: Loading schemes, coarse grained locking and… Ensuring consistency & transactional boundaries for Distributed scenarios Root * *
THE SMALLEST SERVICE Would be responsible for all logic and data related to a single Aggregate
WHY? Because consistency can only be guaranteed within an Aggregate It cannot span aggregates - due to lack of coordinating transactions
Example of bad aggregate boundaries
RULE OF THUMB 1 use case = 1 transaction = 1 aggregate
2. How do we identify our data According to Pat Helland we need to be able to uniquely identify each Aggregate using an ID. • This ID will usually a UUID/GUID • Aggregates refer to each other by their ID • they NEVER use memory pointers, join tables or remote calls {21EC2020-3AEA-4069-A2DD-08002B30309D} 2122 (approximately 5.3×1036) combinations
WE STILL HAVEN’T CONQUERED THE TEMPORAL COUPLING PROBLEM
3. How we communicate between our services • What do we do when our use case involves more than one aggregate and therefore likely more than one service?
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
IF WE WANT TO DECOUPLE OUR SERVICES AS MUCH AS POSSIBLE THEN WE NEED TO LOOK TOWARDS COMPOSITE UI’S AND EVENTS
WHAT’S A COMPOSITE UI A Composite UI is a way to allow different services to participate an applications UI without revealing their internals and thereby removing the need for other services to know the this services internal data This helps us keep coupling low and encapsulation high
Applications and Services iOS Homebanking Call center support portal Bank Backoffice application Customer information service Legal and contract information service Accounts service Credit card service Mortgage loans service
Who owns the UI? • For a service to be fully autonomous is must be self contained – which means it must: • Own its UI • Own its Business Logic • Own its Data model User interface Business Logic Data model & storage Service A similar approach is available under the name Self Contained Systems http://scs-architecture.org/
If a Service doesn’t own its UI we often find the need for a Gateway or Backend For a Frontend (BFF) • Experience shows if you get your Service API wrong the first time around, it is really expensive to fix it* • The granularity of APIs provided by microservices is often different than what a client needs* * See http://thenewstack.io/microservices-calls-robust-api-management-tools/
Gateway or Backend For a Frontend (BFF) • Unfortunately Gateways & BFF’s introduce a lot of coupling between the Gateway and the underlying services • If an underlying service changes its contract in a non-backwards compatible way the gateway needs to change • In these cases the clients of the gateway may also need to change since the changes can permeate upwards (the gateway abstraction is leaky) * See http://thenewstack.io/microservices-calls-robust-api-management-tools/
Gateway/BFFGateway/BFF GATEWAY OR BACKEND FOR A FRONTEND UI Microservices UI-3 MS-3 UI-2 UI-4 MS-4MS-2 UI-1 UI-5 MS-5MS-1 1’s DB 2’s DB 3’s DB 4’s DB 5’s DB Gateway/BFF
Application UI’s • An applications is a composition of different services • The composition can be: • Resource Oriented Client Architecture (ROCA) style service integration (http://roca-style.org/) • Mashup of Service UI components in a dedicated Application – aka. Composite UI Both solutions involve integration via Services web interfaces to minimize coupling to other services. Image from http://scs-architecture.org/
Composite UI - example Page Context: { type: Book, id: ISBN-10 0-321-83457-7 } ImageService BookService ReviewService PriceService InventoryService OthersAlsoBoughtService PriceService ReviewService BookService ImageService BookService
Widget Widget Page Widget Service A Service B Service C Widget Widget Widget Service A Service B Service C Widget Service C • Overall structure of the page is “owned” by the application. • Each widget is owned and delivered by the underlying Service. Page layout
A SERVICE OWNS ITS UI IN ALL CONTEXTS AND FOR ALL COMPOSITE UI’S Not just for HTML clients
Invoice Composite UI example InvoiceHeader Order:ShippingI nfo Invoice: InvoiceNumber Invoice: Data and Due date Order: RelationInformation Order:Item- Qty Product:Ite m Product: Description Order: Item-Unit-Price Order: Item- Total- Price Order:Total Billing:Balance All Services participate at the UI level for each individual Item in the Order
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 Event oriented Command oriented Emergency services Distributed 3 layer
TO BREAK TEMPORAL COUPLING & BEHAVIORAL COUPLING SERVICES NEEDS TO COMMUNICATE ASYNCHRONOUSLY USING BUSINESS EVENTS Services communicate facts without making assumptions about what other services intend to do with the events
Let’s make the implicit explicit! Old wisdom seems to have been forgotten. Let’s introduce: Business/Domain Events Which: • Signal that something has happened • Closely aligned to the Domain Model • Are handled by a messaging system • They are in the past tense: • CustomerBilled • ParcelShipped • CustomerCreated • ReviewCreated • CommentAdded • CommentDeleted
Events are often the side effect of Commands A Command message is prescriptive of what should happen. This is a stronger form of coupling than Events. A Command’s primary goal is to capture USER INTENT A Command supports a single usecase and targets a single Aggregate Commands always carry a name in its imperative form: CreateOrder, ShipOrder, CancelOrder, ReimburseCustomer, etc. “A command describes a Task that you want someone else to carry out for you and the recipient can reject the Command”
Commands & Events Commands mutate Aggregate state – and if succesful – will result in one or more Events being published Command Event(s) AcceptOrder OrderAccepted ShipOrder OrderShipped AddComment CommentAdded QuarantineReview ReviewQuarantined UnquarantineReview ReviewUnquarantined
WE NEED TO CHANGE FOCUS FROM SHORT TECHNICAL TRANSACTIONS To long running business transactions supporting business processes
Using Business Events to drive Business Processes Sales Service Shipping Billing Sales Customers MessageChannel Online Ordering System Web Shop (Composite UI) Billing Service Shipping Service Order Accepted Event AcceptOrder Command The sales fulfillment processing can now begin…
Choreographed Event Driven Processes Sales Service Order Accepted Invoicing Service Order Fulfilment (Saga/ Process-Manager) Shipping Service Online Ordering System MessageChannel(e.g.aTopic) Order Accepted Order Accepted Customer Billed Customer Billed Order Approved Order Approved Works as a Finite State Machine (WorkFlow) handling the life cycle of Shipping and thereby forms a very central new Aggregate in the System
Choreography is very different from the classical orchestrated integration process
The INPAY approach to Microservices
SERVICES AT INPAY
Different perspectives on data With in a given Domain, e.g. Retail, there will exist multiple bounded contexts/sub-domains/business capabilities such as: • Product management • Purchase • Sales • Pricing • Inventory • Shipping • Support • Accounting • Management Each of these lines of business have very specific and unique needs which are relevant for them alone in order to conduct their business. They might use the same name for the entities they’re interested in or they might use different names for the same logical entity.
Many perspectives on data Online Retail System Product Unit Price Promotional Price Promotion End Date Stock Keeping Unit (SKU) Quantity On Hand (QOH) Location Code Price Quantity Ordered Name The lifecycle of the data is VERY important! Customer Pricing Inventory Sales Management Reporting
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 identitySOA: Service
Billing Product Catalogue Shipping Sales Inventory Pricing Retail domain split into a Macro architecture Usually contains more than one aggregate 
What’s a macro architecture • It’s the static/stable(r) parts of your architecture • Which are very costly to refactor and change • Business capabilities are stable • Therefore we should strive to align services with business capabilities / bounded contexts (DDD)
Service and 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
A Service is • The technical authority for a given business capability • It is the owner of all the data and business rules that support this business capability – everywhere (including the UI) • It forms a single source of truth for that capability • This form of business and IT alignment ensures that we can maintain service Autonomy & Encapsulation
Services/Business-capabilities in INPAY Currency Service Finance Service Banking Service Identity Management Service Sales Service PSP Service 3rd party Providers Service Virtual Banking Service IT Operations
Applications in INPAY Identity Management Application Contract Manager Application Treasury Application Compliance Application Operations Application CRM PSP Gateway PSP Merchant Application ERP
Services, Applications and code • Each Service and Application is maintained in separate Git repositories • Common IT Operations libraries and infrastructure are maintained in other separate Git repositories
So what’s inside a Service source repository? • Autonomous Components • Libraries • Adapters • Front-end UI components • API contracts (mainly Events) • DB Schemas • Build file(s)
Autonomous Components?
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
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) • Multiple services can cooperate to fulfill a larger use-case (e.g. a workflow or a business process)
Service Autonomous Component 1..* Is implemented by A Service is the technical authority of a specific Business Capability e.g. Sales, Shipping, Billing Services support business processes. Business processes naturally span multiple services, but there will always be a single service that is the actual authority on the business process. Service vs Autonomous Components
Also known as Microservices Service Autonomous Component 1..* Is implemented by Service vs Autonomous Components Autonomous-Components/Microservices are a division of Services along Transactional boundaries (a transaction stays within the boundary of a Microservice) Microservices are the individually logical 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 Microservice
Services are the corner stone • We talk in terms of Services/business capabilities and the processes/use- cases they support • Autonomous-Components/Microservices are an implementation detail • They are much less stable (which is a good thing – it means they’re easier to replace) • With regards to other Services • subscribe to events from • send commands to (less common) • call operations (in rare occasions)
Services/Bounded Contexts and Aggregates Sales Service PSP ServiceVirtual Banking Service Finance Service Customer customerId … Contract contractId customerId … VBFeeSchedule contractId … PSPFeeSchedule contractId … BillingTemplate contractId …
INPAY Autonomous Component design principles
Commands and Events Events Identifiers Commands
Commands and Events public class RegisterBankCmd extends AbstractCommand { @TargetAggregateIdentifier public final BankId bankId; public final String name; public final Country countryOfOperation; public RegisterBankCmd(BankId bankId, String name, Country countryOfOperation) { Objects.requireNonNull(bankId, "bankId"); Objects.requireNonNull(name, "name"); Objects.requireNonNull(countryOfOperation, "countryOfOperation"); this.bankId = bankId; this.name = name; this.countryOfOperation = countryOfOperation; } }
Commands and Events The generic business event interface includes the name of the topic that subscribers must use public class BankRegistered extends AbstractEvent implements BankEvent { @AggregateIdentifier public final BankId bankId; public final String name; public final Country countryOfOperation; public BankCreated(BankId bankId, String name, Country countryOfOperation) { this.bankId = bankId; this.name = name; this.countryOfOperation = countryOfOperation; } } public interface BankEvent extends Serializable { TopicName TOPIC_NAME = BankingServiceId.ID.topicName("bank-events"); }
CQRS A single model cannot be appropriate for reporting, searching and transactional behavior Greg Young, 2008
Commands, Events and Query Models Read model Read model Events UI Domain modelQuery/Read model ”AcceptOrder” command ”OrderAccepted” event ”Find all Accepted Orders” Query Commands are Imperative: DoStuff Events are Past tense: StuffDone
Event Sourcing Aggregates track their own Domain Events and derive state from them Time 07:39 Time 07:40 Time 07:41 Time 07:45 Time 07:46 Time 07:50
Full CQRS With EventSourcing UI Domain Event Store (can e.g. be a real EventStore DB or a Relational DB) Commands – Change data Commands Events SQL DB Document DB Graph DB UI Data Queries – Ask for data Events Query Build Our single source of truth
Aggregate public class Bank extends InPayEventSourcedAggregate { @AggregateIdentifier private BankId bankId; @EventSourcedMember private Map<BankAccountId, BankAccount> bankAccounts = new HashMap<>(); public Bank(BankId bankId, String name, Country countryOfOperation) { apply(new BankRegistered(bankId, name, countryOfOperation)); } public void addBankAccount(BankAccountId bankAccountId, …) { if (!bankAccounts.containsKey(bankAccountId)) { apply(new BankAccountAdded(bankId, bankAccountId, …)); } } @EventSourcingHandler private void on(BankRegistered e) { bankId = e.getBankId(); } @EventSourcingHandler private void on(BankAccountAdded e) { BankAccount bankAccount = bankAccounts.put(e.getBankAccountId(), new BankAccount(e.getBankId(), e.getBankAccountId(), …)); } }
Service project structure sales_service sales_api sales_contract_ac sales_customer_ac frontend sales_contract_manager_adapters contract adapters sales/modules customer psp_service psp_api psp_fees_ac … frontend psp_contract_manager_adapters fees adapters psp/modules fx Legend: Service/Business-Capability External Event/Command Contracts Autonomous Component Autonomous Component Adapter Angular.js Module Builds into a Java JAR Uses Spring MVC/REST All Java 8 artifacts are built using Gradle
Autonomous Component Library • Can be deployed alone or co-located • Usually deployed together with one or more adapters • Works transparently in a clustered environment • Completely Spring free  • Only depends on our Core infrastructure library • Common types and Id’s • Bus infrastructure • Service lookup • CQRS building blocks (backed by Axon framework)
Client handled subscriptions • Highly resilient pattern for an Event Driven Architecture that’s backed by AC’s that use EventSourcing. • In this model the publisher of the Events is responsible for the durability of all its Events, typically to an EventStore/EventLog. • Each client (subscriber) maintains durable information of the last event it received from each publisher. • When ever the client starts up it makes a subscription to the publisher where it states from which point in time it wants events published. • This effectively means that publisher can remain simple and the client (subscriber) can remain simple and we don’t need additional sophisticated broker infrastructure such as Kafka+ZooKeeper.
Infrastructure 129
Client handled subscriptions Publisher Subscriber A Local storage EventStore Subscriber B Local storage Topic Subscription Topic Subscription TopicSubscriptionHandler TopicSubscriptionHandler EventEvent Event Event EventBus Event Event
psp_fees_ac (deployed on 10.25.26.102) psp_fees_ac (deployed on 10.25.26.101) Bus Bus Bus Bus sales_contract_ac (deployed on 10.25.26.104) sales_contract_ac (deployed on 10.25.26.103) Federated Bus
Distributed Bus Topic Queue Topic Publisher side Topic Subscriber side Queue Sender side Queue Receiver side Local Topic Publisher Local Topic Subscriber Local Queue Sender Local Queue Receiver Distributed per Service EventBus Local Topic Subscriber Local Topic Subscriber Local Queue Sender Distributed Notifications Distributed Broadcast Distributed SingleInstance Task
Applications
AUTONOMOUS-COMPONENTS/ MICROSERVICES ARE LOGICAL DEPLOYABLE UNITS That doesn’t mean they HAVE to be deployed individually. Design for Distribution But take advantage of locality
Logical Architecture Building Blocks
Autonomous Components can be co-deployed together with Application backends contract_manager (Spring Boot fat–jar) sales_contract_ac sales_customer_ac sales_contract_manager_adapters psp_api psp_fees_ac psp_contract_manager_adapters frontend sales_api app libs contract customer fees
Application in code @Configuration @ComponentScan(basePackages = { "com.inpay.contractmanager", "com.inpay.adapters", "com.inpay.itops.spring" }) public class Application extends InpaySpringBootApplication { public Application() { super(); } @Override protected String getApplicationName() { return "ContractManager"; } @Override protected Collection<AutonomousComponent> getAutonomousComponentsHostedInThisApplication() { CurrencyExchangeRateAc currencyExchangeRateAc = new CurrencyExchangeRateAc(); return list( new IDMCoreAc(), new PSPFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()), new VBFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()), new ContractAc(), new CustomersAc(), currencyExchangeRateAc ); } public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
AC in code public class PSPAgreementAc extends HzBackedAutonomousComponent { public static AutonomousComponentId SERVICE_AC_ID = PSP_SERVICE_ID.ac("psp_agreement_ac"); … public PSPAgreementAc(CurrencyConverter currencyConverter) { this.currencyConverter = currencyConverter; } @Override public void onInitialize(IConfigureACEnvironment acSetup) { acSetup.withAutonomousComponentId(SERVICE_AC_ID).usingServiceDataSource() .withBusConfiguration(cfg -> { cfg.getAxonContext() .subscribeAnnotatedCommandHandler(new TemplateCmdHandler( cfg.getAxonContext().eventSourcedRepository(PSPTemplate.class), currencyConverter)); …. manageLifecycleFor(templateViewRepository = new TemplateViewRepository(cfg, currencyConverter)); }) .runOnBusStartup((bus, axonContext) -> { bus.registerAxonReplayableTopicPublisher(InternalTemplateEvents.TOPIC_NAME, replayFromAggregate(PSPTemplate.class) .dispatchAggregateEventsOfType(InternalTemplateEvents.class)); bus.subscribeTopic(SERVICE_AC_ID.topicSubscriber("ContractEvents"), ExternalContractEvents.TOPIC_NAME, new SalesTopicSubscription(bus)); }); } public TemplateViewRepository getTemplateViewRepository() { return templateViewRepository; } }
AC, autonomy and “shared” service data Service DB DB Autonomous Component Autonomous Component Autonomous Component Autonomous Component DB
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!
Thanks :)

More Related Content

PPTX
Autonomous microservices for a Financial System
byINPAY
 
PPTX
The "Why", "What" and "How" of Microservices
byINPAY
 
PPTX
Are microservices 'soa done right'?
byJason Bloomberg
 
PPTX
SOA vs EDA 2 (discussions with Jeppe)
byJean-Jacques Dubray
 
PPTX
SOA vs EDA
byJean-Jacques Dubray
 
KEY
Event Driven Architecture at NDDNUG
byChris Patterson
 
PPTX
Events & Microservices
byYamen Sader
 
PDF
Watch your communication
byUwe Friedrichsen
 
Autonomous microservices for a Financial System
byINPAY
 
The "Why", "What" and "How" of Microservices
byINPAY
 
Are microservices 'soa done right'?
byJason Bloomberg
 
SOA vs EDA 2 (discussions with Jeppe)
byJean-Jacques Dubray
 
SOA vs EDA
byJean-Jacques Dubray
 
Event Driven Architecture at NDDNUG
byChris Patterson
 
Events & Microservices
byYamen Sader
 
Watch your communication
byUwe Friedrichsen
 

What's hot

PDF
Timeless design in a cloud-native world
byUwe Friedrichsen
 
KEY
Event Driven Architecture
byChris Patterson
 
PDF
Event-Driven Service-oriented Architecture (EDSOA)
byAttune Infocom Pvt Ltd
 
PDF
High Octane Productivity
byRaman Kannan
 
PDF
Microservice design patterns
byHugh McKee
 
PDF
JUG Frankfurt - Orchestration of microservices
byBernd Ruecker
 
PDF
Strategies for migration to public cloud
bySiddharth Ram
 
PDF
Graphel: A Purely Functional Approach to Digital Interaction
bymtrimpe
 
PDF
DDD Belgium Meetup 2017: Events, flows and long running services
byBernd Ruecker
 
PDF
November 2017: Collaboration of (micro-)services
byBernd Ruecker
 
PPTX
Event sourcing
byTouraj Ebrahimi
 
PPT
The Architect's Two Hats
byBen Stopford
 
PPTX
Event driven architecture in practice
bymimmozzo_
 
PDF
Saturn 2018: Managing data consistency in a microservice architecture using S...
byChris Richardson
 
PDF
CAP theorem and distributed systems
byKlika Tech, Inc
 
PDF
MuCon London 2017: Break your event chains
byBernd Ruecker
 
PPTX
Introduction to microservices
byPaulo Gandra de Sousa
 
PDF
Microservices for Mortals by Bert Ertman at Codemotion Dubai
byCodemotion Dubai
 
PDF
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old Services
byallingeek
 
Timeless design in a cloud-native world
byUwe Friedrichsen
 
Event Driven Architecture
byChris Patterson
 
Event-Driven Service-oriented Architecture (EDSOA)
byAttune Infocom Pvt Ltd
 
High Octane Productivity
byRaman Kannan
 
Microservice design patterns
byHugh McKee
 
JUG Frankfurt - Orchestration of microservices
byBernd Ruecker
 
Strategies for migration to public cloud
bySiddharth Ram
 
Graphel: A Purely Functional Approach to Digital Interaction
bymtrimpe
 
DDD Belgium Meetup 2017: Events, flows and long running services
byBernd Ruecker
 
November 2017: Collaboration of (micro-)services
byBernd Ruecker
 
Event sourcing
byTouraj Ebrahimi
 
The Architect's Two Hats
byBen Stopford
 
Event driven architecture in practice
bymimmozzo_
 
Saturn 2018: Managing data consistency in a microservice architecture using S...
byChris Richardson
 
CAP theorem and distributed systems
byKlika Tech, Inc
 
MuCon London 2017: Break your event chains
byBernd Ruecker
 
Introduction to microservices
byPaulo Gandra de Sousa
 
Microservices for Mortals by Bert Ertman at Codemotion Dubai
byCodemotion Dubai
 
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old Services
byallingeek
 

Similar to The "Why", "What" & "How" of Microservices - short version

PDF
Microservices for Mortals
byBert Ertman
 
PPTX
Let's talk about... Microservices
byAlessandro Giorgetti
 
PPTX
Microservices Architecture
byAlessandro Giorgetti
 
PDF
A tale of two microservices
byPablo Chacin
 
PPTX
Microservices
byRajesh Kumar
 
PDF
Building microservices on azure
byVaibhav Gujral
 
PDF
Microservices for Java Architects (Chicago, April 21, 2015)
byDerek Ashmore
 
PDF
The histories of microservices
bySteve Upton
 
PDF
Micro Service Architecture
byLinjith Kunnon
 
PDF
Microservices: an introduction
byDaniel Baptista Dias
 
PDF
Microservices for Java Architects (Madison-Milwaukee, April 28-9, 2015)
byDerek Ashmore
 
PDF
Microservices for architects los angeles-2016-07-16
byDerek Ashmore
 
PDF
Patterns & Practices of Microservices
byWesley Reisz
 
PDF
L11 Service Design and REST
byÓlafur Andri Ragnarsson
 
PDF
DSR Microservices (Day 1, Part 1)
bySteve Upton
 
PPTX
Microservices
byAnkireddy Polu
 
PDF
Microservices: Where do they fit within a rapidly evolving integration archit...
byKim Clark
 
PDF
Microservices for Architects - Atlanta 2018-03-28
byDerek Ashmore
 
PPTX
Microservice intro
byramesh_sharma
 
PDF
Microservice Architecture
bytyrantbrian
 
Microservices for Mortals
byBert Ertman
 
Let's talk about... Microservices
byAlessandro Giorgetti
 
Microservices Architecture
byAlessandro Giorgetti
 
A tale of two microservices
byPablo Chacin
 
Microservices
byRajesh Kumar
 
Building microservices on azure
byVaibhav Gujral
 
Microservices for Java Architects (Chicago, April 21, 2015)
byDerek Ashmore
 
The histories of microservices
bySteve Upton
 
Micro Service Architecture
byLinjith Kunnon
 
Microservices: an introduction
byDaniel Baptista Dias
 
Microservices for Java Architects (Madison-Milwaukee, April 28-9, 2015)
byDerek Ashmore
 
Microservices for architects los angeles-2016-07-16
byDerek Ashmore
 
Patterns & Practices of Microservices
byWesley Reisz
 
L11 Service Design and REST
byÓlafur Andri Ragnarsson
 
DSR Microservices (Day 1, Part 1)
bySteve Upton
 
Microservices
byAnkireddy Polu
 
Microservices: Where do they fit within a rapidly evolving integration archit...
byKim Clark
 
Microservices for Architects - Atlanta 2018-03-28
byDerek Ashmore
 
Microservice intro
byramesh_sharma
 
Microservice Architecture
bytyrantbrian
 

Recently uploaded

PDF
5 Common Supply Chain Attacks and How They Work | CyberPro Magazine
byCyberPro Magazine
 
PPTX
The power of Slack and MuleSoft | Bangalore MuleSoft Meetup #60
byshyamraj55
 
PDF
So You Want to Work at Google | DevFest Seattle 2025
byMargaret Maynard-Reid
 
PDF
ODSC AI West: Agent Optimization: Beyond Context engineering
byShashikant Jagtap
 
PDF
KMWorld - KM & AI Bring Collectivity, Nostalgia, & Selectivity
byJonathan Ralton
 
PDF
How Much Does It Cost To Build Software
bycollinmishell2
 
PDF
PCCC25（設立25年記念PCクラスタシンポジウム）：エヌビディア合同会社 テーマ２「NVIDIA BlueField-4 DPU」
byPC Cluster Consortium
 
PDF
Accessibility & Inclusion: What Comes Next. Presentation of the Digital Acces...
byAssociazione Digital Days
 
PPTX
Support, Monitoring, Continuous Improvement & Scaling Agentic Automation [3/3]
byUiPathCommunity
 
PDF
Mastering UiPath Maestro – Session 2 – Building a Live Use Case - Session 2
byDianaGray10
 
PDF
Cybersecurity Prevention and Detection: Unit 2
byVICTOR MAESTRE RAMIREZ
 
PDF
Top Crypto Supers 15th Report November 2025
byStephen Perrenod
 
PPTX
Guardrails in Action - Ensuring Safe AI with Azure AI Content Safety.pptx
byUdaiappa Ramachandran
 
PDF
[DevFest Strasbourg 2025] - NodeJs Can do that !!
bymoassiongbon
 
PDF
DUBAI IT MODERNIZATION WITH AZURE MANAGED SERVICES.pdf
byLogicEra
 
PDF
10 Best Automation QA Testing Software Tools in 2025.pdf
byRohitBhandari66
 
PDF
[BDD 2025 - Full-Stack Development] Digital Accessibility: Why Developers nee...
bywintari3
 
PDF
"DISC as GPS for team leaders: how to lead a team from storming to performing...
byFwdays
 
PDF
Cheryl Hung, Vibe Coding Auth Without Melting Down! isaqb Software Architectu...
byCheryl Hung
 
PDF
Transcript: The partnership effect: Libraries and publishers on collaborating...
byBookNet Canada
 
5 Common Supply Chain Attacks and How They Work | CyberPro Magazine
byCyberPro Magazine
 
The power of Slack and MuleSoft | Bangalore MuleSoft Meetup #60
byshyamraj55
 
So You Want to Work at Google | DevFest Seattle 2025
byMargaret Maynard-Reid
 
ODSC AI West: Agent Optimization: Beyond Context engineering
byShashikant Jagtap
 
KMWorld - KM & AI Bring Collectivity, Nostalgia, & Selectivity
byJonathan Ralton
 
How Much Does It Cost To Build Software
bycollinmishell2
 
PCCC25（設立25年記念PCクラスタシンポジウム）：エヌビディア合同会社 テーマ２「NVIDIA BlueField-4 DPU」
byPC Cluster Consortium
 
Accessibility & Inclusion: What Comes Next. Presentation of the Digital Acces...
byAssociazione Digital Days
 
Support, Monitoring, Continuous Improvement & Scaling Agentic Automation [3/3]
byUiPathCommunity
 
Mastering UiPath Maestro – Session 2 – Building a Live Use Case - Session 2
byDianaGray10
 
Cybersecurity Prevention and Detection: Unit 2
byVICTOR MAESTRE RAMIREZ
 
Top Crypto Supers 15th Report November 2025
byStephen Perrenod
 
Guardrails in Action - Ensuring Safe AI with Azure AI Content Safety.pptx
byUdaiappa Ramachandran
 
[DevFest Strasbourg 2025] - NodeJs Can do that !!
bymoassiongbon
 
DUBAI IT MODERNIZATION WITH AZURE MANAGED SERVICES.pdf
byLogicEra
 
10 Best Automation QA Testing Software Tools in 2025.pdf
byRohitBhandari66
 
[BDD 2025 - Full-Stack Development] Digital Accessibility: Why Developers nee...
bywintari3
 
"DISC as GPS for team leaders: how to lead a team from storming to performing...
byFwdays
 
Cheryl Hung, Vibe Coding Auth Without Melting Down! isaqb Software Architectu...
byCheryl Hung
 
Transcript: The partnership effect: Libraries and publishers on collaborating...
byBookNet Canada
 

The "Why", "What" & "How" of Microservices - short version

  • 1.
    The “Why”, “What”and of Microservices Jeppe Cramon - @jeppec Chief Architect - INPAY “How”
  • 2.
    WHY WOULD WEWANT TO USE MICROSERVICES?
  • 3.
    Most feel stuckwith a monolith and are look for a way out “The” DB UI Logic Data Access
  • 4.
    Microservices promise asolution to our problem Monolith Microservice Microservice Microservice MicroserviceMicroservice Microservice Microservice
  • 5.
    Microservices as anarchitectural style 5
  • 6.
    ARCHITECTURE IS ESSENTIAL Becauseit influences how fast we can respond to changes and what the cost of those changes are
  • 7.
    ULTIMATELY WE WANTTO BE ABLE TO ADAPT TO CHANGES IN A CONSTANT AMOUNT OF TIME
  • 8.
    E.G. IF YOURPRICING MODEL WAS WRONG – YOU SHOULD BE ABLE TO CHANGE AND REDEPLOY IT IN HOURS/DAYS
  • 9.
    SOME ORGANIZATIONS CALCULATE CHANGETIMES IN MONTHS OR YEARS
  • 10.
    WE ALL WANTTO MOVE FAST But can’t always move fast - for various reasons…
  • 11.
    THE MAIN MAINIMPEDIMENT TO OBTAINING HIGH VELOCITY IS
  • 12.
  • 13.
    Coupling causes rippleeffect – much like circles in the water • You want to change a little thing and all of a sudden you need to change 25 other seemingly unrelated things • Zero coupling is impossible • Question is what is the right level of coupling? • This highly depends on how likely the component/system/service is to change and what parts that change together
  • 14.
    The playing field Zerocoupling The monolith (an indivisible unit)
  • 15.
    It usually startssimple “The” DB UI Logic Data Access
  • 16.
    Next step isspaghetti in layers
  • 17.
    And finally weend up with a Big Ball Of Mud
  • 18.
    MICROSERVICES TELL USTO MAKE THINGS SMALLER Adhering to the Single Responsibility Principle (SRP) – “A Microservice should have one reason – and only one reason – to change”
  • 19.
    THERE IS VALUEIN MAKING THINGS SMALLER For one thing it is easier to reason about them in isolation It’s easier to replace them – since coupling is explicit
  • 20.
    HOW SMALL SHOULDA MICROSERVICE BE?
  • 21.
    BUT I’VE HEARDTHAT A “MICROSERVICE SHOULD BE NO LARGER THAN 100 LINES OF CODE!?”
  • 22.
    SIZE THIS ANDSIZE THAT! BE CAREFUL If Microservices are good, then Nanoservices must be even better? Why not one-liner services?
  • 23.
  • 24.
  • 25.
    Nano Services Unless wehave a very good reason for doing so, we risk building services that are so fine-grained that their costs outweigh their utility* *Read Arnon Rotem-Gal-Oz’s Nano Services Anti Pattern:http://arnon.me/wp-content/uploads/2010/10/Nanoservices.pdf
  • 26.
    IS YOUR MICROSERVICE VALUABLE? Thevalue of a microservice must exceed the cost of building & operating it. Microservices entail costs for serializations, deserializations, security, communication, maintenance, configuration, deployment, monitoring, etc.
  • 27.
    Let’s transform ourmonolith to microservices “The” DB UI Logic Microservices Data Access Microservices UI-3 MS-3 MS-C UI-2 MS-D UI-4 MS-4MS-2 MS-B MS-E UI-1 UI-5 MS-5MS-1 MS-A
  • 28.
    BEWARE… When we breakup big things into small pieces we invariably push the complexity to their interaction. Michael Feathers https://michaelfeathers.silvrback.com/microservices-until-macro-complexity
  • 29.
    Let’s zoom inon the data tier MS-A “The” DB MS-C MS-D MS-B MS-E
  • 30.
    IF OUR MONOLITHSCODE IS COUPLED AND MESSY Chances are that the data(base) model is equally coupled and messy
  • 31.
    We start witha simple model
  • 32.
    And as timegoes by…
  • 33.
    It gets moreand more complicated
  • 34.
  • 35.
    AND WE ENDUP WITH ONE DOMAIN MODEL TO RULE THEM ALL
  • 36.
    THE MENTAL CAPACITYREQUIRED TO UNDERSTAND THIS DOMAIN MODEL IS HUGE
  • 37.
    TO UNDERSTAND ANYPART IN ISOLATION, REQUIRES YOU TO UNDERSTAND THE ENTIRE MODEL - AS EVERYTHING IS COUPLED TO EACH OTHER
  • 38.
    Side effect: Ourqueries get messy
  • 39.
    SOA PRINCIPLE SERVICES AREAUTONOMOUS Autonomy means that our service is independent and self- contained and as far as possible doesn’t directly depend on other services to be functional.
  • 40.
  • 41.
    SERVICES ARE AUTONOMOUS Fora service to be autonomous is MUST own its data Shipping DB
  • 42.
    SERVICES ARE AUTONOMOUS Fora service to be autonomous is must NOT share state
  • 43.
    SERVICES ARE AUTONOMOUS Autonomyis essential for Scalability (scale out clustering) Reliability (fail over clustering)
  • 44.
    SERVICES ARE AUTONOMOUS Autonomyis essential for Reusability Adaptability
  • 45.
    Let’s refactor thedata tier MS-C MS-D MS-B MS-E MS-A A’s DB B’s DB C’s DB D’s DB E’s DB UI Logic Microservices Data Access Microservices UI-3 MS-3 MS-C UI-2 MS-D UI-4 MS-4MS-2 MS-B MS-E UI-1 UI-5 MS-5MS-1 MS-A A’s DB B’s DB C’s DB D’s DB E’s DB
  • 46.
    THIS IS ALSOKNOWN AS A DISTRIBUTED MONOLITH
  • 47.
    Things that arenot Services • A Service with only functionality (and no data) is a FUNCTION • Like: check if order is valid • A Service that only has data is a DATABASE • Like: Entity CRUD • A database already has a nice API - we don’t need to bubble wrap it with REST or Asynchronous messages • Don’t split the atom – we need cohesion as well as decoupling! • If we want datastore abstraction (so we can swap out Postgresql with Mongo or Redis) there this little pattern called Respository. This is typically seen in a lot of layered SOA usages where a function calls a function that calls a function that calls a database
  • 48.
    Let’s refactor the“microservices” UI Microservices UI-3 MS-3 UI-2 UI-4 MS-4MS-2 UI-1 UI-5 MS-5MS-1 1’s DB 2’s DB 3’s DB 4’s DB 5’s DB
  • 49.
    SRP What about crossService relationships? Customer Orders Products
  • 50.
    Microservices == distributedobjects? Service star chart
  • 51.
  • 52.
    WHAT’S WRONG WITHUSING RPC/REST/… BETWEEN SERVICES?
  • 53.
    Synchronous calls lowerour 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 style Service interaction we can loose business data, there’s no automatic retry or we risk creating data more than once because idempotence* often is an after though 53 Client Server Duplicated Response Duplicated Request Processing Response Request 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
  • 54.
    Also remember: RESTisn’t magic!
  • 55.
    WITH CROSS SERVICEINTEGRATION WE’RE BOUND BY THE LAWS OF DISTRIBUTED COMPUTING
  • 56.
    The 8 Fallaciesof 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. See http://www.rgoarchitects.com/Files/fallacies.pdf for a walkthrough of the fallacies and why they’re fallacies
  • 57.
    A DISTRIBUTED SYSTEMIS ONE WHERE A MACHINE I’VE NEVER HEARD OF CAN CAUSE MY PROGRAM TO FAIL. — Leslie Lamport
  • 58.
    Essential complexity of2 way integration Component C Component B Component A UI Service Service B:Service() call C:Service() call A:Service() commit() Service Local transaction between System A, B and C
  • 59.
    B:Service() call C:Service() call A:Service() if(A:Call-Failed:Too-Busy?) Wait-A-While() call A:Service() if (A:Call-Failed:Too-Busy?) Wait-A-Little-While-Longer() call A:Service() if (A:Call-Failed:IO-Error?) Save-We-Need-Check-If-Call-A-Succeded-After-All AND We-Need-To-Retry call C:Service and call B:Service AND Tell-Customer-That-This-Operation-Perhaps-Went-Well if (A:Call-Went-Well?) commit() Accidental complexity from distributed service integration Component C Component B System A UI Service Service Service Local transaction between System B and C
  • 60.
    Consequence: Availability goesdown (without additional instances of each service) Service A Service B Service C Availability: 99% Availability: 99% Availability: 99% Combined availability: 97%
  • 61.
    DECIDE IF YOUCAN LIVE WITH THE CONSEQUENCES OF COUPLING SERVICES TO EACH OTHER USING REQUEST/RESPONSE Different situations – different tradeoffs
  • 62.
    HOW CAN WEBUILD SERVICES THAT DON’T EXPERIENCE THESE PROBLEMS?
  • 63.
    GUIDANCE CAN BEFOUND IN Pat Hellands “Life Beyond Distributed Transactions? An Apostate ‘s Opinion” Link: http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf
  • 64.
    Life Beyond DistributedTransactions? According to Pat Helland, we must find the solution to our problem by looking at: 1. How do we split our data / services 2. How do we identify our data 3. How do we communicate between our services
  • 65.
    1. How dowe split our data / services Data must be collected in pieces called aggregates. These aggregates should be limited in size (but not smaller), so that, after a transaction they are consistent. Rule of thumb: One transaction involves only one aggregate.
  • 66.
    DOMAIN DRIVEN DESIGN Theterm Aggregate comes from DDD
  • 67.
    Aggregates Invoice InvoiceLine * Account * What: • Clustercoherent Entities and Value Objects, with complex associations into Aggregates with well defined boundaries. • Choose one entity to be root and control access to objects inside the boundary through the root. Motivation: Control invariants and consistency through the aggregate root. Enables: Loading schemes, coarse grained locking and… Ensuring consistency & transactional boundaries for Distributed scenarios Root * *
  • 68.
    THE SMALLEST SERVICE Wouldbe responsible for all logic and data related to a single Aggregate
  • 69.
    WHY? Because consistency canonly be guaranteed within an Aggregate It cannot span aggregates - due to lack of coordinating transactions
  • 70.
    Example of badaggregate boundaries
  • 71.
    RULE OF THUMB 1use case = 1 transaction = 1 aggregate
  • 72.
    2. How dowe identify our data According to Pat Helland we need to be able to uniquely identify each Aggregate using an ID. • This ID will usually a UUID/GUID • Aggregates refer to each other by their ID • they NEVER use memory pointers, join tables or remote calls {21EC2020-3AEA-4069-A2DD-08002B30309D} 2122 (approximately 5.3×1036) combinations
  • 73.
    WE STILL HAVEN’TCONQUERED THE TEMPORAL COUPLING PROBLEM
  • 74.
    3. How wecommunicate between our services • What do we do when our use case involves more than one aggregate and therefore likely more than one service?
  • 75.
    Synchronous calls arethe 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
  • 76.
    IF WE WANTTO DECOUPLE OUR SERVICES AS MUCH AS POSSIBLE THEN WE NEED TO LOOK TOWARDS COMPOSITE UI’S AND EVENTS
  • 77.
    WHAT’S A COMPOSITEUI A Composite UI is a way to allow different services to participate an applications UI without revealing their internals and thereby removing the need for other services to know the this services internal data This helps us keep coupling low and encapsulation high
  • 78.
    Applications and Services iOSHomebanking Call center support portal Bank Backoffice application Customer information service Legal and contract information service Accounts service Credit card service Mortgage loans service
  • 79.
    Who owns theUI? • For a service to be fully autonomous is must be self contained – which means it must: • Own its UI • Own its Business Logic • Own its Data model User interface Business Logic Data model & storage Service A similar approach is available under the name Self Contained Systems http://scs-architecture.org/
  • 80.
    If a Servicedoesn’t own its UI we often find the need for a Gateway or Backend For a Frontend (BFF) • Experience shows if you get your Service API wrong the first time around, it is really expensive to fix it* • The granularity of APIs provided by microservices is often different than what a client needs* * See http://thenewstack.io/microservices-calls-robust-api-management-tools/
  • 81.
    Gateway or BackendFor a Frontend (BFF) • Unfortunately Gateways & BFF’s introduce a lot of coupling between the Gateway and the underlying services • If an underlying service changes its contract in a non-backwards compatible way the gateway needs to change • In these cases the clients of the gateway may also need to change since the changes can permeate upwards (the gateway abstraction is leaky) * See http://thenewstack.io/microservices-calls-robust-api-management-tools/
  • 82.
    Gateway/BFFGateway/BFF GATEWAY OR BACKEND FORA FRONTEND UI Microservices UI-3 MS-3 UI-2 UI-4 MS-4MS-2 UI-1 UI-5 MS-5MS-1 1’s DB 2’s DB 3’s DB 4’s DB 5’s DB Gateway/BFF
  • 83.
    Application UI’s • Anapplications is a composition of different services • The composition can be: • Resource Oriented Client Architecture (ROCA) style service integration (http://roca-style.org/) • Mashup of Service UI components in a dedicated Application – aka. Composite UI Both solutions involve integration via Services web interfaces to minimize coupling to other services. Image from http://scs-architecture.org/
  • 84.
    Composite UI -example Page Context: { type: Book, id: ISBN-10 0-321-83457-7 } ImageService BookService ReviewService PriceService InventoryService OthersAlsoBoughtService PriceService ReviewService BookService ImageService BookService
  • 85.
    Widget Widget Page Widget Service AService B Service C Widget Widget Widget Service A Service B Service C Widget Service C • Overall structure of the page is “owned” by the application. • Each widget is owned and delivered by the underlying Service. Page layout
  • 86.
    A SERVICE OWNSITS UI IN ALL CONTEXTS AND FOR ALL COMPOSITE UI’S Not just for HTML clients
  • 87.
    Invoice Composite UIexample InvoiceHeader Order:ShippingI nfo Invoice: InvoiceNumber Invoice: Data and Due date Order: RelationInformation Order:Item- Qty Product:Ite m Product: Description Order: Item-Unit-Price Order: Item- Total- Price Order:Total Billing:Balance All Services participate at the UI level for each individual Item in the Order
  • 88.
    Coupling matrix* * Modifiedversion of Ian Robinson’s matrix: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/ Behavioral coupling Temporal coupling Low High Low High Event oriented Command oriented Emergency services Distributed 3 layer
  • 89.
    TO BREAK TEMPORALCOUPLING & BEHAVIORAL COUPLING SERVICES NEEDS TO COMMUNICATE ASYNCHRONOUSLY USING BUSINESS EVENTS Services communicate facts without making assumptions about what other services intend to do with the events
  • 90.
    Let’s make theimplicit explicit! Old wisdom seems to have been forgotten. Let’s introduce: Business/Domain Events Which: • Signal that something has happened • Closely aligned to the Domain Model • Are handled by a messaging system • They are in the past tense: • CustomerBilled • ParcelShipped • CustomerCreated • ReviewCreated • CommentAdded • CommentDeleted
  • 91.
    Events are oftenthe side effect of Commands A Command message is prescriptive of what should happen. This is a stronger form of coupling than Events. A Command’s primary goal is to capture USER INTENT A Command supports a single usecase and targets a single Aggregate Commands always carry a name in its imperative form: CreateOrder, ShipOrder, CancelOrder, ReimburseCustomer, etc. “A command describes a Task that you want someone else to carry out for you and the recipient can reject the Command”
  • 92.
    Commands & Events Commandsmutate Aggregate state – and if succesful – will result in one or more Events being published Command Event(s) AcceptOrder OrderAccepted ShipOrder OrderShipped AddComment CommentAdded QuarantineReview ReviewQuarantined UnquarantineReview ReviewUnquarantined
  • 93.
    WE NEED TOCHANGE FOCUS FROM SHORT TECHNICAL TRANSACTIONS To long running business transactions supporting business processes
  • 94.
    Using Business Eventsto drive Business Processes Sales Service Shipping Billing Sales Customers MessageChannel Online Ordering System Web Shop (Composite UI) Billing Service Shipping Service Order Accepted Event AcceptOrder Command The sales fulfillment processing can now begin…
  • 95.
    Choreographed Event DrivenProcesses Sales Service Order Accepted Invoicing Service Order Fulfilment (Saga/ Process-Manager) Shipping Service Online Ordering System MessageChannel(e.g.aTopic) Order Accepted Order Accepted Customer Billed Customer Billed Order Approved Order Approved Works as a Finite State Machine (WorkFlow) handling the life cycle of Shipping and thereby forms a very central new Aggregate in the System
  • 96.
    Choreography is verydifferent from the classical orchestrated integration process
  • 97.
    The INPAY approachto Microservices
  • 98.
  • 99.
    Different perspectives ondata With in a given Domain, e.g. Retail, there will exist multiple bounded contexts/sub-domains/business capabilities such as: • Product management • Purchase • Sales • Pricing • Inventory • Shipping • Support • Accounting • Management Each of these lines of business have very specific and unique needs which are relevant for them alone in order to conduct their business. They might use the same name for the entities they’re interested in or they might use different names for the same logical entity.
  • 100.
    Many perspectives ondata Online Retail System Product Unit Price Promotional Price Promotion End Date Stock Keeping Unit (SKU) Quantity On Hand (QOH) Location Code Price Quantity Ordered Name The lifecycle of the data is VERY important! Customer Pricing Inventory Sales Management Reporting
  • 101.
    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 identitySOA: Service
  • 102.
    Billing Product Catalogue Shipping Sales Inventory Pricing Retail domain splitinto a Macro architecture Usually contains more than one aggregate 
  • 103.
    What’s a macroarchitecture • It’s the static/stable(r) parts of your architecture • Which are very costly to refactor and change • Business capabilities are stable • Therefore we should strive to align services with business capabilities / bounded contexts (DDD)
  • 104.
    Service and BusinessCapability 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
  • 105.
    A Service is •The technical authority for a given business capability • It is the owner of all the data and business rules that support this business capability – everywhere (including the UI) • It forms a single source of truth for that capability • This form of business and IT alignment ensures that we can maintain service Autonomy & Encapsulation
  • 106.
  • 107.
  • 108.
    Services, Applications andcode • Each Service and Application is maintained in separate Git repositories • Common IT Operations libraries and infrastructure are maintained in other separate Git repositories
  • 109.
    So what’s insidea Service source repository? • Autonomous Components • Libraries • Adapters • Front-end UI components • API contracts (mainly Events) • DB Schemas • Build file(s)
  • 110.
  • 111.
    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
  • 112.
    Service deployment • Manyservices 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) • Multiple services can cooperate to fulfill a larger use-case (e.g. a workflow or a business process)
  • 113.
    Service Autonomous Component 1..* Is implemented by AService is the technical authority of a specific Business Capability e.g. Sales, Shipping, Billing Services support business processes. Business processes naturally span multiple services, but there will always be a single service that is the actual authority on the business process. Service vs Autonomous Components
  • 114.
    Also known asMicroservices Service Autonomous Component 1..* Is implemented by Service vs Autonomous Components Autonomous-Components/Microservices are a division of Services along Transactional boundaries (a transaction stays within the boundary of a Microservice) Microservices are the individually logical 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 Microservice
  • 115.
    Services are thecorner stone • We talk in terms of Services/business capabilities and the processes/use- cases they support • Autonomous-Components/Microservices are an implementation detail • They are much less stable (which is a good thing – it means they’re easier to replace) • With regards to other Services • subscribe to events from • send commands to (less common) • call operations (in rare occasions)
  • 116.
    Services/Bounded Contexts andAggregates Sales Service PSP ServiceVirtual Banking Service Finance Service Customer customerId … Contract contractId customerId … VBFeeSchedule contractId … PSPFeeSchedule contractId … BillingTemplate contractId …
  • 117.
    INPAY Autonomous Componentdesign principles
  • 118.
  • 119.
    Commands and Events publicclass RegisterBankCmd extends AbstractCommand { @TargetAggregateIdentifier public final BankId bankId; public final String name; public final Country countryOfOperation; public RegisterBankCmd(BankId bankId, String name, Country countryOfOperation) { Objects.requireNonNull(bankId, "bankId"); Objects.requireNonNull(name, "name"); Objects.requireNonNull(countryOfOperation, "countryOfOperation"); this.bankId = bankId; this.name = name; this.countryOfOperation = countryOfOperation; } }
  • 120.
    Commands and Events Thegeneric business event interface includes the name of the topic that subscribers must use public class BankRegistered extends AbstractEvent implements BankEvent { @AggregateIdentifier public final BankId bankId; public final String name; public final Country countryOfOperation; public BankCreated(BankId bankId, String name, Country countryOfOperation) { this.bankId = bankId; this.name = name; this.countryOfOperation = countryOfOperation; } } public interface BankEvent extends Serializable { TopicName TOPIC_NAME = BankingServiceId.ID.topicName("bank-events"); }
  • 121.
    CQRS A single modelcannot be appropriate for reporting, searching and transactional behavior Greg Young, 2008
  • 122.
    Commands, Events andQuery Models Read model Read model Events UI Domain modelQuery/Read model ”AcceptOrder” command ”OrderAccepted” event ”Find all Accepted Orders” Query Commands are Imperative: DoStuff Events are Past tense: StuffDone
  • 123.
    Event Sourcing Aggregates tracktheir own Domain Events and derive state from them Time 07:39 Time 07:40 Time 07:41 Time 07:45 Time 07:46 Time 07:50
  • 124.
    Full CQRS With EventSourcing UIDomain Event Store (can e.g. be a real EventStore DB or a Relational DB) Commands – Change data Commands Events SQL DB Document DB Graph DB UI Data Queries – Ask for data Events Query Build Our single source of truth
  • 125.
    Aggregate public class Bankextends InPayEventSourcedAggregate { @AggregateIdentifier private BankId bankId; @EventSourcedMember private Map<BankAccountId, BankAccount> bankAccounts = new HashMap<>(); public Bank(BankId bankId, String name, Country countryOfOperation) { apply(new BankRegistered(bankId, name, countryOfOperation)); } public void addBankAccount(BankAccountId bankAccountId, …) { if (!bankAccounts.containsKey(bankAccountId)) { apply(new BankAccountAdded(bankId, bankAccountId, …)); } } @EventSourcingHandler private void on(BankRegistered e) { bankId = e.getBankId(); } @EventSourcingHandler private void on(BankAccountAdded e) { BankAccount bankAccount = bankAccounts.put(e.getBankAccountId(), new BankAccount(e.getBankId(), e.getBankAccountId(), …)); } }
  • 126.
    Service project structuresales_service sales_api sales_contract_ac sales_customer_ac frontend sales_contract_manager_adapters contract adapters sales/modules customer psp_service psp_api psp_fees_ac … frontend psp_contract_manager_adapters fees adapters psp/modules fx Legend: Service/Business-Capability External Event/Command Contracts Autonomous Component Autonomous Component Adapter Angular.js Module Builds into a Java JAR Uses Spring MVC/REST All Java 8 artifacts are built using Gradle
  • 127.
    Autonomous Component Library •Can be deployed alone or co-located • Usually deployed together with one or more adapters • Works transparently in a clustered environment • Completely Spring free  • Only depends on our Core infrastructure library • Common types and Id’s • Bus infrastructure • Service lookup • CQRS building blocks (backed by Axon framework)
  • 128.
    Client handled subscriptions •Highly resilient pattern for an Event Driven Architecture that’s backed by AC’s that use EventSourcing. • In this model the publisher of the Events is responsible for the durability of all its Events, typically to an EventStore/EventLog. • Each client (subscriber) maintains durable information of the last event it received from each publisher. • When ever the client starts up it makes a subscription to the publisher where it states from which point in time it wants events published. • This effectively means that publisher can remain simple and the client (subscriber) can remain simple and we don’t need additional sophisticated broker infrastructure such as Kafka+ZooKeeper.
  • 129.
  • 130.
    Client handled subscriptions Publisher Subscriber A Localstorage EventStore Subscriber B Local storage Topic Subscription Topic Subscription TopicSubscriptionHandler TopicSubscriptionHandler EventEvent Event Event EventBus Event Event
  • 131.
    psp_fees_ac (deployed on 10.25.26.102) psp_fees_ac (deployedon 10.25.26.101) Bus Bus Bus Bus sales_contract_ac (deployed on 10.25.26.104) sales_contract_ac (deployed on 10.25.26.103) Federated Bus
  • 132.
  • 133.
  • 134.
    AUTONOMOUS-COMPONENTS/ MICROSERVICES ARE LOGICAL DEPLOYABLEUNITS That doesn’t mean they HAVE to be deployed individually. Design for Distribution But take advantage of locality
  • 135.
  • 136.
    Autonomous Components canbe co-deployed together with Application backends contract_manager (Spring Boot fat–jar) sales_contract_ac sales_customer_ac sales_contract_manager_adapters psp_api psp_fees_ac psp_contract_manager_adapters frontend sales_api app libs contract customer fees
  • 137.
    Application in code @Configuration @ComponentScan(basePackages= { "com.inpay.contractmanager", "com.inpay.adapters", "com.inpay.itops.spring" }) public class Application extends InpaySpringBootApplication { public Application() { super(); } @Override protected String getApplicationName() { return "ContractManager"; } @Override protected Collection<AutonomousComponent> getAutonomousComponentsHostedInThisApplication() { CurrencyExchangeRateAc currencyExchangeRateAc = new CurrencyExchangeRateAc(); return list( new IDMCoreAc(), new PSPFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()), new VBFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()), new ContractAc(), new CustomersAc(), currencyExchangeRateAc ); } public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
  • 138.
    AC in codepublic class PSPAgreementAc extends HzBackedAutonomousComponent { public static AutonomousComponentId SERVICE_AC_ID = PSP_SERVICE_ID.ac("psp_agreement_ac"); … public PSPAgreementAc(CurrencyConverter currencyConverter) { this.currencyConverter = currencyConverter; } @Override public void onInitialize(IConfigureACEnvironment acSetup) { acSetup.withAutonomousComponentId(SERVICE_AC_ID).usingServiceDataSource() .withBusConfiguration(cfg -> { cfg.getAxonContext() .subscribeAnnotatedCommandHandler(new TemplateCmdHandler( cfg.getAxonContext().eventSourcedRepository(PSPTemplate.class), currencyConverter)); …. manageLifecycleFor(templateViewRepository = new TemplateViewRepository(cfg, currencyConverter)); }) .runOnBusStartup((bus, axonContext) -> { bus.registerAxonReplayableTopicPublisher(InternalTemplateEvents.TOPIC_NAME, replayFromAggregate(PSPTemplate.class) .dispatchAggregateEventsOfType(InternalTemplateEvents.class)); bus.subscribeTopic(SERVICE_AC_ID.topicSubscriber("ContractEvents"), ExternalContractEvents.TOPIC_NAME, new SalesTopicSubscription(bus)); }); } public TemplateViewRepository getTemplateViewRepository() { return templateViewRepository; } }
  • 139.
    AC, autonomy and“shared” service data Service DB DB Autonomous Component Autonomous Component Autonomous Component Autonomous Component DB
  • 140.
    50 shades ofinter 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!
  • 141.