Nobody told me about that : Chronicles about implementing microservice architecture

i sure you've heard about microservices. did you suffered when implementing microservice architecture, did you fail (like i did) implementing them. in this talk i will tell you about all the unknown indesrables effects and how to take the benfits of such architecture based on true failed and successessuful experiences.

Transcript

1. NOBODY TOLD ME ABOUT THAT NOBODY TOLD ME ABOUT THAT CHRONICLES ABOUT IMPLEMENTING MICROSERVICE CHRONICLES ABOUT IMPLEMENTING MICROSERVICE ARCHITECTURE ARCHITECTURE Khaled Souf twitter: @khaledsouf 1 / 32
2. ABOUT ME ABOUT ME Developer/Cra ing So ware Coach/ DDD Expert/Trainer Co-organizer of So ware Cra ers Montréal meetup Co-organizer of SOCRATES Canada unconference more details on : https://ksouf.com 2 / 32
3. 3 / 32
4. 4 / 32
5. I remain convinced that it is much easier to partition an existing, "brownfield" system than to do so up front with a new, greenfield system. -- Sam Newman (Author of building microservices) 5 / 32
6. If you can’t build a well-structured monolith, what makes you think you can build a well-structured set of microservices? -- Simon Brown (Author of So ware Architecture for Developers) 6 / 32
7. source microservices.io -- Chris Richardson (Author of microservices Patterns) 7 / 32
8. DOMAIN DRIVEN DESIGN TO THE RESCUE DOMAIN DRIVEN DESIGN TO THE RESCUE STRATEGIC DESIGN TO BE PRECISE STRATEGIC DESIGN TO BE PRECISE Extract your Microservice from the monolith based on business capabilities Create New Feature on new Bounded Context (Bubble Context) Use some Context Mapping Patterns for communication 8 / 32
9. ANTI-CORRUPTION LAYER (ACL) ANTI-CORRUPTION LAYER (ACL) 9 / 32
10. OPEN HOST SERVICE (OHS) OPEN HOST SERVICE (OHS) 10 / 32
11. More details on: Applied Domain Driven Design On Legacy Code 11 / 32
12. Don't Make Microservices communicate with each other (Directly)!! 12 / 32
13. UNLESS YOU WANT THIS!!! UNLESS YOU WANT THIS!!! 13 / 32
14. 14 / 32
15. HOW WE DO AVOID IT? HOW WE DO AVOID IT? Service registry: every instance of service is registered and can be found only by the registry Microservices publish messages to the bus to chain actions Microservices consumes from queues that subscribed to specific event of the messaging bus Messages are used for asynchronous commands Registry is used to find API's (REST for the most) for querying 15 / 32
16. MICROSERVICE ARCHITECTURE (WITH REGISTRY & MICROSERVICE ARCHITECTURE (WITH REGISTRY & MESSAGING BUS) MESSAGING BUS)
17. 16 / 32
18. WHAT ABOUT DATABASES? WHAT ABOUT DATABASES? Use choreography-based saga pattern (aka eventual consistency in Domain Driven Design). A Microservice manage his own data (shared database is Anti-Pattern). Keep two copies for starting (one in monolith/ one in microservice). 17 / 32
19. CHOREOGRAPHY-BASED SAGA PATTERN CHOREOGRAPHY-BASED SAGA PATTERN 18 / 32
20. BACK-END FOR FRONT-END (BFF) BACK-END FOR FRONT-END (BFF) Don't expose your Microservices directly Use BFF as view and information aggregator for general purpose or specific customer (depends on context) Use a gateway if you're exposing BFF to something external 19 / 32
21. BFF: GENERAL PURPOSE API BFF: GENERAL PURPOSE API source samnewman.io 20 / 32
22. BFF: SPECIFIC PURPOSE API BFF: SPECIFIC PURPOSE API source samnewman.io 21 / 32
23. USE CONTRACTS TESTING FOR API USE CONTRACTS TESTING FOR API (INSTEAD OF END TO END TESTING) (INSTEAD OF END TO END TESTING) Let your consumer define the contract (Consumer Driven Contracts Testing) Use a contract broker to publish/verify your contracts 22 / 32
24. CONSUMER DRIVEN CONTRACTS TESTING CONSUMER DRIVEN CONTRACTS TESTING 23 / 32
25. USE MICRO FRONTEND USE MICRO FRONTEND 24 / 32
26. INDUSTRIALIZE YOUR APPLICATIONS INDUSTRIALIZE YOUR APPLICATIONS Create Template by Type of Project. Focus only Business Value when creating your Microservice. Define Template by used language and capabilities. Your Template should contain also you definition of build & deployment pipelines. 25 / 32
27. LOGGING LOGGING Use Centralized logs solution Use structured logs Log your input/output of your Microservice Use Correlation Id to monitor cross Microservices requests 26 / 32
28. MONITORING MONITORING Implement always a health check for your Microservice Centralize your metrics in one simple dashboard Use alerting system when any weird behavior 27 / 32
29. PROVISIONING/CONFIGURATION MANAGEMENT PROVISIONING/CONFIGURATION MANAGEMENT Use tools to manage configuration (Ansible, Saltstack, ...). build a git repository infrastructure as code to automate your provisioning. Make sure that the only possible modification of infrastructure is by modifying infra as code. 28 / 32
30. SECRETS MANAGEMENT SECRETS MANAGEMENT Separate your Secrets from your configuration in a secrets server (Vault Server) Use key rotation technique to change keys periodically to prevent that a key is compromised 29 / 32
31. WARP-UP WARP-UP Don't start with microservices Use Strategic Design of Domain Driven Design and Strangler Pattern to split your monolith don't make microservices communicate directly (Service Registry for API Query, Messaging BUS for Command) Use Consumer Driven Contracts Technique instead of End to End Testing Centralize your cutting-edge concern (logging, monitoring, secrets, configuration, infrastructure) Automate as much as possible (infrastructure provisioning, config management, secrets management,build & deployment, ..) 30 / 32
32. BEFORE FINISHING: I DID NOT INVENTED ALL THESE BEFORE FINISHING: I DID NOT INVENTED ALL THESE TECHNIQUES!!! TECHNIQUES!!! Domain Driven Design Microservices Patterns (The Book) Twelve Factor DevOps Practices 31 / 32
33. THANK YOU FOR ATTENDING THANK YOU FOR ATTENDING Questions ? twitter: @khaledsouf 32 / 32