Post on 14-Apr-2017
transcript
v a n d e r s t e l t
2Your presenter
Dennis van der Stelt
http://dennis.bloggingabout.net/
Software Architect
About Dennis
Innovative software architect
Almost 20 years of experience in development ofdistributed systems. Has a continuous drive tolearn and improve knowledge in differentarchitectural styles, including quality in softwaredevelopment. Highly motivated to share hisknowledge via articles, presentations and his blog.
Awards
NServiceBus Champ
Typemock MVP
Certified Trainer
Professional Services
Provides coaching & training
• Presentations
• Software & Architecture audits
• SOA & Microservices advice
• Unit Testing training
• NServiceBus training
Presentations
October 15th at Blaak Selectie / BetabitReliable systems using messaging
v a n d e r s t e l t
3
AgendaIn a polyglot architectural landscape with a lot of business logic, data and information, how can we build solid loosely coupled systems?
Let’s have a look at the differences between those opposites
Monolithic vs Microservices
Dividing your system’s business logic over logical boundaries
Service Boundaries
Why duplicating data is a bad practice, but replicating data is perfectly fine
Replicating vs Duplicating
v a n d e r s t e l t
Monolithic application
Wikipedia : large, powerful, and intractably indivisible and uniform.
A monolithic application is build and deployed as a single unit.
WordPress is a successful & scalable monolithic application used by millions!
Monolith is therefor not by default a badly designed system
4
v a n d e r s t e l t
5Microservices
a software architectural style for complex applications of small, independent processes.
services are small, highly decoupled and focus on a single task
communicate via language agnostic APIs
boundaries are explicitservices are autonomous
share schema & contract, not classescompatibility is based on policy
v a n d e r s t e l t
9
First law
“My First Law of Distributed Object Design: Don't distribute your objects”
Martin Fowler in Patterns of Enterprise Application Architecture
v a n d e r s t e l t
10Monolithic application problems
Problem Analysis
of all monolithic systems are buildwith high time constraints, resultingin big balls of mud in which nodeveloper can find their way.
42%
MaintenanceThe coupling makes it hard to change anything
Documentation
Cost to add new featuresBuilding the 100th feature as fast as the 1st
Project Ownership
v a n d e r s t e l t
13
Microservices“don't even consider microservices unless you have a system that's too complex to manage as a monolith”
Martin Fowler
v a n d e r s t e l t
15Microservices architecture
DeploymentDon’t necessarily need to separately deploy every single service
Bounded ContextDefine boundaries around logical business processes
MonitoringDocument message flows and monitor them with great tools
MessagingAsynchronous communication
via messaging & publish/subscribe
v a n d e r s t e l t
Any organization that designs a system will produce a design whose structure is a
copy of the organization's communication structure.“
”Conway’s law – 1968
v a n d e r s t e l t
Architectural style 19
Ship
pin
gFin
ance
Sale
sM
arketing
CQRS
Event SourcingCRUD
there is no
top level
architecture
v a n d e r s t e l t
21
-Alan Kay-Creator of SmallTalk, Adjunct Professor at MIT & University of California
At Utah sometime after Nov 66 when, influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my
background in Biology and Mathematics, I thought of an architecture for programming. It was probably in 1967 when someone asked me
what I was doing, and I said: "It's object-oriented programming".
v a n d e r s t e l t
26
Messaging
Handle business events through
Inversion of communication
by supplementing SOA with EDA
“”
v a n d e r s t e l t
27Resume
Service BoundariesTry to see if your organizational communication structure can be the model for your logical service boundaries.
MessagingAvoid RPC style communication between services. Use messaging with an event driven architecture.
DeploymentDon’t necessarily see every microservice as a deployable unit. Do keep an eye out for coupling. Avoid joins in your database between entities.
v a n d e r s t e l t
29
Do not duplicate
across service boundaries
You can share…
some information
Publish / Subscribe
to notify in advance
v a n d e r s t e l t
30Duplicating data
What event just took placebusiness process related
events that other services require to properly function
and take action on
Status changes Identifiers Date Time Info
Who was the subjectthe triggered event has a
specific subject in our domain
When does the status expirewhen status updates expire or
are no longer relevant at a point in time, we provide
expiration information
v a n d e r s t e l t
Sales
Messaging 32
TaxiTaxiRequested
RequestTaxi
FinanceTaxiAssigned
Customers
v a n d e r s t e l t
Sales
Messaging 33
TaxiRequestCancelled
Finance
RequestCancelled
CancelRequest
v a n d e r s t e l t
34Replicating vs Duplicating data
So duplication of data is not good But what about this
replicating data?
v a n d e r s t e l t
35Replicating vs Duplicating data
So duplication of data is not good But what about this
replicating data?
Replicating within a service boundary is okay
for performance or connectivity issues
v a n d e r s t e l t
36Replicating data options
Performance optimization
Suitable for all categories business and personal presentation
In memory cache
Prepare for optimal querying
Prepare data for querying, for example into a specific readmodel / viewmodel
Resolve latency issues
Replicating data across physical machines does not break service boundaries
Resolve network issues
Different sites across the globe, or a moving site without connection,
like a large container ship
Viewmodels
Different machines
Different sites
v a n d e r s t e l t
37Composite UI; little micro views
SalesLists requests made by
customer
CustomerDisplays customer information such as name and current location
TaxiShows where taxi drivers are and at what time they arrive at your location
FinanceDisplays status of all
financial transactions and outstanding bills
39
Implementation
Find edge casesNew features that are added (not
integrated) into your system
Publish messages to itStart using messaging and
publish/subscribe for communication
Add small databasesDo not integrate into your big ball of
mud database; keep it seperate
Pay attention to logical boundariesA service is the technical authority of
a specific business capability
v a n d e r s t e l t
44Resume; how we build microservices
Define BoundariesDefine boundaries of your services. Your organizationalstructure may help. Do not duplicate data across services.Share status changes, identifiers and date-times.
ImplementImplement your microservices that handle a single task.Use publish/subscribe to notify other services with statuschanges.
Composite UIEverything from data up until the user interface shouldbelong in a service, resulting in a composite ui thatretrieves data based on the mentioned identifiers.
DeployDeploy your microservices, but not necessarily as singleunits. A possibility is a deployment unit per serviceboundary.
v a n d e r s t e l t
45
Microservices can be hard to build, deploy & monitor. Get help from people with experience
Think about temporal coupling between services and how to solve this, possibly with messaging
Do not duplicate data between services, as at some point business logic will follow
Conclusion