Heb je ook een onderbuik gevoel dat er iets mis is als mensen praten over microservices? Alsof je verplicht bent services te bouwen van hooguit enkele regels code, die expliciet autonoom en los inzetbaar zijn, en altijd via REST moeten communiceren? Iedereen zegt dat je deployment goed op orde moet hebben, omdat dit anders een nachtmerrie wordt, maar niemand geeft een oplossing. In deze sessie geven we je een andere kijk op microservices en hoe je dit ook kunt implementeren binnen je bestaande architectuur.

1. in a Microservices Architecture
Dennis van der Stelt
Software Architect

2. v a n d e r s t e l t
2
Your presenter
Dennis van der Stelt
http://dennis.bloggingabout.net/
Software Architect
About Dennis
Innovative software architect
Almost 20 years of experience in development of
distributed systems. Has a continuous drive to
learn and improve knowledge in different
architectural styles, including quality in software
development. Highly motivated to share his
knowledge 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 / Betabit
Reliable systems using messaging

3. v a n d e r s t e l t
3
Agenda
In 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

4. 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

5. v a n d e r s t e l t
5
Microservices
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 explicit
services are autonomous
share schema & contract, not classes
compatibility is based on policy

6. v a n d e r s t e l t
Monolithic application 6
single deployment unit

7. v a n d e r s t e l t
Microservices 7
multiple deployable services

8. v a n d e r s t e l t
Authentication
8
Coupling
OSS
ViewModel
Change
Product
Database
Razor

9. 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

10. v a n d e r s t e l t
10
Monolithic application problems
Problem Analysis
of all monolithic systems are build
with high time constraints, resulting
in big balls of mud in which no
developer can find their way.
42%
Maintenance
The coupling makes it hard to change anything
Documentation
Cost to add new features
Building the 100th feature as fast as the 1st
Project Ownership

11. v a n d e r s t e l t
Monolithic application 11

12. v a n d e r s t e l t
12

13. 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

14. BOUNDED CONTEXTDividing your system’s business logic over logical boundaries

15. v a n d e r s t e l t
15
Microservices architecture
Deployment
Don’t necessarily need to
separately deploy every
single service
Bounded Context
Define boundaries around
logical business processes
Monitoring
Document message flows
and monitor them with
great tools
Messaging
Asynchronous communication
via messaging &
publish/subscribe

16. 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

17. v a n d e r s t e l t
Service boundaries 17
Shipping
FinanceSales
Marketing

18. v a n d e r s t e l t
Deployment 18
Shipping
FinanceSales
Marketing
SQL
SQL
{ }

19. v a n d e r s t e l t
Architectural style 19
Shipping
FinanceSales
Marketing
CQRS
Event Sourcing
CRUD
there is no
top level
architecture

20. v a n d e r s t e l t
Coupling aspects 20
SpatialTemporalPlatform

21. 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".

22. v a n d e r s t e l t
22

23. v a n d e r s t e l t
Messaging
23
Shipping
FinanceSales
Marketing
SQL

24. v a n d e r s t e l t
Messaging
24
Shipping
FinanceSales
Marketing
SQL

25. v a n d e r s t e l t
Messaging
25
Shipping
FinanceSales
Marketing
SQL
Publish / Subscribe

26. 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
“
”

27. v a n d e r s t e l t
27
Resume
Service Boundaries
Try to see if your organizational communication
structure can be the model for your logical service
boundaries.
Messaging
Avoid RPC style communication between services.
Use messaging with an event driven architecture.
Deployment
Don’t necessarily see every microservice as a
deployable unit. Do keep an eye out for coupling.
Avoid joins in your database between entities.

28. DUPLICATION vs REPLICATIONWhy you shouldn’t duplicate, but replicate data

29. 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

30. v a n d e r s t e l t
30
Duplicating data
What event just took place
business process related
events that other services
require to properly function
and take action on
Status changes Identifiers Date Time Info
Who was the subject
the triggered event has a
specific subject in our domain
When does the status expire
when status updates expire or
are no longer relevant at a
point in time, we provide
expiration information

31. v a n d e r s t e l t
Sales
Messaging 31
Taxi
Customers
TaxiRequested
TaxiRequested
RequestTaxi

32. v a n d e r s t e l t
Sales
Messaging 32
Taxi
TaxiRequested
RequestTaxi
Finance
TaxiAssigned
Customers

33. v a n d e r s t e l t
Sales
Messaging 33
Taxi
RequestCancelled
Finance
RequestCancelled
CancelRequest

34. v a n d e r s t e l t
34
Replicating vs Duplicating data
So duplication of
data is not good But what about this
replicating data?

35. v a n d e r s t e l t
35
Replicating 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

36. v a n d e r s t e l t
36
Replicating 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

37. v a n d e r s t e l t
37
Composite UI; little micro views
Sales
Lists requests made by
customer
Customer
Displays customer
information such as name
and current location
Taxi
Shows where taxi drivers
are and at what time they
arrive at your location
Finance
Displays status of all
financial transactions and
outstanding bills

38. IMPLEMENTINGinto your own system

39. 39
Implementation
Find edge cases
New features that are added (not
integrated) into your system
Publish messages to it
Start using messaging and
publish/subscribe for communication
Add small databases
Do not integrate into your big ball of
mud database; keep it seperate
Pay attention to logical boundaries
A service is the technical authority of
a specific business capability

40. MONITORINGyour services

41. v a n d e r s t e l t
41
Monitoring

42. v a n d e r s t e l t
42
Monitoring

43. v a n d e r s t e l t
43
Monitoring

44. v a n d e r s t e l t
44
Resume; how we build microservices
Define Boundaries
Define boundaries of your services. Your organizational
structure may help. Do not duplicate data across services.
Share status changes, identifiers and date-times.
Implement
Implement your microservices that handle a single task.
Use publish/subscribe to notify other services with status
changes.
Composite UI
Everything from data up until the user interface should
belong in a service, resulting in a composite ui that
retrieves data based on the mentioned identifiers.
Deploy
Deploy your microservices, but not necessarily as single
units. A possibility is a deployment unit per service
boundary.

45. 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

46. v a n d e r s t e l t
46

47. v a n d e r s t e l t
48
Contact Me
Address
Rotterdam, The Netherlands
Email
dennis@bloggingabout.net
Twitter
@dvdstelt
Website
http://dennis.bloggingabout.net
Thank you for your time…