Do's and Don'ts moving to Go microservices architecture

Are you moving, or planning to move to a microservice architecture? It can be a real challenge today for companies to keep updated with technologies, performance, scaling, management methods, ways of working.

In this talk, we will share our story, the bad and the ugly moving from a monolith to a microservice architecture in Golang. You will discover the do’s and the don't’s we learned from our journey, from a technical and organisational perspective.

Key Takeaways
- Discover why we chose to Go to take the best of its simplicity
- Learn how to make a team responsible for their work
- Get a reminder of why you should make automation a priority

Transcript

1. Do's & Don'ts moving to Go microservices architecture
2. GDG Sophia-Antipolis Organiser WHAT06 Member Women Techmakers Ambassador @doniacld Donia Chaiehloudj Backend Engineer @Powder
3. Aliénor Latour Diversity Ambassador alienor-latour Senior Backend Engineer @HelloFresh
4. 1. Where to start 2. Prepare for growth 3. How to maintain
5. Multi-billion-euro companies started in a garage. 1. Where to start
6. Have a product idea What are the needs What are the constraints Data processing software Scale to millions of processings Already a legacy version Context Context | Validate the idea | Technical choices
7. Define a minimal version Implement a prototype Verify the feasibility Make technical choices Validate the idea Context | Validate the idea | Technical choices
8. Use well-known open-source tools Community support, Stack Overflow goldmine Online free courses, tutorials Easier recruitment & onboarding Technical choices Context | Validate the idea | Technical choices
9. Context | Validate the idea | Technical choices Language trends
10. Use well-known open-source tools Choose Go Created for cloud computing Designed for concurrency Technical choices Context | Validate the idea | Technical choices
11. “My first implementation was in Ruby, but when I re-implemented in Go I was able to take advantage of concurrency to get a 20x performance improvement.” https://tinyurl.com/cncf-devstats Q&A with DevStats creator Łukasz Gryglicki Context | Validate the idea | Technical choices
12. Use well-known open-source tools Choose Go Perfect for cloud computing Designed for concurrency Easy to learn Technical choices Context | Validate the idea | Technical choices
13. Matthias Endler - https://endler.dev/ Context | Validate the idea | Technical choices
14. Use well-known open-source tools Choose Go Perfect for cloud computing Designed for concurrency Easy to learn Great community Technical choices Context | Validate the idea | Technical choices
15. Women Who Go Context | Validate the idea | Technical choices Gophercon Europe
16. Use well-known open-source tools Choose Go Perfect for cloud computing Designed for concurrency Easy to learn Great community Plethora of resources Technical choices Context | Validate the idea | Technical choices
17. Do Verify the feasibility Get the big picture Explore your options Make rational choices Use existing tools Don't Start coding on day 1 Limit to your knowledge Follow trends Reinvent the wheel Where to start Context | Validate the idea | Technical choices
18. 2. Prepare for growth Let's get billions of users and raise a series A! Let's become a unicorn!
19. Restart from scratch Early mistakes make a better product Define teams and communication channels Streamlining Streamlining | Separate Responsibilities | Automate everything
20. “Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.” Mel Conway's law Streamlining | Separate Responsibilities | Automate everything
21. Clear boundaries Clear contracts User-oriented APIs Separate responsibilities Streamlining | Separate Responsibilities | Automate everything
22. Publish Represent Protocols Streamlining | Separate Responsibilities | Automate everything
23. Clear boundaries Clear contracts User-oriented APIs Reduce cognitive load Easy evolution Independent deployment Microservices Separate responsibilities Streamlining | Separate Responsibilities | Automate everything
24. You make it, you run it. Streamlining | Separate Responsibilities | Automate everything https://tinyurl.com/ci-cd-pipeline
25. Streamlining | Separate Responsibilities | Automate everything Orchestrated containers
26. Streamlining | Separate Responsibilities | Automate everything Cloud or premises?
27. Automate everything Streamlining | Separate Responsibilities | Automate everything
28. Automate everything Human time is money Streamlining | Separate Responsibilities | Automate everything
29. Automate everything Human time is money Repeating is boring Streamlining | Separate Responsibilities | Automate everything
30. Automate everything Human time is money Repeating is boring Repeating is boing Streamlining | Separate Responsibilities | Automate everything
31. Automate everything Human time is money Repeating is boring Repeating is error-prone Streamlining | Separate Responsibilities | Automate everything
32. Human time is money Repeating is boring Repeating is error-prone Setup Continuous Integration & Continuous Delivery Automate everything Streamlining | Separate Responsibilities | Automate everything
33. Streamlining | Separate Responsibilities | Automate everything https://katalon.com/resources-center/blog/ci-cd-pipeline
34. CI/CD pipelines with Go Streamlining | Separate Responsibilities | Automate everything Format Lint Tests Coverage Benchmark gofmt golangci-lint go test go test -cover go test -bench=.
35. Human time is money Repeating is boring Repeating is error-prone Setup Continuous Integration & Continuous Delivery Test at different levels Automate everything Streamlining | Separate Responsibilities | Automate everything
36. http://www.testingreferences.com/here_be_pyramids.php Streamlining | Separate Responsibilities | Automate everything Ideal pyramid tests
37. F1 Streamlining | Separate Responsibilities | Automate everything Performance & load tests
38. Do Separate responsibilities Own your code Write tests early Setup CI/CD pipelines Don't Redeploy everything as you go Rely on manual actions Stuff the monolith turkey Prepare for growth Streamlining | Separate Responsibilities | Automate everything
39. 3. How to maintain
40. Shoveling the snow forward Pelleter en avant https://ferd.ca/on-technical-debt-shoveling-forward.html Refactoring is mandatory | Monitoring
41. The software needs to grow as you learn Dedicate time for housekeeping Stay up to date with dependency versions Work iteratively, in small steps Refactoring is mandatory Refactoring is mandatory | Monitoring
42. Setup observability tools Add logs & traces Build meaningful dashboards Automate alerts Monitoring Refactoring is mandatory | Monitoring
43. Do Setup thresholds for alerts Keep track of technical debt Don't Suppose bugs never happen How to maintain Refactoring is mandatory | Monitoring
44. Conclusion
45. Conclusion Choose Go to leverage its simplicity and scalability Automation is a priority and well-invested money Make your domain clear with low cognitive load Allocate time for housekeeping
46. Thank you! Software Engineer She/Her alienor-latour Aliénor Latour Software Engineer She/Her @doniacld Donia Chaiehloudj https://gopherize.me/
47. Go further
48. Go further
49. Go further
50. Go further
51. Go further