The document provides an introduction to microservices, defining them as small, decoupled services that represent bounded contexts within an application. It contrasts microservices with monolithic applications, highlighting the advantages and disadvantages of each architecture style, such as improved error tolerance and technology flexibility for microservices, along with increased complexity. The document also advises starting with a monolith before transitioning to microservices while being aware of the challenges that distributed systems present.

1. Microservices
An introduction

2. Microservice as a concept

3. What is a microservice?

4. What is a microservice?

5. What is a microservice?

6. What is a microservice?
a service that fit in one page of code...

7. What is a microservice?
a service that fit in one page of code...
a service that represents a bounded context of a system domain...

8. What is a microservice?
a service that fit in one page of code...
a service that represents a bounded context of a system domain...
a fine grained service...

9. What is a microservice?
a service that fit in one page of code...
a service that represents a bounded context of a system domain...
a fine grained service...
a very small service...

10. What is a microservice?

11. Microservice in software
architecture / design

12. And the microservice architectural style?

13. And the microservice architectural style?
"The microservice architectural style is an approach to developing a
single application as a suite of small services, each running in its own
process and communicating with lightweight mechanisms, often an
HTTP resource API"

14. And the microservice architectural style?

15. And the microservice architectural style?

16. Why do we need Microservices?

17. Why? A Background - Monolithic apps
UI DB

18. Why? A Background
● Monolithic applications: One large application to handle everything !
● Good aspects:
○ easy communication between components
○ easy to develop

19. Why? A Background
● Monolithic applications: One large application to handle everything !
● Good aspects:
○ easy communication between components
○ easy to develop
● Bad aspects:
○ hard coupling between components
○ long term commitment to a technology stack
○ you need to escalate the entire block
○ component crash affects the entire application

20. UI DB
Monolithic apps - Error handling

21. UI DB
Monolithic apps - Error handling

22. UI DB
load
balance
Monolithic apps - Scalability

23. UI DB
Monolithic apps - Scalability

24. How can I address these issues?

25. UI DB
What if we divide to conquer?

26. UI DB
What if we divide to conquer?

27. UI DB
What if we divide to conquer?

28. UI DB
What if we divide to conquer?

29. UI DB
What if we divide to conquer?

30. UI DB
What if we divide to conquer?

31. Microservices
● Good aspects:
○ decoupled services/components grouped by domain bounded contexts
○ error tolerance can be achieved more easily
○ data can be distributed through the components too
○ each component can use a different technology stack

32. UI DB
Customers Payments
Products
LogisticsCustomer Care
Splitting into domain bounded contexts

33. UI DB
Customers
Customer Care
Products Payments
Logistics
Splitting into domain bounded contexts

34. UI
Payments
DB
Customers
Customer Care
Products
Payments
Logistics
Products
DB
Logistics
DB
...
Splitting the data

35. UI
Payments
DB
Customers
Customer Care
Products
Payments
Logistics
Products
DB
Logistics
DB
...
Splitting the technology stack

36. UI
Payments
DB
Customers
Customer Care
Products
Payments
Logistics
Products
DB
Logistics
DB
...
Splitting the technology stack

37. Microservices
● Good aspects:
○ decoupled services/components grouped by domain boundaries
○ error tolerance can be achieved more easily
○ data can be distributed through the components too
○ each component can use a different technology stack
● Bad aspects:
○ the overall complexity of the app increases
○ it's difficult to move responsibilities across components through refactorings
○ integration testing may be hard
○ component communications have more latency and need to have a well defined interface

38. UI
Payments
DB
Customers
Customer Care
Products
Payments
Logistics
Products
DB
Logistics
DB
...

39. Distributed computing - Keep in mind !
1. CAP Theorem (Consistency, Availability and Partition Tolerance)
2. Distributed System Fallacies
○ 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.

40. Final considerations / suggestions
● Start as a monolith app, organizing the code in modules
● Keep refactoring the code to keep the module cohesion
● While the first monolith problems begin to appear, split into small services
● Be aware that microservices isn't a silver bullet
○ When you embrace this approach you also embrace a lot of distributed systems challenges and benefits

41. Hmm… And do you really applied
this concept?

42. Our first app that started as a
monolith !

43. Our newest app structured using the
microservice architecture !

44. Thanks !
danielbpdias@gmail.com
https://github.com/danielbdias
https://www.slideshare.net/DanielDias10
https://github.com/danielbdias/nodebr-meetup-ddd-demo