SlideShare a Scribd company logo
AUTONOMOUS MICROSERVICES FOR A
FINANCIAL SYSTEM
Jeppe Cramon - @jeppec
Chief Architect - INPAY
“Inpay’s vision is to transform global trade
by making cross-border payments as fast,
easy, safe, and cost-efficient as local bank transfers”
Jacob Tackmann Thomsen
Founder & CEO
2
Our development teams main goal:
Build a flexible and scalable solution
that can grow with the company
3
WE WANT TO BE ABLE TO ADAPT
TO CHANGES QUICKLY

Recommended for you

JUG Frankfurt - Orchestration of microservices
JUG Frankfurt - Orchestration of microservicesJUG Frankfurt - Orchestration of microservices
JUG Frankfurt - Orchestration of microservices

Slides from my talk held at JUG Frankfurt on 27th of September 2017 about microservice orchestration. Source code for the live hacking is here: https://github.com/flowing/flowing-retail

orchestrationbpmnworkflow
Strategies for migration to public cloud
Strategies for migration to public cloudStrategies for migration to public cloud
Strategies for migration to public cloud

This document provides recommendations for organizations considering migrating to the public cloud. It addresses common questions around security, costs, compliance, and architecture decisions. Key recommendations include: - Use threat modeling to prioritize security and consider boundaries and openness. Cloud can improve security when done right. - Be aware of higher initial costs of cloud and factor them into budgets. Speed and agility, not just cost savings, should motivate cloud adoption. - Leverage platform as a service (PaaS) capabilities to simplify designs while limiting vendor lock-in. Start with infrastructure as a service (IaaS) and shift to PaaS over time. - Consider cross-region disaster recovery needs based on compliance and

public cloudcloudmigration
Microservice design patterns
Microservice design patternsMicroservice design patterns
Microservice design patterns

There are many design patterns for building microservices, and most of them are wrong. Actually, that is not true. The fundamental objectives for implementing microservice systems are speed and agility. Speed, of course, is how quickly you can get things done. Regardless of what design patterns you use, if you can quickly build, fix, enhance, and rapidly evolve your microservices, you are heading in the right direction. Agility is the flexibility to move rapidly across the entire development lifecycle while living happily in production. But we can always do better. Right? That is what this talk is about. We will take a look at some of the more common microservice design patterns. And we will compare them to some of the alternatives. For example, what is the more common microlith design pattern, and how getting serious about loose coupling guides the evolution to ways that increase your speed and agility? We will also look at why it is micro at the code level and the data level. Finally, we will cover some practical guidelines, such as why your microservices should do the least amount of work while your users are waiting and techniques for doing that.

microservicesevent orientedcqrs
WE ALL WANT TO MOVE FAST
But many organization experience that they cannot move fast
THE MAIN IMPEDIMENT TO
MOVING FAST?
High coupling
It usually starts simple
“The” DB
UI
Logic
Data Access

Recommended for you

Graphel: A Purely Functional Approach to Digital Interaction
Graphel: A Purely Functional Approach to Digital InteractionGraphel: A Purely Functional Approach to Digital Interaction
Graphel: A Purely Functional Approach to Digital Interaction

1. The document discusses using speech acts as the basis for building immutable conversational interfaces and applications. 2. Speech acts model conversations as sequences of immutable events that narrow responses. This approach can be used to build various interfaces like chatbots, administrative tools, and mobile applications. 3. Experiments can be run by assigning users to different versions of state machine definitions that define how conversations branch based on inputs. This facilitates A/B testing and machine learning to optimize interfaces.

purely functionalclojurepersistent data structure
DDD Belgium Meetup 2017: Events, flows and long running services
DDD Belgium Meetup 2017: Events, flows and long running servicesDDD Belgium Meetup 2017: Events, flows and long running services
DDD Belgium Meetup 2017: Events, flows and long running services

Slides from the talk on 13th of November at the DDD Belgium Meetup in Gent/Brussels held together with Martin Schimak.

dddflowevent driven architecture
November 2017: Collaboration of (micro-)services
November 2017: Collaboration of (micro-)servicesNovember 2017: Collaboration of (micro-)services
November 2017: Collaboration of (micro-)services

Slides from a talk held at WJAX Munic on 9th of November (and some other meetups later in November) about how to tackle collaboration of microservices. Most of the talk was live coding, the respective code is here: https://github.com/flowing/flowing-retail.

circuit breakermicroservicesworkflow
And we end up
with…
Reality rears its ugly head
It’s hard to see
the sky
How to ensure ending up there?
Be in a hurry!
12

Recommended for you

Event sourcing
Event sourcingEvent sourcing
Event sourcing

Event Sourcing By Touraj Ebrahimi. Senior Java Developer and Java Architect. github: toraj58 bitbucket: toraj58 twitter: @toraj58 youtube channel: https://www.youtube.com/channel/UCcLcw6sTk_8G6EgfBr0E5uA

javamicroserviceeventsourcing
The Architect's Two Hats
The Architect's Two HatsThe Architect's Two Hats
The Architect's Two Hats

This presentation, given on the Software Architecture course at the University of Brunel, discusses the interplay between architecture and design. How the designer and architect are really different roles and ones that often have competing goals.

Event driven architecture in practice
Event driven architecture in practiceEvent driven architecture in practice
Event driven architecture in practice

Event Driven Architecture (EDA) is presented as an alternative to Service Oriented Architecture (SOA). In EDA, business capabilities are defined which own parts of the system and communicate through shared communication channels using events, commands, and documents as messages. Examples are provided of a simple event and command message format. Key aspects of EDA include eventual consistency, idempotency, and ability to replay messages. The presentation concludes with discussing some advantages of EDA like improved scalability and isolation, and technologies used in one company's EDA infrastructure like RabbitMQ and Reactive Extensions.

edasoaevent driven architecture
Being in a hurry results in writing bad code
Bad code slows us down every time we want
to change something
13
Bad code is rigid
Changing one thing requires you to modify a lot of
other code to make the codebase consistent again
14
Bad code is fragile
15
When you change a thing you end up
breaking something else!
Coupling
• Coupling is a measure of dependencies:
• Efferent coupling – who do you depend on
• Afferent coupling – who depends on you
• Different aspects on coupling:
• Temporal coupling (processing time of Y affects X – if Y is down can X continue?)
• Spatial coupling (where on the network are the Y instances and how does X know?)
• Behavioral coupling (how much about Y’s behavior does X understand)
X Y

Recommended for you

Saturn 2018: Managing data consistency in a microservice architecture using S...
Saturn 2018: Managing data consistency in a microservice architecture using S...Saturn 2018: Managing data consistency in a microservice architecture using S...
Saturn 2018: Managing data consistency in a microservice architecture using S...

A revised and extended version that I gave at Saturn 2018. The services in a microservice architecture must be loosely coupled and so cannot share database tables. What’s more, two phase commit (a.k.a. a distributed transaction) is not a viable option for modern applications. Consequently, a microservices application must use the Saga pattern, which maintains data consistency using a series of local transactions. In this presentation, you will learn how sagas work and how they differ from traditional transactions. We describe how to use sagas to develop business logic in a microservices application. You will learn effective techniques for orchestrating sagas and how to use messaging for reliability. We will describe the design of a saga framework for Java and show a sample application.

microservicesmicroservice architecturedistributed transactions
MuCon London 2017: Break your event chains
MuCon London 2017: Break your event chainsMuCon London 2017: Break your event chains
MuCon London 2017: Break your event chains

- The document discusses breaking event chains, decentralizing control, and alternatives to workflow engines for orchestrating microservices. It argues that events can decrease coupling but also increase it, and that central control should be avoided but important long-running capabilities still need ownership. Lightweight workflow engines are presented as a better alternative to DIY orchestration since they address hard problems and can run decentralized.

microservicesflow
Introduction to microservices
Introduction to microservicesIntroduction to microservices
Introduction to microservices

This document provides an introduction to microservices, including: - Microservices are small, independently deployable services that work together and are modeled around business domains. - They allow for independent scaling, technology diversity, and enable resiliency through failure design. - Implementing microservices requires automation, high cohesion, loose coupling, and stable APIs. Identifying service boundaries and designing for orchestration and data management are also important aspects of microservices design. - Microservices are not an end goal but a means to solve problems of scale; they must be adopted judiciously based on an organization's needs.

microservicesservice-oriented architecturearchitecture
End result
“Nobody is allowed to modify that module!”
or
“Let’s rewrite!”
17
If we want to go fast,
then we need to do a good job
This means:
• Take your time
• Study the problem
• Work iteratively to refine until you end up at a simple solution
18
Microservices promise a solution to our problem
Monolith
Microservice Microservice
Microservice MicroserviceMicroservice
Microservice
Microservice
There’s never time to do it right
But there’s always time to do it over
20

Recommended for you

Java User Group Maas-Rhine February 2018: 7 sins of workflow
Java User Group Maas-Rhine February 2018: 7 sins of workflowJava User Group Maas-Rhine February 2018: 7 sins of workflow
Java User Group Maas-Rhine February 2018: 7 sins of workflow

Slides from my talk at Eureg JUG Aachen in February 2018. You can find the recoding here: https://youtu.be/hS-4hjeFjt0. Code is available: http://github.com/flowing/flowing-retail and https://github.com/flowing/flowing-retail/tree/master/payment-rest.

workflowworkflow automationcamunda
Microservices for Mortals by Bert Ertman at Codemotion Dubai
 Microservices for Mortals by Bert Ertman at Codemotion Dubai Microservices for Mortals by Bert Ertman at Codemotion Dubai
Microservices for Mortals by Bert Ertman at Codemotion Dubai

With popular poster children such as Netflix and Amazon, Microservices based architecture seems to be the killer approach to 21st century architectures. But are they only for Hollywood Coders pioneering on the bleeding edge of our profession? Or are they ready to be used for your projects and your customers? I will go over the benefits, but more so the pitfalls, of using a Microservices based architecture. What impact does it have on your organization, your applications, on dealing with scale and failures, and how do you prevent your landscape from becoming an unmaintainable nightmare.

scalesmobile application developmentlandscape
JFS 2017 - Orchestration of microservices
JFS 2017 - Orchestration of microservicesJFS 2017 - Orchestration of microservices
JFS 2017 - Orchestration of microservices

This document discusses orchestrating microservices using event-driven architectures and process managers. It describes how independent microservices can collaborate by publishing domain events to which other services subscribe. While this loose coupling is beneficial, long-running processes require persistent state management. The document recommends using a process manager to handle event-command transformation and state for long-running flows, providing visibility, versioning, and other capabilities. It warns against creating monolithic workflows across microservices and advocates defining local flows within bounded contexts.

floworchestrationmicroservices
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
Microservices as an architectural style
22
ARCHITECTURE IS ESSENTIAL
Because it influences how fast we can respond to changes
and what the cost of those changes are
What is the right level of coupling?
This highly depends on
• How likely are things to change
• And what parts that change together
24

Recommended for you

CAP theorem and distributed systems
CAP theorem and distributed systemsCAP theorem and distributed systems
CAP theorem and distributed systems

The document discusses the CAP theorem which states that it is impossible for a distributed computer system to simultaneously provide consistency, availability, and partition tolerance. It defines these terms and explores how different systems address the tradeoffs. Consistency means all nodes see the same data at the same time. Availability means every request results in a response. Partition tolerance means the system continues operating despite network failures. The CAP theorem says a system can only choose two of these properties. The document discusses how different types of systems, like CP and AP systems, handle partitions and trade off consistency and availability. It also notes the CAP theorem is more nuanced in reality with choices made at fine granularity within systems.

highloaddistributed systemsfault tolerance
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old Services
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old ServicesRetiring Service Interfaces: A Retrospective on Two 10+ Year Old Services
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old Services

Presented in Pittsburgh, PA for Abstractions.io in August, 2016. "The greater your adoption success, the greater your retirement pain." The number of APIs has exploded and will continue growing as more teams adopt microservices. In my time at Amazon my team of eight owned hundreds of microservices, covering every possible life cycle phase. Two of our services were more than a decade old. These lingered despite several interface iterations launched to cover alternative use-cases, multiple ownership changes, and funded retirement initiatives. The reason was simple: hundreds of internal and external clients had a dependency on these services. A coordinated migration effort was nearly impossible to prioritize across the whole of Amazon and integrated third-party merchant software. To make matters worse, many of our clients were as old as the services themselves. Several were owned by teams that had long since forgotten about them. We were all victims of these successful services. As I took over as manager of the team I knew that failure to retire these services in the next year would be a critical blow to our system scalability in Q4. Failure was not an option. I was hellbent on hitting the power switch. Every service owner will eventually encounter this problem. Few want to talk about it. In this session I'll elaborate on the challenges facing service owners, my approach to solving them, the impact of our success, and the lessons learned. I'll share the highs and lows - smooth migrations, and the pain of scream test victims. It is my hope that an attendee will be able to learn from these experiences and succeed in their own retirement efforts.

conferenceabstractions.iomicroservices
From no services to Microservices
From no services to MicroservicesFrom no services to Microservices
From no services to Microservices

A journey of a FinTech application into the cloud, starting as a monolith and growing to MicroServices. Why going functional is so good for finance technology, and how Scala helped us build a better application.

microservicesjavanearshoring
MICROSERVICES TELL US TO
ADHERE TO THE SRP
Single Responsibility Principle (SRP) –
“A Microservice should have one reason – and only one reason – to change”
Does your domain
model adhere to
the SRP?
How to create a big entangled
domain model?
27
Result will be fragmented domain logic
Focus on Nouns (Entities)
and retrofit Verbs later
28

Recommended for you

Designing DDD Aggregates
Designing DDD AggregatesDesigning DDD Aggregates
Designing DDD Aggregates

Gabriele Pividori presents to us the importance of communication within Domain-Driven Design, how the Ubiquitous Language can aid our software designs and the value the Aggregate pattern can bring.

domaindrivendesigndddaggregates
CQRS recipes or how to cook your architecture
CQRS recipes or how to cook your architectureCQRS recipes or how to cook your architecture
CQRS recipes or how to cook your architecture

The principles of CQRS is very simple. Separate Reads from Writes. Although when you try to implement it in you can face many technical and functional problems. This presentation starts from very simple architecture and while business requirements are added we consider other architecture ending with a CQRS + DDD + ES one.

cqrsevent sourcingn-layered architectures
Three perspective on migrating to Cloud
Three perspective on migrating to CloudThree perspective on migrating to Cloud
Three perspective on migrating to Cloud

Logicalis Cloud Briefing - get some "Cloud Clarity"! Three perspectives on why and how to migrate to Cloud on your terms - change leadership, legal and technology considerations

cloud computingenterprise cloudmicrosoft
The Verbs capture the intent/task we wish to
accomplish – i.e. the use cases
29
A Use case typically involve more than one Entity
If we primarily model around nouns/entities
we can easily violate the SRP
Changes to requirements
is likely to require changes
to multiple entity classes
30
If a change to requirements forces us to
“refactor” the structure of your domain model
Then it wasn’t a model of the domain!
31
A change to requirements should be a
“change to how we do business”
Not a change to what business we’re in!
32

Recommended for you

Microservices Journey NYC
Microservices Journey NYCMicroservices Journey NYC
Microservices Journey NYC

Christian Posta is a principal middleware specialist and architect who has worked with large microservices architectures. He discusses why companies are moving to microservices and cloud platforms like Kubernetes and OpenShift. He covers characteristics of microservices like small autonomous teams and decentralized decision making. Posta also discusses breaking applications into independent services, shedding dependencies between teams, and using contracts and APIs for communication between services.

microservicesdistributed systemspromise theory
Iot cloud service v2.0
Iot cloud service v2.0Iot cloud service v2.0
Iot cloud service v2.0

The document discusses transitioning from a monolithic architecture to microservices architecture for an IoT cloud platform. Some key points include: - The goals of enabling scalability, supporting new markets, and innovation. - Moving to a microservices architecture can help with scalability, fault tolerance, and independent deployability compared to a monolith. - Organizational structure should also transition from function-based to product-based to align with the architecture. - Technical considerations in building microservices include service interfaces, data management, fault tolerance, and DevOps practices.

iotmicroserviceazure
Best Practices Building Cloud Scale Apps with Microservices
Best Practices Building Cloud Scale Apps with MicroservicesBest Practices Building Cloud Scale Apps with Microservices
Best Practices Building Cloud Scale Apps with Microservices

This presentation covers general engineering and organizational principles for microservices, with 11 specific topics for best practices.

microservicebest practicescloud
"We don't sell domains, WE SELL USE CASES!"
Jim Coplien
33
So instead of focusing on Nouns
We should focus on Verbs!
34
Second reason for big entangled
domain models
Trying to create a single model to serve
everyone
35
Every system has
Multiple Users with multiple roles
Multiple Stakeholders
36

Recommended for you

Orchestration, the conductor's score
Orchestration, the conductor's scoreOrchestration, the conductor's score
Orchestration, the conductor's score

Talk given by David Lucey, Systems Engineering Architect at Salesforce, at Open Network Users Group in May 2016 “Livestock, not Pets.” We’ve all heard the phrase, but it seems to be so much harder in practice. It’s even worse when applications are developed over decades. Well, the Salesforce application suite has been developed over decades, with a massive number of products, features, and offerings within its own ecosystem. Come see how Salesforce wrangles that livestock and handles their scale of infrastructure at a high velocity – all while maintaining their high level of security.

systemssalesforceengineering
A Microservice Journey
A Microservice JourneyA Microservice Journey
A Microservice Journey

The document discusses Christian Posta's journey with microservices architectures. It begins by explaining why organizations are moving to microservices and defines microservices. It then covers related topics like cloud platforms, container technologies like Kubernetes and OpenShift, benefits and drawbacks of microservices, and tools for developing microservices like Docker, Kubernetes, OpenShift, and Camel.

microservicesspring bootopenshift
Microsoft Microservices
Microsoft MicroservicesMicrosoft Microservices
Microsoft Microservices

CPU and RAM costs continue to plummet. Multi-core systems are ubiquitous. Writing code is easier than it has ever been. Why, then, is it still so darn hard to make a scalable system?

microservicesscalabilitydurable service
It’s very hard to come up with one canonical
model that’s good for everybody
37
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 identity

Recommended for you

Phil Green - We're migrating to the cloud - Who needs service management
Phil Green - We're migrating to the cloud - Who needs service managementPhil Green - We're migrating to the cloud - Who needs service management
Phil Green - We're migrating to the cloud - Who needs service management

This presentation explored the importance of service management in the cloud and explore what is needed to build an operating model for the governance, assurance, and day to day operation of cloud services.

The Value of Next Generation Managed Services
The Value of Next Generation Managed ServicesThe Value of Next Generation Managed Services
The Value of Next Generation Managed Services

The document discusses the value of next generation managed services which leverage professional, DevOps, and managed security services to provide intelligent operations and automation through a single billing structure. This allows the managed services provider to be a strategic partner, continuously improving their clients' organizations by reducing costs through efficiency and automation while increasing speed to market.

What is ? Modern business questions 2014
What is ? Modern business questions 2014What is ? Modern business questions 2014
What is ? Modern business questions 2014

What is: - Important - Innovation -- Is it only technology innovation? - Entrepreneurship - Money - Cloud -- Is it more than the internet? - Mobility - Big data - Business Model

innovationmobilitycloud computing
How can we discover bounded contexts?
41
BOUNDED CONTEXT
The setting in which a word or a statement
appears that determines its meaning
42
HOW TO GATHER REQUIREMENTS FROM MANY DIFFERENT
STAKEHOLDERS/DEPARTMENTS/SPECIALISTS?
Department C
Department E
Department A
Department D
Department B
Sequential data gathering?
Time

Recommended for you

MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017
MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017
MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017

This document provides an overview of architecting data protection with Rubrik presented by Andrew Miller and Rebecca Fitzhugh. It discusses key considerations for disaster recovery planning like business impact analyses, service level agreements, recovery point and recovery time objectives. It introduces Rubrik's approach to data management which aims to simplify architectures using a software-defined fabric. The presentation demonstrates Rubrik's capabilities for rapid data ingestion, intelligent SLA policies, instant recovery of VMs and files, and integration with public clouds.

vmworlddisaster recoveryrubrik ransomware backup recovery
Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014
Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014
Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014

Can we spend less on IT, work less, but accomplish more? Join us at The Ritz to discover how Exponential-e’s innovative hybrid services combine the best of traditional IT competencies, with world leading connectivity, Cloud and communication services - and make the impossible, possible. Our CEO, Lee Wade, will be amongst a selection of key speakers, who will share their views on how innovations in Cloud services can be combined with advanced networking technology and service provider experience to deliver the real benefits businesses have been seeking. We'll seek to explain how you can spend less on IT, work less and still accomplish more. We'll demonstrate why your Cloud is only as good as your network, and how you can transition to the Cloud efficiently and securely. Seems too good to be true? Come and see for yourself. View our Cloud video and more on YouTube: https://www.youtube.com/user/Exponentialltd

exponential-ecolocationvoip
What are microservices
What are microservicesWhat are microservices
What are microservices

“ The Microservices architecture has many appealing qualities, but the road towards it has painful traps for the unwary. This book will help you figure out if this path is for you, and how to avoid those traps on your journey.” —Martin Fowler Chief Scientist, ThoughtWorks

what are microservices
Or design by committee?
REQUIREMENTS GATHERING TENDS
TO FOLLOW THE STEPS OF CLASSICAL
OO DESIGN
We write use cases and afterwards look for nouns and verbs
SOFTWARE DEVELOPMENT IS
JOURNEY
Involving collective learning
SO LET’S FIND A FUN AND BETTER
WAY TO DO IT

Recommended for you

.NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith...
.NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith....NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith...
.NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith...

For the past couple of years it seems that Microservices is all the rage. We want to use Microservices, we want to decompose into Microservices and we want Microservices to be a part of our world. While modern tools and platforms such as Docker, Kubernetes, Service Mesh and the public cloud help in implementing and maintaining such systems, the reality is that many fail even before the first line of code was written. This can happen for many reasons; Perhaps you chose a Microservices architecture for the wrong reasons? Maybe the organization wasn't ready for it? Or just possibly - the proposed architecture didn't embrace the true meaning of Microservices? As the CTO of a software services company I get tackle these questions a lot. Join me in this session as I provide my perspective on transitioning from Monolith to Microservices through lessons learned in the real world, while architecting and implementing multiple Microservices based software systems at various customers.

#dotnetfestua#dotnetfest#dotnetfest2019
Design & Implementation of Microservices - James Lewis
Design & Implementation of Microservices - James LewisDesign & Implementation of Microservices - James Lewis
Design & Implementation of Microservices - James Lewis

The document outlines an agenda for a microservices workshop. It is split into four sessions over half a day covering topics such as why use a microservices architecture, principles and constraints of microservices, splitting services, integration strategies, deployment considerations and more. There will be breaks between the sessions.

AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)
AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)
AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)

Blockchain technology is poised for widespread adoption. AWS is working with financial institutions and blockchain providers to further innovation. AWS provides services like CloudTrail, CloudFormation, S3 and VPC that can be used to build robust blockchain solutions globally at scale, whether for public or private blockchains. PwC has experience delivering blockchain proofs-of-concept, pilots and production systems for insurance claims management and asset distribution using these AWS services. Future blockchain use cases may include identity management, utilities, healthcare and energy.

aws cloudaws re:invent 2016ale flores
Event Storming
• Event Storming is a fun way of bringing developers and business experts
together and drive your analysis from the outside and quickly explore
complex business domains in hours instead of days/weeks.
Event Storming
• Invented by Alberto Brandolini
• See http://ziobrando.blogspot.dk/2013/11/introducing-event-storming.html
Event Storming
• Invite the right people
• people with questions and people with answers. They provide the perfect mix of curiosity
and wisdom.
• Provide unlimited modeling space
Event Storming
• Explore the domain starting from Domain/Business Events
Event

Recommended for you

Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices

This is a small introduction to microservices. you can find the differences between microservices and monolithic applications. You will find the pros and cons of microservices. you will also find the challenges (Business/ technical) that you may face while implementing microservices.

softwareagilemicroservices
Recent Advancements in the NIST-JARVIS Infrastructure
Recent Advancements in the NIST-JARVIS InfrastructureRecent Advancements in the NIST-JARVIS Infrastructure
Recent Advancements in the NIST-JARVIS Infrastructure

Recent advancements in the NIST-JARVIS infrastructure: JARVIS-Overview, JARVIS-DFT, AtomGPT, ALIGNN, JARVIS-Leaderboard

jarvisjarvis-dftalignn
Transcript: Details of description part II: Describing images in practice - T...
Transcript: Details of description part II: Describing images in practice - T...Transcript: Details of description part II: Describing images in practice - T...
Transcript: Details of description part II: Describing images in practice - T...

This presentation explores the practical application of image description techniques. Familiar guidelines will be demonstrated in practice, and descriptions will be developed “live”! If you have learned a lot about the theory of image description techniques but want to feel more confident putting them into practice, this is the presentation for you. There will be useful, actionable information for everyone, whether you are working with authors, colleagues, alone, or leveraging AI as a collaborator. Link to presentation recording and slides: https://bnctechforum.ca/sessions/details-of-description-part-ii-describing-images-in-practice/ Presented by BookNet Canada on June 25, 2024, with support from the Department of Canadian Heritage.

a11yaccessibilityalt text
Why Events
• Simple semantic and notation
• Represent the state transitions
• Gives us precision
• Easy to grasp by everybody in the room
53
Events
An Event is non-prescriptive of what should happen in other parts of
the system. It leaves this open to the recipients, so that they themselves
determine what to do based on occurrence of the event.
Events always carry a name in its past-tense form:
OrderWasAccepted, OrderHasShipped, CustomerWasReimbursed
Other qualities
• Immutable, i.e. content cannot be changed
• Always carries the ID of the Business Object it relates to
• An event can and will typically will be published to multiple
consumers.
• The publisher of the event does not know who the recipients are
• And it doesn’t know what the recipients intend to do with the event
“An Event describes something that HAS
happened”
Why Events
• Simple semantic and notation
• Represent the state transitions
• Gives us precision
• Easy to grasp by everybody in the room
• Place them along a timeline to visualize the process
• An event might be the predecessor or the follower of another one.
55
Event Storming
• What causes Domain Events?
• User Action model it as a Command
• External system
• Time
• Other Domain Events
• Documents
External
Time
Command Role
Event Event
Document

Recommended for you

Advanced Techniques for Cyber Security Analysis and Anomaly Detection
Advanced Techniques for Cyber Security Analysis and Anomaly DetectionAdvanced Techniques for Cyber Security Analysis and Anomaly Detection
Advanced Techniques for Cyber Security Analysis and Anomaly Detection

Cybersecurity is a major concern in today's connected digital world. Threats to organizations are constantly evolving and have the potential to compromise sensitive information, disrupt operations, and lead to significant financial losses. Traditional cybersecurity techniques often fall short against modern attackers. Therefore, advanced techniques for cyber security analysis and anomaly detection are essential for protecting digital assets. This blog explores these cutting-edge methods, providing a comprehensive overview of their application and importance.

cybersecurityanomaly detectionadvanced techniques
Pigging Solutions Sustainability brochure.pdf
Pigging Solutions Sustainability brochure.pdfPigging Solutions Sustainability brochure.pdf
Pigging Solutions Sustainability brochure.pdf

Sustainability requires ingenuity and stewardship. Did you know Pigging Solutions pigging systems help you achieve your sustainable manufacturing goals AND provide rapid return on investment. How? Our systems recover over 99% of product in transfer piping. Recovering trapped product from transfer lines that would otherwise become flush-waste, means you can increase batch yields and eliminate flush waste. From raw materials to finished product, if you can pump it, we can pig it.

pigging solutionsprocess piggingproduct transfers
[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf
[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf
[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf

Kief Morris rethinks the infrastructure code delivery lifecycle, advocating for a shift towards composable infrastructure systems. We should shift to designing around deployable components rather than code modules, use more useful levels of abstraction, and drive design and deployment from applications rather than bottom-up, monolithic architecture and delivery.

infrastructure as codeclouddevops
Events are often the side effect of Commands
A Command is prescriptive of what should happen. This is a stronger form of
coupling than Events or Documents.
A Command’s primary goal is to capture USER INTENT
A Command supports a single usecase and targets a single Business Object
Commands always carry a name in its imperative form: CreateOrder, ShipOrder,
CancelOrder, ReimburseCustomer, etc.
Other qualities
• Immutable, i.e. content cannot be changed
• Always carries the ID of the Business Object that it relates to
• A command can only be handled by ONE service
• The Operations that consume Commands don’t return values – but can throw
exceptions
“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 Business Object state which results in
one or more Events being published
Command Event(s)
AcceptOrder OrderAccepted
ShipOrder OrderShipped
AddComment CommentAdded
QuarantineReview ReviewQuarantined
UnquarantineReview ReviewUnquarantined
Also, UI’s give you valuable input
Create Task based UI mockups
59
60

Recommended for you

UiPath Community Day Kraków: Devs4Devs Conference
UiPath Community Day Kraków: Devs4Devs ConferenceUiPath Community Day Kraków: Devs4Devs Conference
UiPath Community Day Kraków: Devs4Devs Conference

We are honored to launch and host this event for our UiPath Polish Community, with the help of our partners - Proservartner! We certainly hope we have managed to spike your interest in the subjects to be presented and the incredible networking opportunities at hand, too! Check out our proposed agenda below 👇👇 08:30 ☕ Welcome coffee (30') 09:00 Opening note/ Intro to UiPath Community (10') Cristina Vidu, Global Manager, Marketing Community @UiPath Dawid Kot, Digital Transformation Lead @Proservartner 09:10 Cloud migration - Proservartner & DOVISTA case study (30') Marcin Drozdowski, Automation CoE Manager @DOVISTA Pawel Kamiński, RPA developer @DOVISTA Mikolaj Zielinski, UiPath MVP, Senior Solutions Engineer @Proservartner 09:40 From bottlenecks to breakthroughs: Citizen Development in action (25') Pawel Poplawski, Director, Improvement and Automation @McCormick & Company Michał Cieślak, Senior Manager, Automation Programs @McCormick & Company 10:05 Next-level bots: API integration in UiPath Studio (30') Mikolaj Zielinski, UiPath MVP, Senior Solutions Engineer @Proservartner 10:35 ☕ Coffee Break (15') 10:50 Document Understanding with my RPA Companion (45') Ewa Gruszka, Enterprise Sales Specialist, AI & ML @UiPath 11:35 Power up your Robots: GenAI and GPT in REFramework (45') Krzysztof Karaszewski, Global RPA Product Manager 12:20 🍕 Lunch Break (1hr) 13:20 From Concept to Quality: UiPath Test Suite for AI-powered Knowledge Bots (30') Kamil Miśko, UiPath MVP, Senior RPA Developer @Zurich Insurance 13:50 Communications Mining - focus on AI capabilities (30') Thomasz Wierzbicki, Business Analyst @Office Samurai 14:20 Polish MVP panel: Insights on MVP award achievements and career profiling

#uipathcommunity#automation#automationdeveloper
Details of description part II: Describing images in practice - Tech Forum 2024
Details of description part II: Describing images in practice - Tech Forum 2024Details of description part II: Describing images in practice - Tech Forum 2024
Details of description part II: Describing images in practice - Tech Forum 2024

This presentation explores the practical application of image description techniques. Familiar guidelines will be demonstrated in practice, and descriptions will be developed “live”! If you have learned a lot about the theory of image description techniques but want to feel more confident putting them into practice, this is the presentation for you. There will be useful, actionable information for everyone, whether you are working with authors, colleagues, alone, or leveraging AI as a collaborator. Link to presentation recording and transcript: https://bnctechforum.ca/sessions/details-of-description-part-ii-describing-images-in-practice/ Presented by BookNet Canada on June 25, 2024, with support from the Department of Canadian Heritage.

a11yaccessibilityalt text
Manual | Product | Research Presentation
Manual | Product | Research PresentationManual | Product | Research Presentation
Manual | Product | Research Presentation

Manual Method of Product Research | Helium10 | MBS RETRIEVER

product researchhelium10 | mbs retriever
Domain modeling
61
When discussing with Business Experts
Focus on data fields and NOT entities
62
Focus on which data fields clump together
(or are talked about together)
and what fields are separate
Place the fields in piles,
that later will become your
bounded contexts
63
Don’t name the piles before you know what
they are
This avoids cognitive bias
64

Recommended for you

TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-InTrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In

Six months into 2024, and it is clear the privacy ecosystem takes no days off!! Regulators continue to implement and enforce new regulations, businesses strive to meet requirements, and technology advances like AI have privacy professionals scratching their heads about managing risk. What can we learn about the first six months of data privacy trends and events in 2024? How should this inform your privacy program management for the rest of the year? Join TrustArc, Goodwin, and Snyk privacy experts as they discuss the changes we’ve seen in the first half of 2024 and gain insight into the concrete, actionable steps you can take to up-level your privacy program in the second half of the year. This webinar will review: - Key changes to privacy regulations in 2024 - Key themes in privacy and data governance in 2024 - How to maximize your privacy program in the second half of 2024

data privacyprivacy complianceai
How RPA Help in the Transportation and Logistics Industry.pptx
How RPA Help in the Transportation and Logistics Industry.pptxHow RPA Help in the Transportation and Logistics Industry.pptx
How RPA Help in the Transportation and Logistics Industry.pptx

Revolutionize your transportation processes with our cutting-edge RPA software. Automate repetitive tasks, reduce costs, and enhance efficiency in the logistics sector with our advanced solutions.

rpa in transportationrpa in transportation industryrpa in transportation sector
Research Directions for Cross Reality Interfaces
Research Directions for Cross Reality InterfacesResearch Directions for Cross Reality Interfaces
Research Directions for Cross Reality Interfaces

An invited talk given by Mark Billinghurst on Research Directions for Cross Reality Interfaces. This was given on July 2nd 2024 as part of the 2024 Summer School on Cross Reality in Hagenberg, Austria (July 1st - 7th)

augmented realitycross realityvirtual reality
Give the piles gibberish or color names
65
UI
BL
DAO
UI
BL
Entity
UI
BL
Entity
UI
BL
Entity
UI
BL
Entity
What we see, is that we move from
Towards Bounded Context that are fairly small (but not too small)
and rarely need to call each other
Sales Pricing InventoryShipping
✕ ✕ ✕
UI
BL
DAO
UI
BL
DAO
UI
BL
DAO
UI
BL
DAO
So where does (micro) services fit into this?
68

Recommended for you

Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...

Have you noticed the OpenSSF Scorecard badges on the official Dart and Flutter repos? It's Google's way of showing that they care about security. Practices such as pinning dependencies, branch protection, required reviews, continuous integration tests etc. are measured to provide a score and accompanying badge. You can do the same for your projects, and this presentation will show you how, with an emphasis on the unique challenges that come up when working with Dart and Flutter. The session will provide a walkthrough of the steps involved in securing a first repository, and then what it takes to repeat that process across an organization with multiple repos. It will also look at the ongoing maintenance involved once scorecards have been implemented, and how aspects of that maintenance can be better automated to minimize toil.

dartflutteropenssf
Choose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presenceChoose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presence

Our Linux Web Hosting plans offer unbeatable performance, security, and scalability, ensuring your website runs smoothly and efficiently. Visit- https://onliveserver.com/linux-web-hosting/

cheap linux hosting
Calgary MuleSoft Meetup APM and IDP .pptx
Calgary MuleSoft Meetup APM and IDP .pptxCalgary MuleSoft Meetup APM and IDP .pptx
Calgary MuleSoft Meetup APM and IDP .pptx

MuleSoft Meetup on APM and IDP

mulesoftai
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 (including the UI)
• It forms a single source of truth for that bounded context
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 NOT share state

Recommended for you

How to Build a Profitable IoT Product.pptx
How to Build a Profitable IoT Product.pptxHow to Build a Profitable IoT Product.pptx
How to Build a Profitable IoT Product.pptx

How do we build an IoT product, and make it profitable? Talk from the IoT meetup in March 2024. https://www.meetup.com/iot-sweden/events/299487375/

iot
How Social Media Hackers Help You to See Your Wife's Message.pdf
How Social Media Hackers Help You to See Your Wife's Message.pdfHow Social Media Hackers Help You to See Your Wife's Message.pdf
How Social Media Hackers Help You to See Your Wife's Message.pdf

In the modern digital era, social media platforms have become integral to our daily lives. These platforms, including Facebook, Instagram, WhatsApp, and Snapchat, offer countless ways to connect, share, and communicate.

social media hackerfacebook hackerhire a instagram hacker
Measuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at TwitterMeasuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at Twitter

Widya Salim and Victor Ma will outline the causal impact analysis, framework, and key learnings used to quantify the impact of reducing Twitter's network latency.

SERVICES ARE AUTONOMOUS
Autonomy is essential for
Scalability (scale out clustering)
Reliability (fail over clustering)
SERVICES ARE AUTONOMOUS
Autonomy is essential for
Reusability
Adaptability
How do we communicate between our
services?
75
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

Recommended for you

Coordinate Systems in FME 101 - Webinar Slides
Coordinate Systems in FME 101 - Webinar SlidesCoordinate Systems in FME 101 - Webinar Slides
Coordinate Systems in FME 101 - Webinar Slides

If you’ve ever had to analyze a map or GPS data, chances are you’ve encountered and even worked with coordinate systems. As historical data continually updates through GPS, understanding coordinate systems is increasingly crucial. However, not everyone knows why they exist or how to effectively use them for data-driven insights. During this webinar, you’ll learn exactly what coordinate systems are and how you can use FME to maintain and transform your data’s coordinate systems in an easy-to-digest way, accurately representing the geographical space that it exists within. During this webinar, you will have the chance to: - Enhance Your Understanding: Gain a clear overview of what coordinate systems are and their value - Learn Practical Applications: Why we need datams and projections, plus units between coordinate systems - Maximize with FME: Understand how FME handles coordinate systems, including a brief summary of the 3 main reprojectors - Custom Coordinate Systems: Learn how to work with FME and coordinate systems beyond what is natively supported - Look Ahead: Gain insights into where FME is headed with coordinate systems in the future Don’t miss the opportunity to improve the value you receive from your coordinate system data, ultimately allowing you to streamline your data analysis and maximize your time. See you there!

What’s New in Teams Calling, Meetings and Devices May 2024
What’s New in Teams Calling, Meetings and Devices May 2024What’s New in Teams Calling, Meetings and Devices May 2024
What’s New in Teams Calling, Meetings and Devices May 2024

This is a powerpoint that features Microsoft Teams Devices and everything that is new including updates to its software and devices for May 2024

microsoft teamsmicrosoft
Best Programming Language for Civil Engineers
Best Programming Language for Civil EngineersBest Programming Language for Civil Engineers
Best Programming Language for Civil Engineers

The integration of programming into civil engineering is transforming the industry. We can design complex infrastructure projects and analyse large datasets. Imagine revolutionizing the way we build our cities and infrastructure, all by the power of coding. Programming skills are no longer just a bonus—they’re a game changer in this era. Technology is revolutionizing civil engineering by integrating advanced tools and techniques. Programming allows for the automation of repetitive tasks, enhancing the accuracy of designs, simulations, and analyses. With the advent of artificial intelligence and machine learning, engineers can now predict structural behaviors under various conditions, optimize material usage, and improve project planning.

programmingcodingcivil engineering
But all the cool kids tell us to use REST
between (micro)services?
77
Service Dependencies
Source: https://www.infoq.com/presentations/netflix-ipc
WHAT’S THE CHALLENGE
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
80
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

Recommended for you

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

Recommended for you

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
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
• And what about timeouts?
• X Phase Commit is fragile by design
WE NEED TO CHANGE FOCUS FROM
SHORT TECHNICAL TRANSACTIONS
To long running business transactions
supporting business processes

Recommended for you

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
SERVICES AT INPAY
Services/Business-capabilities in INPAY
Currency
Service
Banking
Service
Identity
Management
Service
Sales
Service
PSP
Service
3rd party
Providers
Service
Virtual
Banking
Service
IT
Operations
Compliance
Service

Recommended for you

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
We need more fine grained building blocks
Autonomous Components
A Service represents a logical boundary
95
Service
Autonomous
Component
Autonomous
Component
UI component
UI component
An Application is the plate where Components are
co-deployed
96
Sales service components
PSP service components
…

Recommended for you

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
Bounded-Context/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
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

Recommended for you

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
Service
Virtual Banking
Service
Customer
customerId
…
Contract
contractId
customerId
…
VBFeeSchedule
contractId
…
PSPFeeSchedule
contractId
…
BillingTemplate
contractId
…
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

Recommended for you

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
Infrastructure patterns
106
Create Contract
Sales Service : Contracts_Ac
Contract Manager Application
PSP Service : Agreement_Ac
ContractCreated
ContractCreated
Publish
PayInTemplateCreated
ContractEvents
<<Topic>>
Client handled subscriptions
• Highly resilient pattern for an Event Driven Architecture that’s backed by Event-
Sourced AC’s
• 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 has
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.

Recommended for you

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
What about applications?
112

Recommended for you

Applications in INPAY
Identity
Management
Application
Contract
Manager
Application
Treasury
Application
Compliance
Application
Operations
Application
CRM
PSP
Gateway
PSP
Merchant
Application
ERP
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/
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
Screen view != View model
Think in composites
116

Recommended for you

117
118
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:
{id: ISBN-10 0-321-83457-7 }
ImageService
BookService
ReviewService
PriceService
InventoryService
OthersAlsoBoughtService
PriceService
ReviewService
BookService
ImageService
BookService

Recommended for you

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
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
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
api_psp
psp_fees_ac
psp_contract_manager_adapters
frontend
api_sales
app
libs
contract
customer
fees
Be pragmatic
Some services are more stable
In which case we allow other services to call them using local
calls
124

Recommended for you

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 ApplicationIdentifier getApplicationIdentifier() {
return ApplicationIdentifier.from("ContractManager");
}
@Override
protected Collection<AutonomousComponent> getAutonomousComponentsHostedInThisApplication() {
CurrencyExchangeRateAc currencyExchangeRateAc = new CurrencyExchangeRateAc();
return list(
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!

Recommended for you

5 Microservices Do’s
• Identify Business Capabilities (or Bounded Contexts) and split your services according
to them. A service is owned by one team that builds and runs the service. This gives you
proper business and IT alignment and allows pin point accuracy with regards to spending
money to solve problems.
• Spend time to understand the business processes and the domain. At first you must go
slow to go fast. Building microservices properly takes time and is not trivial. Identify how
likely things are to change and what things change together.
• Focus on the business side effects - also know as the Events and make them a first class
principle. Avoid RPC/REST/Request-Response between Services - events are the API.
• Consider building composite application and Backend’s For Frontend's (BFF’s) to
decouple services further. An application is owned by a dedicated team, but may borrow
developers from service teams.
• Learn from history. Don’t repeat the mistakes that gave (misapplied) SOA a bad name.
Also, microservice might not be as small as you think - we need low coupling as well as high
cohesion :)
5 Microservices Don’ts
• Do not introduce a network boundary as an excuse to write better code - many have
troubles with poorly modularized monoliths and believe that introducing network between
modules magically solves the problem. If you don’t change your thinking and design, you
will end up with a distributed monolith, which has all the disadvantages of a monolith, the
disadvantages of a distributed system and none of the advantages of microservices
• Don't split the atom! Distributed Transactions are never easy. Learn about the CAP
theorem and avoid Request/Response API’s between Services.
• Don't fall into the trap of “Not my problem”. When working on isolated code bases teams
can loose sight of the big picture.
• Identify the bottlenecks and possible solutions before deciding to split a problem into
one or more microservices. There’s nothing the guarantees that your microservice scales
better than your monolith.
• Don't do big bang rewrites. Move towards microservices gradually while focusing on
functional areas that can replace or support the old monolith. Don’t rewrite core business
while being new to microservices.
Thanks :)

More Related Content

What's hot

Timeless design in a cloud-native world
Timeless design in a cloud-native worldTimeless design in a cloud-native world
Timeless design in a cloud-native world
Uwe Friedrichsen
 
Event Driven Architecture
Event Driven ArchitectureEvent Driven Architecture
Event Driven Architecture
Chris Patterson
 
Event-Driven Service-oriented Architecture (EDSOA)
Event-Driven Service-oriented Architecture (EDSOA)Event-Driven Service-oriented Architecture (EDSOA)
Event-Driven Service-oriented Architecture (EDSOA)
Attune Infocom Pvt Ltd
 
JUG Frankfurt - Orchestration of microservices
JUG Frankfurt - Orchestration of microservicesJUG Frankfurt - Orchestration of microservices
JUG Frankfurt - Orchestration of microservices
Bernd Ruecker
 
Strategies for migration to public cloud
Strategies for migration to public cloudStrategies for migration to public cloud
Strategies for migration to public cloud
Siddharth Ram
 
Microservice design patterns
Microservice design patternsMicroservice design patterns
Microservice design patterns
Hugh McKee
 
Graphel: A Purely Functional Approach to Digital Interaction
Graphel: A Purely Functional Approach to Digital InteractionGraphel: A Purely Functional Approach to Digital Interaction
Graphel: A Purely Functional Approach to Digital Interaction
mtrimpe
 
DDD Belgium Meetup 2017: Events, flows and long running services
DDD Belgium Meetup 2017: Events, flows and long running servicesDDD Belgium Meetup 2017: Events, flows and long running services
DDD Belgium Meetup 2017: Events, flows and long running services
Bernd Ruecker
 
November 2017: Collaboration of (micro-)services
November 2017: Collaboration of (micro-)servicesNovember 2017: Collaboration of (micro-)services
November 2017: Collaboration of (micro-)services
Bernd Ruecker
 
Event sourcing
Event sourcingEvent sourcing
Event sourcing
Touraj Ebrahimi
 
The Architect's Two Hats
The Architect's Two HatsThe Architect's Two Hats
The Architect's Two Hats
Ben Stopford
 
Event driven architecture in practice
Event driven architecture in practiceEvent driven architecture in practice
Event driven architecture in practice
mimmozzo_
 
Saturn 2018: Managing data consistency in a microservice architecture using S...
Saturn 2018: Managing data consistency in a microservice architecture using S...Saturn 2018: Managing data consistency in a microservice architecture using S...
Saturn 2018: Managing data consistency in a microservice architecture using S...
Chris Richardson
 
MuCon London 2017: Break your event chains
MuCon London 2017: Break your event chainsMuCon London 2017: Break your event chains
MuCon London 2017: Break your event chains
Bernd Ruecker
 
Introduction to microservices
Introduction to microservicesIntroduction to microservices
Introduction to microservices
Paulo Gandra de Sousa
 
Java User Group Maas-Rhine February 2018: 7 sins of workflow
Java User Group Maas-Rhine February 2018: 7 sins of workflowJava User Group Maas-Rhine February 2018: 7 sins of workflow
Java User Group Maas-Rhine February 2018: 7 sins of workflow
Bernd Ruecker
 
Microservices for Mortals by Bert Ertman at Codemotion Dubai
 Microservices for Mortals by Bert Ertman at Codemotion Dubai Microservices for Mortals by Bert Ertman at Codemotion Dubai
Microservices for Mortals by Bert Ertman at Codemotion Dubai
Codemotion Dubai
 
JFS 2017 - Orchestration of microservices
JFS 2017 - Orchestration of microservicesJFS 2017 - Orchestration of microservices
JFS 2017 - Orchestration of microservices
Bernd Ruecker
 
CAP theorem and distributed systems
CAP theorem and distributed systemsCAP theorem and distributed systems
CAP theorem and distributed systems
Klika Tech, Inc
 
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old Services
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old ServicesRetiring Service Interfaces: A Retrospective on Two 10+ Year Old Services
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old Services
allingeek
 

What's hot (20)

Timeless design in a cloud-native world
Timeless design in a cloud-native worldTimeless design in a cloud-native world
Timeless design in a cloud-native world
 
Event Driven Architecture
Event Driven ArchitectureEvent Driven Architecture
Event Driven Architecture
 
Event-Driven Service-oriented Architecture (EDSOA)
Event-Driven Service-oriented Architecture (EDSOA)Event-Driven Service-oriented Architecture (EDSOA)
Event-Driven Service-oriented Architecture (EDSOA)
 
JUG Frankfurt - Orchestration of microservices
JUG Frankfurt - Orchestration of microservicesJUG Frankfurt - Orchestration of microservices
JUG Frankfurt - Orchestration of microservices
 
Strategies for migration to public cloud
Strategies for migration to public cloudStrategies for migration to public cloud
Strategies for migration to public cloud
 
Microservice design patterns
Microservice design patternsMicroservice design patterns
Microservice design patterns
 
Graphel: A Purely Functional Approach to Digital Interaction
Graphel: A Purely Functional Approach to Digital InteractionGraphel: A Purely Functional Approach to Digital Interaction
Graphel: A Purely Functional Approach to Digital Interaction
 
DDD Belgium Meetup 2017: Events, flows and long running services
DDD Belgium Meetup 2017: Events, flows and long running servicesDDD Belgium Meetup 2017: Events, flows and long running services
DDD Belgium Meetup 2017: Events, flows and long running services
 
November 2017: Collaboration of (micro-)services
November 2017: Collaboration of (micro-)servicesNovember 2017: Collaboration of (micro-)services
November 2017: Collaboration of (micro-)services
 
Event sourcing
Event sourcingEvent sourcing
Event sourcing
 
The Architect's Two Hats
The Architect's Two HatsThe Architect's Two Hats
The Architect's Two Hats
 
Event driven architecture in practice
Event driven architecture in practiceEvent driven architecture in practice
Event driven architecture in practice
 
Saturn 2018: Managing data consistency in a microservice architecture using S...
Saturn 2018: Managing data consistency in a microservice architecture using S...Saturn 2018: Managing data consistency in a microservice architecture using S...
Saturn 2018: Managing data consistency in a microservice architecture using S...
 
MuCon London 2017: Break your event chains
MuCon London 2017: Break your event chainsMuCon London 2017: Break your event chains
MuCon London 2017: Break your event chains
 
Introduction to microservices
Introduction to microservicesIntroduction to microservices
Introduction to microservices
 
Java User Group Maas-Rhine February 2018: 7 sins of workflow
Java User Group Maas-Rhine February 2018: 7 sins of workflowJava User Group Maas-Rhine February 2018: 7 sins of workflow
Java User Group Maas-Rhine February 2018: 7 sins of workflow
 
Microservices for Mortals by Bert Ertman at Codemotion Dubai
 Microservices for Mortals by Bert Ertman at Codemotion Dubai Microservices for Mortals by Bert Ertman at Codemotion Dubai
Microservices for Mortals by Bert Ertman at Codemotion Dubai
 
JFS 2017 - Orchestration of microservices
JFS 2017 - Orchestration of microservicesJFS 2017 - Orchestration of microservices
JFS 2017 - Orchestration of microservices
 
CAP theorem and distributed systems
CAP theorem and distributed systemsCAP theorem and distributed systems
CAP theorem and distributed systems
 
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old Services
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old ServicesRetiring Service Interfaces: A Retrospective on Two 10+ Year Old Services
Retiring Service Interfaces: A Retrospective on Two 10+ Year Old Services
 

Similar to Autonomous microservices for a Financial System

From no services to Microservices
From no services to MicroservicesFrom no services to Microservices
From no services to Microservices
João Cavalheiro
 
Designing DDD Aggregates
Designing DDD AggregatesDesigning DDD Aggregates
Designing DDD Aggregates
Andrew McCaughan
 
CQRS recipes or how to cook your architecture
CQRS recipes or how to cook your architectureCQRS recipes or how to cook your architecture
CQRS recipes or how to cook your architecture
Thomas Jaskula
 
Three perspective on migrating to Cloud
Three perspective on migrating to CloudThree perspective on migrating to Cloud
Three perspective on migrating to Cloud
Logicalis Australia
 
Microservices Journey NYC
Microservices Journey NYCMicroservices Journey NYC
Microservices Journey NYC
Christian Posta
 
Iot cloud service v2.0
Iot cloud service v2.0Iot cloud service v2.0
Iot cloud service v2.0
Vinod Wilson
 
Best Practices Building Cloud Scale Apps with Microservices
Best Practices Building Cloud Scale Apps with MicroservicesBest Practices Building Cloud Scale Apps with Microservices
Best Practices Building Cloud Scale Apps with Microservices
Jim (张建军) Zhang
 
Orchestration, the conductor's score
Orchestration, the conductor's scoreOrchestration, the conductor's score
Orchestration, the conductor's score
Salesforce Engineering
 
A Microservice Journey
A Microservice JourneyA Microservice Journey
A Microservice Journey
Christian Posta
 
Microsoft Microservices
Microsoft MicroservicesMicrosoft Microservices
Microsoft Microservices
Chase Aucoin
 
Phil Green - We're migrating to the cloud - Who needs service management
Phil Green - We're migrating to the cloud - Who needs service managementPhil Green - We're migrating to the cloud - Who needs service management
Phil Green - We're migrating to the cloud - Who needs service management
itSMF UK
 
The Value of Next Generation Managed Services
The Value of Next Generation Managed ServicesThe Value of Next Generation Managed Services
The Value of Next Generation Managed Services
CloudHesive
 
What is ? Modern business questions 2014
What is ? Modern business questions 2014What is ? Modern business questions 2014
What is ? Modern business questions 2014
Exo Futures
 
MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017
MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017
MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017
Andrew Miller
 
Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014
Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014
Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014
Exponential_e
 
What are microservices
What are microservicesWhat are microservices
What are microservices
Krunalkumar Rajdip
 
.NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith...
.NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith....NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith...
.NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith...
NETFest
 
Design & Implementation of Microservices - James Lewis
Design & Implementation of Microservices - James LewisDesign & Implementation of Microservices - James Lewis
Design & Implementation of Microservices - James Lewis
JAXLondon_Conference
 
AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)
AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)
AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)
Amazon Web Services
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
MahmoudZidan41
 

Similar to Autonomous microservices for a Financial System (20)

From no services to Microservices
From no services to MicroservicesFrom no services to Microservices
From no services to Microservices
 
Designing DDD Aggregates
Designing DDD AggregatesDesigning DDD Aggregates
Designing DDD Aggregates
 
CQRS recipes or how to cook your architecture
CQRS recipes or how to cook your architectureCQRS recipes or how to cook your architecture
CQRS recipes or how to cook your architecture
 
Three perspective on migrating to Cloud
Three perspective on migrating to CloudThree perspective on migrating to Cloud
Three perspective on migrating to Cloud
 
Microservices Journey NYC
Microservices Journey NYCMicroservices Journey NYC
Microservices Journey NYC
 
Iot cloud service v2.0
Iot cloud service v2.0Iot cloud service v2.0
Iot cloud service v2.0
 
Best Practices Building Cloud Scale Apps with Microservices
Best Practices Building Cloud Scale Apps with MicroservicesBest Practices Building Cloud Scale Apps with Microservices
Best Practices Building Cloud Scale Apps with Microservices
 
Orchestration, the conductor's score
Orchestration, the conductor's scoreOrchestration, the conductor's score
Orchestration, the conductor's score
 
A Microservice Journey
A Microservice JourneyA Microservice Journey
A Microservice Journey
 
Microsoft Microservices
Microsoft MicroservicesMicrosoft Microservices
Microsoft Microservices
 
Phil Green - We're migrating to the cloud - Who needs service management
Phil Green - We're migrating to the cloud - Who needs service managementPhil Green - We're migrating to the cloud - Who needs service management
Phil Green - We're migrating to the cloud - Who needs service management
 
The Value of Next Generation Managed Services
The Value of Next Generation Managed ServicesThe Value of Next Generation Managed Services
The Value of Next Generation Managed Services
 
What is ? Modern business questions 2014
What is ? Modern business questions 2014What is ? Modern business questions 2014
What is ? Modern business questions 2014
 
MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017
MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017
MGT3342BUS - Architecting Data Protection with Rubrik - VMworld 2017
 
Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014
Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014
Exponential-e | Cloud Revolution Seminar at the Ritz, 20th November 2014
 
What are microservices
What are microservicesWhat are microservices
What are microservices
 
.NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith...
.NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith....NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith...
.NET Fest 2019. Eran Stiller. 6 Lessons I Learned on My Journey from Monolith...
 
Design & Implementation of Microservices - James Lewis
Design & Implementation of Microservices - James LewisDesign & Implementation of Microservices - James Lewis
Design & Implementation of Microservices - James Lewis
 
AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)
AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)
AWS re:Invent 2016: Blockchain on AWS: Disrupting the Norm (GPST301)
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
 

Recently uploaded

Recent Advancements in the NIST-JARVIS Infrastructure
Recent Advancements in the NIST-JARVIS InfrastructureRecent Advancements in the NIST-JARVIS Infrastructure
Recent Advancements in the NIST-JARVIS Infrastructure
KAMAL CHOUDHARY
 
Transcript: Details of description part II: Describing images in practice - T...
Transcript: Details of description part II: Describing images in practice - T...Transcript: Details of description part II: Describing images in practice - T...
Transcript: Details of description part II: Describing images in practice - T...
BookNet Canada
 
Advanced Techniques for Cyber Security Analysis and Anomaly Detection
Advanced Techniques for Cyber Security Analysis and Anomaly DetectionAdvanced Techniques for Cyber Security Analysis and Anomaly Detection
Advanced Techniques for Cyber Security Analysis and Anomaly Detection
Bert Blevins
 
Pigging Solutions Sustainability brochure.pdf
Pigging Solutions Sustainability brochure.pdfPigging Solutions Sustainability brochure.pdf
Pigging Solutions Sustainability brochure.pdf
Pigging Solutions
 
[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf
[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf
[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf
Kief Morris
 
UiPath Community Day Kraków: Devs4Devs Conference
UiPath Community Day Kraków: Devs4Devs ConferenceUiPath Community Day Kraków: Devs4Devs Conference
UiPath Community Day Kraków: Devs4Devs Conference
UiPathCommunity
 
Details of description part II: Describing images in practice - Tech Forum 2024
Details of description part II: Describing images in practice - Tech Forum 2024Details of description part II: Describing images in practice - Tech Forum 2024
Details of description part II: Describing images in practice - Tech Forum 2024
BookNet Canada
 
Manual | Product | Research Presentation
Manual | Product | Research PresentationManual | Product | Research Presentation
Manual | Product | Research Presentation
welrejdoall
 
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-InTrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc
 
How RPA Help in the Transportation and Logistics Industry.pptx
How RPA Help in the Transportation and Logistics Industry.pptxHow RPA Help in the Transportation and Logistics Industry.pptx
How RPA Help in the Transportation and Logistics Industry.pptx
SynapseIndia
 
Research Directions for Cross Reality Interfaces
Research Directions for Cross Reality InterfacesResearch Directions for Cross Reality Interfaces
Research Directions for Cross Reality Interfaces
Mark Billinghurst
 
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Chris Swan
 
Choose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presenceChoose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presence
rajancomputerfbd
 
Calgary MuleSoft Meetup APM and IDP .pptx
Calgary MuleSoft Meetup APM and IDP .pptxCalgary MuleSoft Meetup APM and IDP .pptx
Calgary MuleSoft Meetup APM and IDP .pptx
ishalveerrandhawa1
 
How to Build a Profitable IoT Product.pptx
How to Build a Profitable IoT Product.pptxHow to Build a Profitable IoT Product.pptx
How to Build a Profitable IoT Product.pptx
Adam Dunkels
 
How Social Media Hackers Help You to See Your Wife's Message.pdf
How Social Media Hackers Help You to See Your Wife's Message.pdfHow Social Media Hackers Help You to See Your Wife's Message.pdf
How Social Media Hackers Help You to See Your Wife's Message.pdf
HackersList
 
Measuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at TwitterMeasuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at Twitter
ScyllaDB
 
Coordinate Systems in FME 101 - Webinar Slides
Coordinate Systems in FME 101 - Webinar SlidesCoordinate Systems in FME 101 - Webinar Slides
Coordinate Systems in FME 101 - Webinar Slides
Safe Software
 
What’s New in Teams Calling, Meetings and Devices May 2024
What’s New in Teams Calling, Meetings and Devices May 2024What’s New in Teams Calling, Meetings and Devices May 2024
What’s New in Teams Calling, Meetings and Devices May 2024
Stephanie Beckett
 
Best Programming Language for Civil Engineers
Best Programming Language for Civil EngineersBest Programming Language for Civil Engineers
Best Programming Language for Civil Engineers
Awais Yaseen
 

Recently uploaded (20)

Recent Advancements in the NIST-JARVIS Infrastructure
Recent Advancements in the NIST-JARVIS InfrastructureRecent Advancements in the NIST-JARVIS Infrastructure
Recent Advancements in the NIST-JARVIS Infrastructure
 
Transcript: Details of description part II: Describing images in practice - T...
Transcript: Details of description part II: Describing images in practice - T...Transcript: Details of description part II: Describing images in practice - T...
Transcript: Details of description part II: Describing images in practice - T...
 
Advanced Techniques for Cyber Security Analysis and Anomaly Detection
Advanced Techniques for Cyber Security Analysis and Anomaly DetectionAdvanced Techniques for Cyber Security Analysis and Anomaly Detection
Advanced Techniques for Cyber Security Analysis and Anomaly Detection
 
Pigging Solutions Sustainability brochure.pdf
Pigging Solutions Sustainability brochure.pdfPigging Solutions Sustainability brochure.pdf
Pigging Solutions Sustainability brochure.pdf
 
[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf
[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf
[Talk] Moving Beyond Spaghetti Infrastructure [AOTB] 2024-07-04.pdf
 
UiPath Community Day Kraków: Devs4Devs Conference
UiPath Community Day Kraków: Devs4Devs ConferenceUiPath Community Day Kraków: Devs4Devs Conference
UiPath Community Day Kraków: Devs4Devs Conference
 
Details of description part II: Describing images in practice - Tech Forum 2024
Details of description part II: Describing images in practice - Tech Forum 2024Details of description part II: Describing images in practice - Tech Forum 2024
Details of description part II: Describing images in practice - Tech Forum 2024
 
Manual | Product | Research Presentation
Manual | Product | Research PresentationManual | Product | Research Presentation
Manual | Product | Research Presentation
 
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-InTrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
 
How RPA Help in the Transportation and Logistics Industry.pptx
How RPA Help in the Transportation and Logistics Industry.pptxHow RPA Help in the Transportation and Logistics Industry.pptx
How RPA Help in the Transportation and Logistics Industry.pptx
 
Research Directions for Cross Reality Interfaces
Research Directions for Cross Reality InterfacesResearch Directions for Cross Reality Interfaces
Research Directions for Cross Reality Interfaces
 
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
 
Choose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presenceChoose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presence
 
Calgary MuleSoft Meetup APM and IDP .pptx
Calgary MuleSoft Meetup APM and IDP .pptxCalgary MuleSoft Meetup APM and IDP .pptx
Calgary MuleSoft Meetup APM and IDP .pptx
 
How to Build a Profitable IoT Product.pptx
How to Build a Profitable IoT Product.pptxHow to Build a Profitable IoT Product.pptx
How to Build a Profitable IoT Product.pptx
 
How Social Media Hackers Help You to See Your Wife's Message.pdf
How Social Media Hackers Help You to See Your Wife's Message.pdfHow Social Media Hackers Help You to See Your Wife's Message.pdf
How Social Media Hackers Help You to See Your Wife's Message.pdf
 
Measuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at TwitterMeasuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at Twitter
 
Coordinate Systems in FME 101 - Webinar Slides
Coordinate Systems in FME 101 - Webinar SlidesCoordinate Systems in FME 101 - Webinar Slides
Coordinate Systems in FME 101 - Webinar Slides
 
What’s New in Teams Calling, Meetings and Devices May 2024
What’s New in Teams Calling, Meetings and Devices May 2024What’s New in Teams Calling, Meetings and Devices May 2024
What’s New in Teams Calling, Meetings and Devices May 2024
 
Best Programming Language for Civil Engineers
Best Programming Language for Civil EngineersBest Programming Language for Civil Engineers
Best Programming Language for Civil Engineers
 

Autonomous microservices for a Financial System

  • 1. AUTONOMOUS MICROSERVICES FOR A FINANCIAL SYSTEM Jeppe Cramon - @jeppec Chief Architect - INPAY
  • 2. “Inpay’s vision is to transform global trade by making cross-border payments as fast, easy, safe, and cost-efficient as local bank transfers” Jacob Tackmann Thomsen Founder & CEO 2
  • 3. Our development teams main goal: Build a flexible and scalable solution that can grow with the company 3
  • 4. WE WANT TO BE ABLE TO ADAPT TO CHANGES QUICKLY
  • 5. WE ALL WANT TO MOVE FAST But many organization experience that they cannot move fast
  • 6. THE MAIN IMPEDIMENT TO MOVING FAST?
  • 8. It usually starts simple “The” DB UI Logic Data Access
  • 9. And we end up with…
  • 10. Reality rears its ugly head
  • 11. It’s hard to see the sky
  • 12. How to ensure ending up there? Be in a hurry! 12
  • 13. Being in a hurry results in writing bad code Bad code slows us down every time we want to change something 13
  • 14. Bad code is rigid Changing one thing requires you to modify a lot of other code to make the codebase consistent again 14
  • 15. Bad code is fragile 15 When you change a thing you end up breaking something else!
  • 16. Coupling • Coupling is a measure of dependencies: • Efferent coupling – who do you depend on • Afferent coupling – who depends on you • Different aspects on coupling: • Temporal coupling (processing time of Y affects X – if Y is down can X continue?) • Spatial coupling (where on the network are the Y instances and how does X know?) • Behavioral coupling (how much about Y’s behavior does X understand) X Y
  • 17. End result “Nobody is allowed to modify that module!” or “Let’s rewrite!” 17
  • 18. If we want to go fast, then we need to do a good job This means: • Take your time • Study the problem • Work iteratively to refine until you end up at a simple solution 18
  • 19. Microservices promise a solution to our problem Monolith Microservice Microservice Microservice MicroserviceMicroservice Microservice Microservice
  • 20. There’s never time to do it right But there’s always time to do it over 20
  • 21. 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
  • 22. Microservices as an architectural style 22
  • 23. ARCHITECTURE IS ESSENTIAL Because it influences how fast we can respond to changes and what the cost of those changes are
  • 24. What is the right level of coupling? This highly depends on • How likely are things to change • And what parts that change together 24
  • 25. MICROSERVICES TELL US TO ADHERE TO THE SRP Single Responsibility Principle (SRP) – “A Microservice should have one reason – and only one reason – to change”
  • 26. Does your domain model adhere to the SRP?
  • 27. How to create a big entangled domain model? 27
  • 28. Result will be fragmented domain logic Focus on Nouns (Entities) and retrofit Verbs later 28
  • 29. The Verbs capture the intent/task we wish to accomplish – i.e. the use cases 29 A Use case typically involve more than one Entity
  • 30. If we primarily model around nouns/entities we can easily violate the SRP Changes to requirements is likely to require changes to multiple entity classes 30
  • 31. If a change to requirements forces us to “refactor” the structure of your domain model Then it wasn’t a model of the domain! 31
  • 32. A change to requirements should be a “change to how we do business” Not a change to what business we’re in! 32
  • 33. "We don't sell domains, WE SELL USE CASES!" Jim Coplien 33
  • 34. So instead of focusing on Nouns We should focus on Verbs! 34
  • 35. Second reason for big entangled domain models Trying to create a single model to serve everyone 35
  • 36. Every system has Multiple Users with multiple roles Multiple Stakeholders 36
  • 37. It’s very hard to come up with one canonical model that’s good for everybody 37
  • 38. 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.
  • 39. 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
  • 40. 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
  • 41. How can we discover bounded contexts? 41
  • 42. BOUNDED CONTEXT The setting in which a word or a statement appears that determines its meaning 42
  • 43. HOW TO GATHER REQUIREMENTS FROM MANY DIFFERENT STAKEHOLDERS/DEPARTMENTS/SPECIALISTS? Department C Department E Department A Department D Department B
  • 45. Or design by committee?
  • 46. REQUIREMENTS GATHERING TENDS TO FOLLOW THE STEPS OF CLASSICAL OO DESIGN We write use cases and afterwards look for nouns and verbs
  • 48. SO LET’S FIND A FUN AND BETTER WAY TO DO IT
  • 49. Event Storming • Event Storming is a fun way of bringing developers and business experts together and drive your analysis from the outside and quickly explore complex business domains in hours instead of days/weeks.
  • 50. Event Storming • Invented by Alberto Brandolini • See http://ziobrando.blogspot.dk/2013/11/introducing-event-storming.html
  • 51. Event Storming • Invite the right people • people with questions and people with answers. They provide the perfect mix of curiosity and wisdom. • Provide unlimited modeling space
  • 52. Event Storming • Explore the domain starting from Domain/Business Events Event
  • 53. Why Events • Simple semantic and notation • Represent the state transitions • Gives us precision • Easy to grasp by everybody in the room 53
  • 54. Events An Event is non-prescriptive of what should happen in other parts of the system. It leaves this open to the recipients, so that they themselves determine what to do based on occurrence of the event. Events always carry a name in its past-tense form: OrderWasAccepted, OrderHasShipped, CustomerWasReimbursed Other qualities • Immutable, i.e. content cannot be changed • Always carries the ID of the Business Object it relates to • An event can and will typically will be published to multiple consumers. • The publisher of the event does not know who the recipients are • And it doesn’t know what the recipients intend to do with the event “An Event describes something that HAS happened”
  • 55. Why Events • Simple semantic and notation • Represent the state transitions • Gives us precision • Easy to grasp by everybody in the room • Place them along a timeline to visualize the process • An event might be the predecessor or the follower of another one. 55
  • 56. Event Storming • What causes Domain Events? • User Action model it as a Command • External system • Time • Other Domain Events • Documents External Time Command Role Event Event Document
  • 57. Events are often the side effect of Commands A Command is prescriptive of what should happen. This is a stronger form of coupling than Events or Documents. A Command’s primary goal is to capture USER INTENT A Command supports a single usecase and targets a single Business Object Commands always carry a name in its imperative form: CreateOrder, ShipOrder, CancelOrder, ReimburseCustomer, etc. Other qualities • Immutable, i.e. content cannot be changed • Always carries the ID of the Business Object that it relates to • A command can only be handled by ONE service • The Operations that consume Commands don’t return values – but can throw exceptions “A command describes a Task that you want someone else to carry out for you and the recipient can reject the Command”
  • 58. Commands & Events Commands mutate Business Object state which results in one or more Events being published Command Event(s) AcceptOrder OrderAccepted ShipOrder OrderShipped AddComment CommentAdded QuarantineReview ReviewQuarantined UnquarantineReview ReviewUnquarantined
  • 59. Also, UI’s give you valuable input Create Task based UI mockups 59
  • 60. 60
  • 62. When discussing with Business Experts Focus on data fields and NOT entities 62
  • 63. Focus on which data fields clump together (or are talked about together) and what fields are separate Place the fields in piles, that later will become your bounded contexts 63
  • 64. Don’t name the piles before you know what they are This avoids cognitive bias 64
  • 65. Give the piles gibberish or color names 65
  • 67. Towards Bounded Context that are fairly small (but not too small) and rarely need to call each other Sales Pricing InventoryShipping ✕ ✕ ✕ UI BL DAO UI BL DAO UI BL DAO UI BL DAO
  • 68. So where does (micro) services fit into this? 68
  • 69. 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 (including the UI) • It forms a single source of truth for that bounded context
  • 70. 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.
  • 72. SERVICES ARE AUTONOMOUS For a service to be autonomous is must NOT share state
  • 73. SERVICES ARE AUTONOMOUS Autonomy is essential for Scalability (scale out clustering) Reliability (fail over clustering)
  • 74. SERVICES ARE AUTONOMOUS Autonomy is essential for Reusability Adaptability
  • 75. How do we communicate between our services? 75
  • 76. 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
  • 77. But all the cool kids tell us to use REST between (micro)services? 77
  • 79. WHAT’S THE CHALLENGE WITH USING RPC/REST/… BETWEEN SERVICES?
  • 80. 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 80 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
  • 81. Also remember: REST isn’t magic!
  • 82. WITH CROSS SERVICE INTEGRATION WE’RE BOUND BY THE LAWS OF DISTRIBUTED COMPUTING
  • 83. 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
  • 84. A DISTRIBUTED SYSTEM IS ONE WHERE A MACHINE I’VE NEVER HEARD OF CAN CAUSE MY PROGRAM TO FAIL. — Leslie Lamport
  • 85. 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
  • 86. 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
  • 87. 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 • And what about timeouts? • X Phase Commit is fragile by design
  • 88. WE NEED TO CHANGE FOCUS FROM SHORT TECHNICAL TRANSACTIONS To long running business transactions supporting business processes
  • 89. 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…
  • 90. 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
  • 93. 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
  • 94. We need more fine grained building blocks Autonomous Components
  • 95. A Service represents a logical boundary 95 Service Autonomous Component Autonomous Component UI component UI component
  • 96. An Application is the plate where Components are co-deployed 96 Sales service components PSP service components …
  • 97. 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)
  • 98. Service Autonomous Component 1..* Is implemented by A Service is the technical authority of a specific Bounded-Context/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
  • 99. 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
  • 100. 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
  • 101. 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)
  • 102. Services/Bounded Contexts and Aggregates Sales Service PSP Service Virtual Banking Service Customer customerId … Contract contractId customerId … VBFeeSchedule contractId … PSPFeeSchedule contractId … BillingTemplate contractId …
  • 103. CQRS A single model cannot be appropriate for reporting, searching and transactional behavior Greg Young, 2008
  • 104. 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
  • 105. 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
  • 107. Create Contract Sales Service : Contracts_Ac Contract Manager Application PSP Service : Agreement_Ac ContractCreated ContractCreated Publish PayInTemplateCreated ContractEvents <<Topic>>
  • 108. Client handled subscriptions • Highly resilient pattern for an Event Driven Architecture that’s backed by Event- Sourced AC’s • 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 has 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.
  • 109. 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
  • 110. 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
  • 114. 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/
  • 115. 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
  • 116. Screen view != View model Think in composites 116
  • 117. 117
  • 118. 118
  • 119. 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/
  • 120. Composite UI - example Page Context: {id: ISBN-10 0-321-83457-7 } ImageService BookService ReviewService PriceService InventoryService OthersAlsoBoughtService PriceService ReviewService BookService ImageService BookService
  • 121. 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
  • 122. 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
  • 123. 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 api_psp psp_fees_ac psp_contract_manager_adapters frontend api_sales app libs contract customer fees
  • 124. Be pragmatic Some services are more stable In which case we allow other services to call them using local calls 124
  • 125. 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 ApplicationIdentifier getApplicationIdentifier() { return ApplicationIdentifier.from("ContractManager"); } @Override protected Collection<AutonomousComponent> getAutonomousComponentsHostedInThisApplication() { CurrencyExchangeRateAc currencyExchangeRateAc = new CurrencyExchangeRateAc(); return list( new PSPFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()), new VBFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()), new ContractAc(), new CustomersAc(), currencyExchangeRateAc ); } public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
  • 126. 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; } }
  • 127. AC, autonomy and “shared” service data Service DB DB Autonomous Component Autonomous Component Autonomous Component Autonomous Component DB
  • 128. 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!
  • 129. 5 Microservices Do’s • Identify Business Capabilities (or Bounded Contexts) and split your services according to them. A service is owned by one team that builds and runs the service. This gives you proper business and IT alignment and allows pin point accuracy with regards to spending money to solve problems. • Spend time to understand the business processes and the domain. At first you must go slow to go fast. Building microservices properly takes time and is not trivial. Identify how likely things are to change and what things change together. • Focus on the business side effects - also know as the Events and make them a first class principle. Avoid RPC/REST/Request-Response between Services - events are the API. • Consider building composite application and Backend’s For Frontend's (BFF’s) to decouple services further. An application is owned by a dedicated team, but may borrow developers from service teams. • Learn from history. Don’t repeat the mistakes that gave (misapplied) SOA a bad name. Also, microservice might not be as small as you think - we need low coupling as well as high cohesion :)
  • 130. 5 Microservices Don’ts • Do not introduce a network boundary as an excuse to write better code - many have troubles with poorly modularized monoliths and believe that introducing network between modules magically solves the problem. If you don’t change your thinking and design, you will end up with a distributed monolith, which has all the disadvantages of a monolith, the disadvantages of a distributed system and none of the advantages of microservices • Don't split the atom! Distributed Transactions are never easy. Learn about the CAP theorem and avoid Request/Response API’s between Services. • Don't fall into the trap of “Not my problem”. When working on isolated code bases teams can loose sight of the big picture. • Identify the bottlenecks and possible solutions before deciding to split a problem into one or more microservices. There’s nothing the guarantees that your microservice scales better than your monolith. • Don't do big bang rewrites. Move towards microservices gradually while focusing on functional areas that can replace or support the old monolith. Don’t rewrite core business while being new to microservices.