1. Let’s talk about…
Microservices
Alessandro Giorgetti
www.primordialcode.com

2. “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 is hard to evolve.
oDifficult to Scale.
oLong development pipeline
(build, test, release)
oAdding a feature can take time.
oA lot of time between releases.
oContinous Delivery is challenging.

4. What is a Microservice ?
Microservice

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

6. Microservices «benefits»:
•Autonomy.
•Independent Development: the right tools for the right job!
•Independent Deployment.
•Independent Scalability.
•Reusability (through composition).

7. Microservices «benefits»:
•A single service is entirely managed by a single team.
•Teams & People scalability.
•No single point of failure: the system can “degrade”, but it
should never be fully down.
•Promotes the adoptions of new technologies.

8. 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 components that have the following properties:

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

10. 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»: service monitoring, gateways, discovery, logging,
etc...
•Debugging.

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

12. The Microservices thing can become…
Service 1
Service 3
Website
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

13. Is it so dramatic?
The true biggest problem of Microservices is not a technical one!
Many of the «problems» are caused by:
misunderstanding, not knowing or not using concepts from:
SOA, EDAand DDD, + some implementation & communication patterns.
Before jumping the Microservices bandwagon it’s better to know some of the “fundamentals”
that will help you build a proper Microservices-enabled Ecosystem.

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

15. This is how we used to think about
services: a layered architecture!

17. You cannot fight the «Coupling»!

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

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

20. 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.
All of this to provide the implementation for a specific Business Capability!
http://www.dbizinstitute.org/resources/articles/four-tenets-service-orientation

21. So… what is the SOA solution to this ?

23. SOA: isolate the different business
capabilities… in services
We might end up with something like this: slices of our layered architecture!
Each slice representing a capability of the system!
They are Autonomous and Loosely Coupled!
Product Catalog Shopping Cart Order Management
Infrastructure
logging, communication, …

24. You can still have coupling!!!
Shopping Cart
Order Management
bool placeOrder(id, items)
Process 1
Shopping Cart
Order Management
bool placeOrder(id, items)
In-Process
Process 2
H
T
T
P

25. BTW… This is coupling too!!!
Process 1
Shopping Cart Order Management
Process 2
The Database
The
Table

26. The major problems of SOA:
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).

27. Welcome «Micro-Services»: SOA 2.0
Microservices is a variant of the service-oriented architecture (SOA) architectural style that
structures an application as a collection of loosely coupled services.
In a microservices based system, services should be fine-grained and the protocols should be
lightweight.
Small, independent applications, loosely coupled, communicating with each other in an
asynchronous manner, and can fail independently, and if one or some fails, the system as a
whole still works, though the functionality might be downgraded when there are failures.

28. Why Loose Coupling?
We should reduce the coupling between the services in order to:
oAllow for independent evolution of each service (development / deployment).
oMake it easier to scale out part of the System.
oLimit the friction between the services.
oExchange information between services implemented with different technologies.
Design the communication protocol around «messages»:
Message/Event Driven Architecture.

29. Finding out what’s inside a service
Build a logical view of the system. Some practices proven to work very well (for us):
oDDD (Domain Driven Design).
oEvent Storming.

30. 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.
Key concepts:
oUbiquitous language.
oBounded contexts.
oContext maps.
oAggregates / Commands / Events (Messages).

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

32. Event Storming
«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.

33. Bounded Contexts
oUbiquitous Language: the language defined between users and developers that defines elements of the business.
oAggregates: clusters of objects that can be treated as a transactional and processing unit.
oBounded Context: the environment in which a specific Ubiquitous Language is valid.
o Each Bounded Context defines a «business boundary»  technical boundaries and other things follows.
BC 1
Aggregate(s)
Cmd(s) Evt(s)
BC n
Aggregate(s)
Cmd(s) Evt(s)
Msg(s)
Msg(s)

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

35. Domain Driven Design
DDD promotes breaking the system into autonomous pieces
that collaborate to implement the business rules.
We used to have a magical word for these pieces!

36. Bounded Contexts are…
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

37. Bounded Contexts are similar to 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

38. How do they talk ?
o(SYNC) RPC and the likes.
o(ASYNC) Messaging.

39. RPC
and the likes: 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

40. RPC
Location Transparency: it 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.

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

42. 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 and delegated.
•Can be broadcasted.

43. Messaging Patterns
Service ServiceOne Way
Service ServiceBroadcast
Service
Service

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

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

46. DDD + EDA + SOA = Microservices
SOA + EDA enables us to have a system where loosely coupled
services do not directly talk to each other, but rather employ a
message based style of communication.
With DDD we gain greater knowledge of service boundaries
(bounded contexts), business logic and data ownership and
encapsulation.

47. DDD + EDA + SOA = Microservices
DDD Aggregates define the transactional consistency boundary and
limit the scope and size of the implementation.
This is where a Microservice (or a set of Microservices) starts to
surface.

48. Let’s revisit some of the MicroServices
«problems»
•Coupling/Undefined Service Boundaries?
DDD to the rescue! (coupling between microservices that don’t belong to the same Bounded
Context or DDD Aggregate? Step back and review the aggregates).
•Distributed Transactions?
Boundaries are wrong! The purpose of an aggregate is to provide a transactional consistency
boundary.
•(Distributed) State Management?
Kinda the same of a distributed transaction: you need to guarantee consistency among different
boundaries  boundaries are wrong (again)!

49. Time to get «physical»
What is the METRIC that
defines «micro» ?

50. Logical Architecture
vs.
Physical Architecture

51. A Microservice in a Distributed
Environment
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.

52. A Service spans multiple «technologies»
and «responsibilities»
Product Catalog Inventory Logistics
Backend
( .net / java / go / … )
Web Portal
( web api / html /
javascript / …)
Mobile Apps
( .net / xamarin / swift /
… )
What about the Deployment Unit(s) ?
Team 1
Team 1
Team 1
Team 2
Team 2
Team 2
Team 3
Team 3
Team 3

53. When it comes to the physical view…
what’s inside a «Service» ?
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!

54. Microservices «Physical View»:
composition of components & services
Web Crawler
Coordinator 1
Parser 1
Download 1
Analyzer 1
Parser n
Download n
Analyzer n
Coordinator n
Parser 1
Download 1
Analyzer 1
Parser n
Download n
Analyzer n
Web Crawler Service

55. How do we «code» the Service ?
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).

56. Multi-Tier Layered Architecture

57. CQRS / ES (Aggregate  Domain Object)

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

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

60. Deployment problems - Topology
oWhat services are available ?
oWhat each service do ?
oHow do we reach them ?
oHow do we scale them ?
Possible Solutions:
oAPI Gateways.
oService Registry / Service Discovery Platforms.

61. Diagnostics and Failure Management
oHow do we know if a service is up and running ?
oWhat to do when a request fail ?
oHow and where do we implement retry strategies ?
oWho is responsible for doing that ?
Possible Solutions:
oHealth Monitoring / Distributed Tracing.
o(wait and) Retry X times.
o(wait and) Retry forever.
oCircuit Breaker (custom fallback, fail fast, autoheal….).

62. Do we have tools that can help us build a
Microservices solution?
Akka (https://akka.io) & Akka.NET (https://getakka.net/)
Microsoft Orleans (https://dotnet.github.io/orleans/)
Dapr - Distributed Application Runtime (https://dapr.io/)

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

64. Containers: Package, Deploy, Run!
A Docker container image is a lightweight, standalone,
executable package of software that includes everything
needed to run an application: code, runtime, system tools,
system libraries and settings.
It’s a true Unit of Deployment: isolate software from its
environment and ensure that it works uniformly despite
potential differences.
Multiple containers can run on the same machine and share
the OS kernel with other containers, each running as
isolated processes in user space.
https://www.docker.com/resources/what-container

65. How to «docker-ize» an application ?
On a Windows OS (Windows 10 or Windows Server 2016):
oSetup Docker Engine following the instructions:
https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-
environment?tabs=Windows-10-Client
oCreate a dockerfile with the proper directives to instruct the Docker Engine what to do.
oUse the Docker CLI and the Dockerfile to:
◦ Build the image of the container.
◦ Run the container itself.

66. Container «Orchestration»
Managing containers by hand is not recommended, things can become complicated quite fast.
What if the number of MicroServices/Containers raises and we want to leverage the elasticity of
the system scaling up and down when needed?
automated container deployment, scaling, and
management across a cluster of nodes.
https://kubernetes.io/

67. What Kubernetes does
It’s a set of independent, composable control processes that drive the system providing:
oService discovery and load balancing.
oAutomatic bin packing.
oSelf-healing.
oStorage orchestration.
oSecret and configuration management.
oHorizontal scaling.
oAnd more…

68. 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 ?

69. So: Is it an «Architecture» ?
Microservices is an implementation approach for distributed
systems based on concepts coming from: Service Oriented
Architecture, Event Driven Architecture, Domain Driven Design.
Microservices also relate to the technical processes around
packaging, deploying and management operations.

70. Resources - Microservices
Microservices.io
https://microservices.io/
.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/

71. Resources – DDD / Messaging
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/
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

72. Resources - Docker / Kubernetes
Docker Desktop for Windows (Community Edition)
https://hub.docker.com/editions/community/docker-ce-desktop-windows
Containers on Windows Documentation
https://docs.microsoft.com/en-us/virtualization/windowscontainers/
Docker images for ASP.NET Core
https://docs.microsoft.com/it-it/aspnet/core/host-and-deploy/docker/building-net-docker-
images?view=aspnetcore-3.0
Kubernetes
https://kubernetes.io/docs/setup/
Intro to Windows support in Kubernetes
https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-
kubernetes/

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