This presentation outlines the benefits and drawbacks of using microservices and designing your application as microsevices.

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