Slides for my architectural session at the event: Docker From Zero To Hero. We talked about what kind of expertises are need in order to build a true Microservices Solution; you'll need to understand some of the fundamentals on which Microservices is built upon: SOA, EDA and DDD just to name a few, then you can move to the container world. Original event link: https://www.eventbrite.it/e/biglietti-docker-from-zero-to-hero-83372825365#

1. Microservices
Alessandro Giorgetti
www.primordialcode.com

2. Microservices
“If you are looking for a technical solution
for what it is a business problem,
you are looking the wrong way.”

3. The monolithic software weak points
oArchitecture/Solution is hard to evolve.
oDifficult to Scale.
oLong development pipeline (build, test, release).
oAdding a feature takes time.
oA lot of time between releases.
oContinous Delivery is challenging.

4. Microservices definition
Microservices is an architectural design for building a
distributed application using containers.

5. Microservices a «better» definition
Microservices is an “architectural style” for building a
distributed application as a collection of small and
loosely coupled services
(each service implementing a business capability).
Services should have the following properties…

6. Microservices «properties»:
•Autonomy.
•Small and Focused on a single «thing».
•Independent Development: the right tools for the right job!
•Independent Deployment.
•Independent Scalability.

7. Microservices «properties»:
•Reusable (through composition).
•Owned by a small team.
•Designed for Failure / No single point of failure: the system
can “degrade”, but it should never be fully down.
•Promotes the adoptions of new technologies.

8. Microservices promise to be like:
The Monolith
(the big ball of mud)
Service 1
Service 3
Website
Service 4
APP
Service 7 Service 6
Service 5
Service 8
Service
10
Service 2
Service 9

9. Microservices leads to Reactive Systems
https://www.reactivemanifesto.org/
Loosely Coupled
Loose coupling through
async message passing
Resilient
Error containment
Fault tolerance and recovery
Elastic
Scalability
React to workload change
Responsive
Rapid and consistent response times
A Reactive System is made of services and components that have the following properties:

10. Microservices «pain points»
•Increased complexity for developers.
•Increased complexity for operators.
•Increased complexity for devops (ALM madness!).
•It requires serious expertise.
•Unclear or not well defined Service Boundaries.
•(Distributed) State management ?

11. Microservices «pain points»
•Versioning.
•Communications issues.
•Distributed Transactions: Can they be avoided? At which cost?
•Performances: many services with many «dependencies» = many network calls!
•Managing and «orchestration»: logging, monitoring, discovery, etc...
•Debugging.

12. Distributed computing is hard!
The fallacies of distributed computing:
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.
And we always underestimate:
1. Error Handling, Failures and Recovery.
2. Performance and Bottlenecks.
3. Blocking operations.
4. Concurrency.
5. Consistency.
6. State Management / Locks / Threads.
7. Parallelism.
8. Availability.

13. The Microservices thing can become…
Service 3 Service 4
APP
Service 7
Service 6
Service 5 Service 8
Service
10
Service 9
Service 1
Service 3
Website
Service 4
APP
Service 7 Service 6
Service 5
Service 8
Service
10
Service
11
Service 9

14. Microservices fundamentals
Service Oriented Architecture
• Ownership of data and behavior.
• Autonomy.
• And more…
Domain Driven Design
• Bounded Context.
• Aggregate.
• Events.
Event Driven Architecture
• Loose coupling.
Patterns & Practices

15. The first thing that comes in mind when
thinking about «architecture»!

16. You cannot fight the «Coupling»!

17. A long time ago
in a galaxy far, far away…. SOA
Service Oriented Architecture
A service is a technical authority for a business capability.
Any piece of data or rule must be owned by only one service.
http://www.soa-manifesto.org/
https://www.infoq.com/articles/tilkov-10-soa-principles https://en.wikipedia.org/wiki/Service-orientation_design_principles

18. SOA Elements
https://en.wikipedia.org/wiki/Service-oriented_architecture
Web Services

19. SOA Service: a definition (sort of)
We can define a service by its fundamentals / principles (the four tenets):
oServices are autonomous.
oServices have well defined boundaries.
oServices share contracts and schema.
oServices interactions are controlled by policies.
A Service provide the implementation for a specific Business Capability!
http://www.dbizinstitute.org/resources/articles/four-tenets-service-orientation

20. SOA: «decouple» the different business
capabilities… in «services»!
We might end up with something like this: slices of a layered architecture!
Each slice representing a capability of the system!
They are Autonomous and Loosely Coupled!
Product Catalog Sales Shipping
Infrastructure
logging, communication, …

21. The major problems of SOA:
oServices could be «very big» (monolithic services).
oToo much tied to a specific technology (Web Services, ESB).
oIf done wrong we’ll end up having tight coupling with one service directly
calling into another.
(welcome the distributed monolith… with latency and reliability problems).

22. MicroServices: SOA vNext
Microservices is a variant of SOA that structures an application as a collection of loosely
coupled services. Services should be fine-grained and the communication protocols should be
lightweight.
Another Microservices Definition:
Microservices is an “architectural style” for building a
distributed application as a collection of small and loosely
coupled services.
A service is a technical authority for a business capability. Any
piece of data or rule must be owned by only one service.

23. MicroServices: SOA vNext
From an “operative” standpoint:
Small, independent applications, loosely coupled,
communicating (asynchronously) with each other, and can
fail independently, and if one or some fails, the system as a
whole still works (the functionality might be downgraded).

24. How is it different from SOA ?
•Tries to reduce the size of services: Small services with a single focus.
•Promotes the usage of technology agnostic APIs.
• Services can be consumed by other services written in different technologies.
•Promotes the usage of independent data storage (for each service).
•Promotes the usage of lightweight communication protocols.
•Puts the emphasis on loose coupling even more.
•Improves the scalability.
•Improve the flexibility.

25. Microservices goes further!
Product Catalog Sales Shipping
Infrastructure
P.C. Service 1
P.C. Service 3 P.C. Service 4
P.C. Service 5 P.C. Service N
P.C. Service 2 S. Service 1 S. Service 2
S. Service 5 S. Service N
S. Service 3 S. Service 4
Sales Service 1 Sales Service 2
Sales Service 3 Sales Service 4
Sales Service 5 Sales Service N

26. How to «discover» the
Services?
DDD TO THE RESCUE

27. Finding out what’s inside a service
We need logical view of the system. Some practices worked very well (for us):
oDDD (Domain Driven Design).
oEvent Storming.

28. Domain Driven Design
An approach to software development for «complex systems»
that works promoting the adoption of an evolving domain model,
that derives from a collaboration between developers and domain experts
to iteratively refine a conceptual model that addresses particular domain
problems.

29. DDD key concepts
Ubiquitous Language - the language used by domain experts and
developers that defines elements/processes of the business.
Events (and Commands) – facts, evidences that something happened in
the business.
Aggregate – a cluster of domain objects that represent a single
(transactional) unit, it supports the business providing behavior and rules.
Bounded Context - the “environment” in which a specific Ubiquitous
Language is valid.
Context-Map – shows the interactions between Bounded-Contexts.

30. Event Storming – talk the (ubiquitous)
language of the business!
«Tool / Workshop» that allows to quickly explore complex business domains.
You can figure out how the system works (how much in detail it is up to you);
you’ll also get an overrall idea of the «shape» of the system.

31. Aggregate
An Aggregate encapsulates state and behavior.
An Aggregate guarantees that Business Rules are satisfied.
An Aggregate is a «Transactional» and «Computational» Unit.
An aggregate accepts Commands and emits Events, Event
represents Business Transactions outcome.
A DDD aggregate is a cluster of domain objects that can be
treated as a single unit.
Aggregate
Cmd(s) Evt(s)
Cmd(s) Evt(s)
Evt(s)

32. Bounded Contexts
Catalog
Aggregate(s)
Cmd(s) Evt(s)
Catalog
Aggregate(s)
Cmd(s) Evt(s)
Catalog
Aggregate(s)
Cmd(s) Evt(s)
Sales
Aggregate(s)
Cmd(s) Evt(s)
Catalog
Aggregate(s)
Cmd(s) Evt(s)
Shipping
Aggregate(s)
Cmd(s) Evt(s)
Catalog
Bounded Context
Sales
Bounded Context
Shipping
Bounded Context

33. Context Map
Context Maps draw the relationships between the Bounded Contexts, they are:
oConformist relationship: the downstream context might follow and adapt to what the upstream context says.
oPartnership relationships (both context work towards a common goal; the same term might exists in multiple contexts with different behaviors).
oTechnical relationships (how they talk).
A system will almost never be made of a single bounded context, BCs operate toghether to fulfill the system requirements and implement business capabilities.
BC 1
BC 3 BC 4
BC 2
External System
https://www.infoq.com/articles/ddd-contextmapping

34. Bounded Contexts
oThey are Autonomous / have Explicit Boundaries: encapsulation, they «contain» everything
that’s needed to implement a business capability.
oThey share contract and schema: that’s a «communication protocol».
BC 1
BC 3 BC 4
BC 2
External SystemBC 1
BC 3 BC 4
BC 2
External System

35. Bounded Contexts  SOA Services
oThey are Autonomous / have Explicit Boundaries: encapsulation, they «contain» everything
that’s needed to implement a business capability.
oThey share contract and schema: that’s a «communication protocol».
BC 1
BC 3 BC 4
BC 2
External System
Service 1
Service 3 Service 4
Service 2
External System

36. How do Services talk?
REDUCING COUPLING IS THE KEY!

37. How do these Services communicate?
You can still have coupling!!!
Shopping Cart
Sales
bool placeOrder(id, items)
Process 1
Shopping Cart
Sales
bool placeOrder(id, items)
In-Process
Process 2
H
T
T
P

38. BTW… This is coupling too!!!
Process 1
Shopping Cart Sales
Process 2
The Database
The
Table

39. How do services talk ?
o(SYNC) RPC and the likes.
o(ASYNC) Messaging.

40. RPC
and the likes: gRPC, Web Services, anything over TCP, HTTP and so on…
In distributed computing, a remote procedure call (RPC) is
an Inter-process communication technology that allows a
computer program to causes a procedure (subroutine) to
execute in a different address space (commonly another
process on another computer on a shared network).
https://en.wikipedia.org/wiki/Remote_procedure_call

41. RPC (underlying concepts)
Location Transparency: the function call is coded as if it were a normal
(local) procedure call, without the programmer explicitly coding the
details for the remote interaction.
RPC is typically implemented via a (blocking) request – response message-
passing system.
Remote calls are usually slower and less reliable than local calls.

42. Messaging
Message: an immutable data structure
used to exchange a piece of information.

43. Why Messages are so important?
They have properties that open up many scenarios:
•Asynchronous Communication.
•Can be serialized and stored (debugging, event sourcing).
•Can be ordered (priority, deferred elaboration).
•Carry metadata / context information (like a reply-to).
•Can be forwarded.
•Can be broadcasted.

44. Messaging Patterns
Service ServiceOne Way
Service ServiceBroadcast
Service
Service

45. Messaging Patterns
Service ServiceProxy
Service ServicePub/Sub
Service
Service
Service
forward
subscribe
publish

46. Message Delivery Patterns
•at-most-once: for each message handed to the mechanism, that message is delivered zero or
one times; the messages may be lost.
•at-least-once: for each message handed to the mechanism potentially multiple attempts are
made at delivering it, until at least one succeeds; the messages may be duplicated but not lost.
•exactly-once: for each message handed to the mechanism exactly one delivery is made to the
recipient; the message can neither be lost nor duplicated.

47. Event Driven Architecture
•Event Producers: generate streams of events.
•Event Consumers: listen to events.
Producers are decoupled from consumers: a producer doesn't know which consumers are
listening. Consumers are also decoupled from each other.
Every Consumer can potentially see all the events / messages.
Event Producer
Event Consumer
Event Consumer
Event Streaming
Infrastructure

48. Event Driven Architecture
Can use two communication models:
•Pub/sub: the messaging infrastructure keeps track of subscriptions. After an
event is received, it cannot be replayed, and new subscribers do not see past
events.
•Event streaming: events are written to a durable log. Events are strictly ordered
within a partition. Consumers don't subscribe to the stream, instead a consumer
can read from any part of the stream. The consumer is responsible for advancing
its position in the stream.

49. Logical Architecture
vs.
Physical Architecture

50. A Microservice in a Distributed App.
OWNS and PROTECTS data and behavior… it’s responsible for their exposure to
the rest of the system.
Ideally, everything that «belongs» to a service is managed by the service itself:
oFrom the Databases  to the Backend  to the UI components (widgets).
oThe Team responsible for the service should have expertise in all the areas.

51. A Service spans multiple «technologies»
and «responsibilities»
Product Catalog Sales Logistics
Backend
( .net / java / go / … )
Web Portal
( web api / html /
javascript / …)
Mobile Apps
( .net / xamarin / swift /
… )
Microservices is also for scaling People!
Not only the Deployment Unit(s)!
Team 1
Team 1
Team 1
Team 2
Team 2
Team 2
Team 3
Team 3
Team 3

52. When it comes to the physical view…
A service is a composition of components and smaller
«services»… that collaborate to implement a specific business
capability!!
The term service is «overloaded» and has slightly different properties:
oA service, in this context, is a support entity for other components in order to fulfill very specific
tasks.
oMight not be fully autonomous.
oThere will be coupling, a lot of coupling… there will be cohesion!

53. Microservices «Physical View»:
composition of components & services
Web Crawler
(stateful)
Crawling Job Coordinator 1
(stateful)
Parser 1
(stateless)
Downloader 1
(stateless)
Analyzer 1
(stateless)
Parser n
(stateless)
Downloader n
(stateless)
Analyzer n
(stateless)
Crawling Job Coordinator n
(stateful)
Parser 1
(stateless)
Downloader 1
(stateless)
Analyzer 1
(stateless)
Parser n
(stateless)
Downloader n
(stateless)
Analyzer n
(stateless)

54. How do we «code» each Service /
Bounded Context?
Inside a Microservice we can follow any architectural style we want!
They are «small» and «autonomous» and «easily replaceable»!
(Given we respect the communication protocol contracts).

55. Multi-Tier Layered Architecture

56. CQRS / ES (Aggregate  Domain Object)

57. We can also consider tools designed to
help us build distributed applications
Akka (https://akka.io) & Akka.NET (https://getakka.net/)
Microsoft Orleans (https://dotnet.github.io/orleans/)
Dapr - Distributed Application Runtime (https://dapr.io/)

58. Chosing the «communication protocols»
at the highest level of the system
Product Catalog
Service
Inventory
Service
Account
Service
Sales
Service
Shipping
Service
Whatever
Service
My favorites:
• Event Streams.
• Enterprise Service Bus.
• Independent Queues.
Less favorites:
• Lightweight RPC (gRPC /
WebServices).
Event Streams / ESB

59. Communications «within» a Microservice
If our Microservice can be made of a subset of cohesive
sub-services:
•Few stateful services.
•Many stateless services.
We can deploy them on several machines (cluster), how
do they communicate?
My Favorites:
•RPC.
•Async Messaging.
Crawling Job Coordinator 1
(stateful)
Parser 1
(stateless)
Downloader 1
(stateless)
Analyzer 1
(stateless)
Parser n
(stateless)
Downloader n
(stateless)
Analyzer n
(stateless)

60. Microservices + API Gateway +
Monolithic UI
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout

61. Microservices + UI Composition
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout

62. Microservices Lifecycle Management ?
Microservices are biased towards organizations with multiple teams.
oBest practices as Continous Integration / Continous Deployment should be encouraged.
oMultiple backlogs (Agile, SCRUM, Kanban, etc…) ?
oMultiple Repositories ?
oMultiple Deployment tools & Deployment Strategies ?

63. So we have all our nice Microservices…
How do we package them?
How do we deploy them?
How do we orchestrate & manage them?
How do we monitor them?
How do we handle failing microservices?

64. Resources – Distributed Applications
•Designing Data-Intensive Applications
https://www.amazon.it/Designing-Data-Intensive-Applications-Reliable-
Maintainable/dp/1449373321
•Designing Distributed Systems
https://www.amazon.it/Designing-Distributed-Systems-Patterns-Paradigms/dp/1491983647

65. Resources - Microservices
•Microservices.io
https://microservices.io/
•Building Microservices
https://www.amazon.it/Building-Microservices-Sam-Newman/dp/1491950358
•.NET Architecture Guides
https://dotnet.microsoft.com/learn/dotnet/architecture-guides
•.NET Microservices Architecture Guidance
https://dotnet.microsoft.com/learn/aspnet/microservices-architecture
•.NET Microservices: Architecture for Containerized .NET Applications
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/

66. Resources – DDD
•Domain Driven Design
https://www.amazon.it/Domain-Driven-Design-Tackling-Complexity-Software-
ebook/dp/B00794TAUG/
•Implementing Domain Driven Design
https://www.amazon.it/Implementing-Domain-Driven-Design-English-Vaughn-
ebook/dp/B00BCLEBN8
•Strategic Domain Driven Design with Context Mapping
https://www.infoq.com/articles/ddd-contextmapping/

67. Resources – Reactive Applications
•Reactive Design Patterns
https://www.amazon.it/Reactive-Design-Patterns-Roland-Kuhn/dp/1617291803/
•Reactive Messaging Patterns with the Actor Model
https://www.amazon.it/dp/B011S8YC5G

68. Keep in touch
Dott.ing. Alessandro Giorgetti
Facebook: https://www.facebook.com/giorgetti.alessandro
Twitter: @a_giorgetti
LinkedIn: https://it.linkedin.com/in/giorgettialessandro
E-mail: alessandro.giorgetti@live.com
Blog: www.primordialcode.com
Alessandro Giorgetti
www.primordialcode.com