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.
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
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.
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.
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.
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.
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.
37. Create your first microservice
Find your microservice.
Choose the communication style.
Choose where to store the data.
Choose where to deploy the microservices.
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