1. Paulo Sousa
2019
INTRODUCTION TO
MICROSERVICES

2. DISCLAIMER
Parts of this presentation are based
on Sam Newman’s workshop
“Designing Microservices” @ NDC
Porto 2019

3. WHAT ARE
MICROSERVICES?

4. Small independently
deployable services that
work together, modelled
around a business
domain

5. SMALL
Size is not the actual point!
not as big as a server app that
needs to be built and deployed
as a single block
Manageable units of
functionality and deployability

6. V4
V2
V5
V2
V3
V1
INDEPENDENTLY DEPLOYABLE
No lock-step build and
deployment
Avoiding the “Distributed
Monolith”

7. https://martinfowler.com/articles/microservices.html
Any organization that designs a system (defined broadly)
will produce a design whose structure is a copy of the
organization's communication structure.
-- Melvyn Conway, 1967
WORK TOGETHER

8. BUSINESS DOMAIN
https://martinfowler.com/bliki/BoundedContext.html

9. THE PROMISE

10. V1
V1
V1
V1
V1
V1
In the begining
everything works fine

11. But happens.
Fortunatelly, no one else
needs to know about it.
V2
V1
V1
V1
V1
V1

12. And it happens again V2
V2
V1
V1
V2
V1

13. And we also want to
refactor and update the
technology stack
V3
V2
V2
V1
V3
V1

14. And enhance the service V4
V2
V2
V1
V3
V1

15. And scale the parts of the
system that really need
extra power
V4
V2
V2
V1
V3
V1

16. And seamingly add new
features
V4
V2
V2
V2
V3
V1
V1
Recommend

17. And all goes well in the V4
V2
V3
V2
V3
V1
V1
Recommend

18. BENEFITS
• Focus on one thing and do it right
• Organizational alignment
• Release functionality faster
• Independent scaling
• Technology diversity; Adopt technologies faster
• Enable security concern segregation
• Enable resiliency by designing for failure

19. But…

21. REQUIRES
V4
V2
V3
V2
V3
V1
V1
Recommend
• Automation
• High cohesion
• Loose coupling
• Stable versioned APIs
a.k.a. Maturity

22. HIGH
COHESION
Business cohesion
Things that change together, stay
together

23. LOOSE
COUPLING
Implementation coupling
Domain coupling
Temporal coupling

24. DOWNSIDES
• Cognitive overloading (many tooling options)
• Cognitive overloading (system understanding)
• Testing is more complicated
• Monitoring is more complex
• Operational overhead
• Resiliency isn’t free

25. So we must
remember

26. Microservices
are about
problems at
scale
# of developers
# of features
# of users

27. MICROSERVICES ARE
NOT THE GOAL.
IT IS A PATH TO ACHIEVE
A BUSINESS OBJECTIVE

28. EMBRACE
Eventual
consistency
Data redundancy
& caching
No single
cannonical model
Long running
transactions

29. ARE THEY USEFUL
FOR “US”?

30. Truth is,
Most problem-contexts don’t (usually) have
a “scale problem”

31. However, there are several potential seams
Calculations Partners
Users &
Authorizations
Customers Business processes
Document
management &
printing
Widgets …

32. DESIGNING AND
ARCHITECTING
If we decide to build it

33. IDENTIFYING SERVICE BOUNDARIES
https://docs.microsoft.com/en-us/azure/architecture/microservices/model/domain-analysis

34. THE MICROSERVICES DESIGN CANVAS
Matt Mclarty, Irakli Nadareishvili (2017)

35. THE MICROSERVICES DESIGN CANVAS
Matt Mclarty, Irakli Nadareishvili (2017)

36. Each
microservice
owns the end-
to-end
Even the UI & data store!

37. MICROSERVICES AND THE UI
SINGLE PAGE APPLICATIONS COMPOSITE UI ASSEMBLY

38. SAGAS, COMPENSATING TRANSACTIONS
• Orchestration
https://docs.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction

39. SAGAS, COMPENSATING TRANSACTIONS
CHOREOGRAPHY ORCHESTRATION
https://microservices.io/patterns/data/saga.html

40. https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices

41. From monolith to
microservice

42. https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservices-architecture

43. https://cloudacademy.com/learning-paths/dotnet-monolithic-to-microservices-migration-284/

44. THE STRANGLER PATTERN
http://mycloudcomputing2017.blogspot.com/2017/02/what-is-strangler-application-pattern.html

45. SUMMING UP

46. microservices
• Are not the goal
• Are about problems at scale
• Are manageable units of functionality and
deployability
• Own the end-to-end
• Require automation and maturity

47. REFERENCES

48. REFERENCES
• Sam Newman (2014) Building Microservices. O’Reilly Media.
• James Lewis, Martin Fowler (2014) Microservices – a definition of this new
architectural term. https://martinfowler.com/articles/microservices.html
• Martin fowler (2015) Microservices trade-offs.
https://martinfowler.com/articles/microservice-trade-offs.html
• Martin Fowler (2014) Bounded context.
https://martinfowler.com/bliki/BoundedContext.html
• Microsoft. Microservices architecture. https://docs.microsoft.com/en-
us/dotnet/standard/microservices-architecture/architect-microservice-
container-applications/microservices-architecture
• Microsoft. Microservices architecture style.
https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-
styles/microservices

49. REFERENCES
• Matt Mclarty, Irakli Nadareishvili (2017) Streamlined Microservice Design
in Practice. In The DZone guide to Micoservices, vol 1.
https://dzone.com/storage/assets/7852543-dzone-microservicesguide-
2017.pdf
• Susan Fowler (2016) Production-ready Microservices. O’Reilly Media.
• IBM. Microservices for fast time to market and improved app quality.
https://www.ibm.com/cloud/garage/architectures/microservices
• IBM. Refactoring application code to microservices.
https://www.ibm.com/cloud/garage/practices/code/refactor-to-
microservices
• Nick Vennaro (2017) How to introduce microservices in a legacy
environment. https://www.infoworld.com/article/3237175/how-to-
introduce-microservices-in-a-legacy-environment.html