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
   

   View Slide

2. GDG Sophia-Antipolis Organiser
   WHAT06 Member
   Women Techmakers Ambassador
   @doniacld
   Donia Chaiehloudj
   Backend Engineer @Powder
   

   View Slide

3. Aliénor Latour
   Diversity Ambassador
   alienor-latour
   Senior Backend Engineer @HelloFresh
   

   View Slide

4. 1. Where to start
   2. Prepare for growth
   3. How to maintain
   

   View Slide

5. Multi-billion-euro companies started in a garage.
   1. Where to start
   

   View Slide

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
   

   View Slide

7. Define a minimal version
   Implement a prototype
   Verify the feasibility
   Make technical choices
   Validate the idea
   Context | Validate the idea | Technical choices
   

   View Slide

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
   

   View Slide

9. Context | Validate the idea | Technical choices
   Language trends
   

   View Slide

10. Use well-known open-source tools
    Choose Go
    Created for cloud computing
    Designed for concurrency
    Technical choices
    Context | Validate the idea | Technical choices
    

    View Slide

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
    

    View Slide

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
    

    View Slide

13. Matthias Endler - https://endler.dev/
    Context | Validate the idea | Technical choices
    

    View Slide

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
    

    View Slide

15. Women Who Go
    Context | Validate the idea | Technical choices
    Gophercon Europe
    

    View Slide

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
    

    View Slide

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
    

    View Slide

18. 2. Prepare for growth
    Let's get billions of users and raise a series A!
    Let's become a unicorn!
    

    View Slide

19. Restart from scratch
    Early mistakes make a better product
    Define teams and communication channels
    Streamlining
    Streamlining | Separate Responsibilities | Automate everything
    

    View Slide

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
    

    View Slide

21. Clear boundaries
    Clear contracts
    User-oriented APIs
    Separate responsibilities
    Streamlining | Separate Responsibilities | Automate everything
    

    View Slide

22. Publish
    Represent Protocols
    Streamlining | Separate Responsibilities | Automate everything
    

    View Slide

23. Clear boundaries
    Clear contracts
    User-oriented APIs
    Reduce cognitive load
    Easy evolution
    Independent deployment
    Microservices
    Separate responsibilities
    Streamlining | Separate Responsibilities | Automate everything
    

    View Slide

24. You make it, you run it.
    Streamlining | Separate Responsibilities | Automate everything
    https://tinyurl.com/ci-cd-pipeline
    

    View Slide

25. Streamlining | Separate Responsibilities | Automate everything
    Orchestrated containers
    

    View Slide

26. Streamlining | Separate Responsibilities | Automate everything
    Cloud or premises?
    

    View Slide

27. Automate everything
    Streamlining | Separate Responsibilities | Automate everything
    

    View Slide

28. Automate everything
    Human time is money
    Streamlining | Separate Responsibilities | Automate everything
    

    View Slide

29. Automate everything
    Human time is money
    Repeating is boring
    Streamlining | Separate Responsibilities | Automate everything
    

    View Slide

30. Automate everything
    Human time is money
    Repeating is boring
    Repeating is boing
    Streamlining | Separate Responsibilities | Automate everything
    

    View Slide

31. Automate everything
    Human time is money
    Repeating is boring
    Repeating is error-prone
    Streamlining | Separate Responsibilities | Automate everything
    

    View Slide

32. Human time is money
    Repeating is boring
    Repeating is error-prone
    Setup Continuous Integration & Continuous Delivery
    Automate everything
    Streamlining | Separate Responsibilities | Automate everything
    

    View Slide

33. Streamlining | Separate Responsibilities | Automate everything
    https://katalon.com/resources-center/blog/ci-cd-pipeline
    

    View Slide

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=.
    

    View Slide

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
    

    View Slide

36. http://www.testingreferences.com/here_be_pyramids.php
    Streamlining | Separate Responsibilities | Automate everything
    Ideal pyramid tests
    

    View Slide

37. F1
    Streamlining | Separate Responsibilities | Automate everything
    Performance & load tests
    

    View Slide

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
    

    View Slide

39. 3. How to maintain
    

    View Slide

40. Shoveling the
    snow forward
    Pelleter en avant
    https://ferd.ca/on-technical-debt-shoveling-forward.html
    Refactoring is mandatory | Monitoring
    

    View Slide

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
    

    View Slide

42. Setup observability tools
    Add logs & traces
    Build meaningful dashboards
    Automate alerts
    Monitoring
    Refactoring is mandatory | Monitoring
    

    View Slide

43. Do
    Setup thresholds for alerts
    Keep track of technical debt
    Don't
    Suppose bugs never happen
    How to maintain
    Refactoring is mandatory | Monitoring
    

    View Slide

44. Conclusion
    

    View Slide

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
    

    View Slide

46. Thank you!
    Software Engineer
    She/Her
    alienor-latour
    Aliénor Latour
    Software Engineer
    She/Her
    @doniacld
    Donia Chaiehloudj
    https://gopherize.me/
    

    View Slide

47. Go further
    

    View Slide

48. Go further
    

    View Slide

49. Go further
    

    View Slide

50. Go further
    

    View Slide

51. Go further
    

    View Slide