The document provides a history of microservices, describing how the term originated in the early 2000s and was popularized at a software architecture workshop in 2011. It discusses key concepts of microservices like independent deployability, organizing services around business capabilities, and having each service own its own state and data. The document also covers microservice communication patterns, persistence, deployment considerations, and challenges like testing, monitoring, security, and transactions across services.

1. A Gentle
Introduction To
Microservices
Microservice everywhere ...

2. GPad
Born to be a developer with an interest in distributed system.
I have developed with many languages like C++, C#, js and ruby. I had fallen in
love with functional programming, especially with elixir, erlang.
● Twitter: https://twitter.com/gpad619
● Github: https://github.com/gpad/
● Medium: https://medium.com/@gpad
CTO & founder of coders51

3. A long time ago in a galaxy far, far away....

4. History
From Wikipedia:
There are numerous claims as to the origin of the term microservices. [...] in
2004, Fred George began working on prototype architectures based on what
he called the "Baysean Principals" named after Jeff Bay.
As early as 2005, Peter Rodgers introduced the term "Micro-Web-Services"
during a presentation at the Web Services Edge conference.
In 2007, Juval Löwy [...] called for building systems in which every class was a
service.

5. History
From Wikipedia:
A workshop of software architects held near Venice in May 2011 used the
term "microservice" to describe what the participants saw as a common
architectural style that many of them had been recently exploring.
Adrian Cockcroft, former director for the Cloud Systems at Netflix, described
this approach as "fine grained SOA", pioneered the style at web scale, as did
many of the others mentioned in this article - Joe Walnes, Dan North, Evan
Bottcher, and Graham Tackley.

6. History
What do you think about this?

7. Only technical stuff?!?!

8. Only technical stuff?!?!
"We try to create teams that are no larger than can be fed by two pizzas," said
Bezos. "We call that the two-pizza team rule."
Conway's law.
Organized around Business Capabilities.

9. Only technical stuff?!?!

11. Microservices Main Concepts

12. Main Concepts
Independent Deployability
Built around a Business
Owner of its state
Size

13. Independent Deployability

14. Built around a Business

15. Owner of its own state

16. Size

17. Where are microservices?

18. Microservices 💘 DDD

19. Microservices 💘 DDD

20. Microservices 💘 DDD

21. Microservices 💘 DDD

22. Microservices 💘 DDD

23. Microservices 💘 DDD

24. Where are microservices?
DDD isn’t the only way (it’s the best in IMHO).
Regulations, GDPR, PCI-DSS, force to formal validations.
Volatility, how fast a part of the system evolves.

25. Microservices communication

26. Microservices communication
Synchronous vs Asynchronous
Request-Response
Event Based

27. Synchronous vs Asynchronous

28. Request-Response

29. Event Based

30. Microservices communication - Mixing
Some types of communication can be synchronous, and others asynchronous.

31. Persistence

32. Persistence
Do you remember Independent Deployability?
Every Service should have its own DB.
Don’t share the DB.
This is my DB. There are many like it, but this one is mine.

33. Persistence

34. Deployment

35. Deployment
You don’t require K8s to run Microservice.
You have to (must?!?) be able to deploy your Microservice smoothly.
Every Microservice should be isolated.

36. Create your first microservice

37. Create your first microservice
Find your microservice.
Choose the communication style.
Choose where to store the data.
Choose where to deploy the microservices.

38. Find your microservice

39. Choose the communication style

40. Choose where to store the data

41. Choose where to deploy the microservice

42. Find your microservice

43. Read instruction before using ...

44. Easily deploy
If you cannot easily deploy your application, don’t try to move on Microservice
realm.
You have to deploy tens of them, and it should be easy and smooth.
Automate everything!!!

45. Log Aggregator
You should have a place where you can collect all the logs.
You should be able to correlate the logs between different microservice.
Implement from day one correlation Id and causation Id.

46. Network is reliable
“Network is reliable” is the first fallacy of “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.

47. Transaction between different Microservices
Don’t do it.
Never!!!
Really, don’t do it!!!
The “Long Living Transaction” are often business transactions (ex: book a
room), not a DB Transaction.
You can use a concept like Saga or Workflow to manage these situations.

48. Be prepared to fail
Don’t start with the most critical part of your application.
In the early stage, you will fail… I’m sorry.
Find the most stable and straightforward part of your business.
Don’t be obsessed with technology.

49. So, this is it?
Clearly no, what do you think about:
Testing. How do you think to test 5, 10, 100 microservices?
Monitoring (observability). How do you detect that something going wrong?
Security. How are microservices exposed to the outworld?
This is a never-ending story ...

50. Reference
Building Microservices
Monolith to Microservices
Clean Architecture
Microservices
Microservice Architecture pattern
[1606.04036] Microservices: yesterday, today,
and tomorrow
Netflix Heads into the Clouds - Interview with
Adrian Cockcroft
Adrian Cockcroft's Presentations on
SlideShare
Feature Toggles (aka Feature Flags)
Latency numbers every programmer should
know
Distributed Systems 3rd edition (2017)
Life beyond Distributed Transactions: an
Apostate's Opinion

51. Thanks!!!