The document discusses microservices, defining them as small, self-contained processes that expose APIs for specific business needs. It outlines the benefits of using microservices, such as scalability and easier maintenance, while also addressing challenges like architectural complexity and data consistency. The author, Marian Marinov, emphasizes the importance of starting with a monolithic approach before transitioning to microservices when necessary.

1. Microservices
Are they for me?
Marian Marinov

2. Who am I?
➢ Director of Engineering at Web Hosting Canada
➢ Previously partner and Head of DevOps at SiteGround
➢ A SysAdmin and System Architect
➢ A hacker at heart

3. Why this talk?

4. Why this talk?
♥ ➢ I love microservices

5. Why this talk?
♥
♥
➢ I love microservices
➢ I love performance

6. Why this talk?
♥
♥
♥
➢ I love microservices
➢ I love performance
➢ I love smaller code bases

7. Why this talk?
♥
♥
♥
42
➢ I love microservices
➢ I love performance
➢ I love smaller code bases
➢ They are not always the answer

8. What are microservices?
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

9. What are microservices?
Exception to the above definition:
➢ Scalability
➢ Microservice depending on other microservices
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

10. What are microservices?
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

11. What are microservices?
➢ A simple file or DB used for exchanging data
A microservice is a small, self-contained process
which exposes an API to solve a single business need.
➢ API
* filesystem interface
* maybe added locking

12. What are microservices?
➢ A simple file or DB used for exchanging data
A microservice is a small, self-contained process
which exposes an API to solve a single business need.
➢ API
* DB protocol

13. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
A microservice is a small, self-contained process
which exposes an API to solve a single business need.
➢ API
* HTTP protocol
* RESTful GET/POST/PUT

14. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
➢ EDA (event-driven architecture)
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

15. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
➢ EDA (event-driven architecture)
* predefined event is triggering changes
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

16. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
➢ EDA (event-driven architecture)
* predefined event is triggering changes
* examples:
adding a user/changing balance on account
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

17. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
➢ EDA (event-driven architecture)
* predefined event is triggering changes
* examples:
adding a user/changing balance on account
* events trigger multiple different parts of the app
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

18. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
➢ EDA (event-driven architecture)
* predefined event is triggering changes
* examples:
adding a user/changing balance on account
* events trigger multiple different parts of the app
* the EDA is by definition decoupled
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

19. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
➢ EDA (event-driven architecture)
➢ Message passing interface(RabbitMQ, Kafka, etc.)
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

20. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
➢ EDA (event-driven architecture)
➢ Message passing interface(RabbitMQ, Kafka, etc.)
* Client/Worker or Publisher/Consumer models
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

21. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
➢ EDA (event-driven architecture)
➢ Message passing interface(RabbitMQ, Kafka, etc.)
* Client/Worker or Publisher/Consumer models
* The MPI is replacing the HTTP
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

22. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
➢ EDA (event-driven architecture)
➢ Message passing interface(RabbitMQ, Kafka, etc.)
* Client/Worker or Publisher/Consumer models
* The MPI is replacing the HTTP
* Easier access to your code
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

23. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
➢ EDA (event-driven architecture)
➢ Message passing interface(RabbitMQ, Kafka, etc.)
➢ Maybe GraphQL
➢ WebSockets
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

24. What are microservices?
➢ A simple file or DB used for exchanging data
➢ REST(maybe OpenAPI)
➢ EDA (event-driven architecture)
➢ Message passing interface(RabbitMQ, Kafka, etc.)
➢ Maybe GraphQL
➢ WebSockets
Use some form of communication between
decoupled parts of a bigger application.
A microservice is a small, self-contained process
which exposes an API to solve a single business need.

25. What are the benefi ts?
➢ Smaller
➢ code base
➢ operational data
➢ logical complexity

26. What are the benefi ts?
➢ Smaller
➢ code base
➢ operational data
➢ logical complexity
➢ “Make each program do one thing well.” - Ken Thompson

27. What are the benefi ts?
➢ Smaller
➢ code base
➢ operational data
➢ logical complexity
➢ “Make each program do one thing well.” - Ken Thompson
➢ Scalability
➢ less dependencies
➢ mostly self contained

28. What are the benefi ts?
➢ Smaller
➢ code base
➢ operational data
➢ logical complexity
➢ “Make each program do one thing well.” - Ken Thompson
➢ Scalability
➢ less dependencies
➢ mostly self contained
➢ Easier to maintain/update/upgrade
➢ smaller changes impact only this service
➢ upgrades are impacting only parts of our application infra
➢ easier blue-green deployments

29. What are the benefi ts?
➢ Smaller
➢ code base
➢ operational data
➢ logical complexity
➢ “Make each program do one thing well.” - Ken Thompson
➢ Scalability
➢ less dependencies
➢ mostly self contained
➢ Easier to maintain/update/upgrade
➢ Asynchronous code

30. What are the benefi ts?
➢ Smaller
➢ code base
➢ operational data
➢ logical complexity
➢ “Make each program do one thing well.” - Ken Thompson
➢ Scalability
➢ less dependencies
➢ mostly self contained
➢ Easier to maintain/update/upgrade
➢ Asynchronous code
➢ Partial failures
➢ feature flags/switches

31. Why not to choose them?
➢ Architectural complexity

32. Why not to choose them?
➢ Architectural complexity
➢ Authentication
➢ Multiple places where you have code
➢ Communication overhead
➢ Data format
➢ Handling single or multiple points of failure
➢ Integration testing

33. Why not to choose them?
➢ Architectural complexity
➢ Authentication
➢ Multiple places where you have code
➢ Communication overhead
➢ Data format
- should use common protocol and format
- sometimes impossible when using external services
➢ Handling single or multiple points of failure
➢ Integration testing

34. Why not to choose them?
➢ Architectural complexity
➢ Authentication
➢ Multiple places where you have code
➢ Communication overhead
➢ Data format
➢ Handling single or multiple points of failure
➢ Integration testing

35. Why not to choose them?
➢ Architectural complexity
➢ Authentication
➢ Multiple places where you have code
➢ Communication overhead
➢ Data format
➢ Handling single or multiple points of failure
➢ Integration testing
- on top of your unit testing

36. Why not to choose them?
➢ Architectural complexity
➢ Authentication
➢ Multiple places where you have code
➢ Communication overhead
➢ Data format
➢ Handling single or multiple points of failure
➢ Integration testing
➢ Data complexity
MOST OFTEN THE ROOT OF ALL EVIL
√DB

37. Why not to choose them?
➢ Architectural complexity
➢ Authentication
➢ Multiple places where you have code
➢ Communication overhead
➢ Data format
➢ Handling single or multiple points of failure
➢ Integration testing
➢ Data complexity
➢ DB Replication
- DO NOT replicate everything
- divide and conquer is your friend

38. Why not to choose them?
➢ Architectural complexity
➢ Authentication
➢ Multiple places where you have code
➢ Communication overhead
➢ Data format
➢ Handling single or multiple points of failure
➢ Integration testing
➢ Data complexity
➢ DB Replication
➢ Cache invalidation

39. Why not to choose them?
➢ Architectural complexity
➢ Authentication
➢ Multiple places where you have code
➢ Communication overhead
➢ Data format
➢ Handling single or multiple points of failure
➢ Integration testing
➢ Data complexity
➢ DB Replication
➢ Cache invalidation
➢ Data consistency
- strong vs eventual consistency models

40. Why not to choose them?
➢ Architectural complexity
➢ Authentication
➢ Multiple places where you have code
➢ Communication overhead
➢ Data format
➢ Handling single or multiple points of failure
➢ Integration testing
➢ Data complexity
➢ DB Replication
➢ Cache invalidation
➢ Data consistency
➢ Maybe MapReduce
- did all of the reducers finish
- did we start another map run before having available reducers

41. How to start?
Monolith first – by Martin Fowler

42. How to start?
Monolith first – by Martin Fowler
➢ Start with Monolith

43. How to start?
Monolith first – by Martin Fowler
➢ Start with Monolith
➢ If you already have big enough monolith
Look for places where async execution may be separated
➢
Look for hot paths with small logic footprint
➢
Separate one single logical part of the monolith
➢
➢ Strangler pattern
➢ Parts of the code that need to scale out(or that are frequently attacked)

44. How to start?
Monolith first – by Martin Fowler
➢ Start with Monolith
➢ If you already have big enough monolith
Look for places where async execution may be separated
➢
Look for hot paths with small logic footprint
➢
Separate one single logical part of the monolith
➢
➢ Strangler pattern
➢ Parts of the code that need to scale out(or that are frequently attacked)
➢ Do not start by redesigning all of your monolith
as microservices

45. How to start?
Monolith first – by Martin Fowler
➢ Start with Monolith
➢ If you already have big enough monolith
Look for places where async execution may be separated
➢
Look for hot paths with small logic footprint
➢
Separate one single logical part of the monolith
➢
➢ Strangler pattern
➢ Parts of the code that need to scale out(or that are frequently attacked)
➢ Do not start by redesigning all of your monolith
as microservices
➢ Do not start with microservice architecture unless you are
already at the scale that needs it

46. Thank you
Marian Marin
mm@yuhu.biz