A Gentle introduction to Microservices

What are microservices? Why should I use them? Are they a trend? Some say they are a "standard" solution, others say they shouldn't be used, and others deny their existence ... But whoever develops software and has to bring home some software that works, what has to do?
Let's try to see and understand where they come from, what they are and what characteristics they have to make a conscious choice in every context.

Transcript

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!!!