Microservices introduction

A quick introduction to microservices, its challenges and advantages.

Transcript

1. BBL 21 juillet - INVIVOO
   MicroServices Boris FELD
   

   View Slide

2. About ME
   ❖ Python Dev @ tinyclues
   ❖ DevOps
   ❖ @lothiraldan
   

   View Slide

3. View Slide

4. From monolith…
   

   View Slide

5. To microservices
   

   View Slide

6. History
   ❖ Starts in ~2012 / 2013
   ❖ A synchronized evolution
   ❖ Helped by cloud evolution
   ❖ Pioneers: James Lewis from ThoughtWorks and Adrian
   Cockcroft from Netflix
   ❖ Advocators like Martin Fowler from ThoughtWorks
   

   View Slide

7. Who uses it
   ❖ Heavy user
   ❖ Unknown number of services
   ❖ ~100-150 service called/page
   ❖ Pioneer
   ❖ Open-Source and blog a lot!
   ❖ ~800 services
   ❖ ~6 service called/api call
   

   View Slide

8. Example
   User management service
   

   View Slide

9. Small
   Simple composant Easy to understand
   Easy to maintain
   Small team
   

   View Slide

10. Single Responsibility
    Do one thing Do it well
    Easy to test
    Unix way
    

    View Slide

11. Black-box
    Expose a contract What it does
    What it returns And the format
    

    View Slide

12. Isolation
    Communicate over

    Network
    No data leak through
    layers
    

    View Slide

13. Scaling
    Easier to scale IF STATELESS
    

    View Slide

14. Best language
    Choose the best tool And change it later
    

    View Slide

15. Best datastore
    Polyglot persistence Easier to change
    

    View Slide

16. Microservices
    ❖ Fight against two inhibitors:
    ❖ Coupling
    ❖ Entropy
    ❖ To ease innovation and agility
    

    View Slide

17. Challenges Not so fast
    

    View Slide

18. Challenges
    ❖ Service discovery
    ❖ Performance overhead
    ❖ ACID, availability
    ❖ Links
    ❖ Asynchronism
    ❖ Value by service composition
    ❖ Distributed system
    

    View Slide

19. Communication
    ?
    

    View Slide

20. Two patterns
    ❖ Request / Response
    ❖ Publish / Subscribe
    

    View Slide

21. Request / Response
    

    View Slide

22. Publish / Subscribe
    EVENT
    

    View Slide

23. HTTP
    REST
    

    View Slide

24. HTTP
    ❖ Simple
    ❖ Knowledge of scaling, load-balancing and securing
    ❖ Support for every language
    ❖ Basic protocol, so REST is often used
    

    View Slide

25. MQ
    MQ
    

    View Slide

26. Message Queue
    ❖ Simplify the architecture
    ❖ Middleware for every message
    ❖ Need to be made High Available
    

    View Slide

27. Choice
    ❖ Internal competences
    ❖ Needs for performance
    ❖ One choice per pattern
    ❖ Starts with HTTP, use MQ for events
    ❖ P2P vs centralized
    

    View Slide

28. Service discovery
    ?
    

    View Slide

29. Service discovery
    ❖ How to find a peer?
    ❖ How to detect new peer or leaving peers?
    

    View Slide

30. Service discovery solution
    ❖ ZooKeeper
    ❖ Consul
    ❖ Etcd
    ❖ Eureka
    

    View Slide

31. ACID / Availability
    ❖ ACID is hard to ensure in a distributed system
    ❖ Occasion to define which service need ACID or not
    ❖ The number of view might not, the billing yes definitely
    

    View Slide

32. Links
    ❖ No more DB joins
    ❖ Need to switch to applications links
    ❖ Think about graph
    ❖ Links are explicitly costly
    ❖ Play with services boundaries
    

    View Slide

33. Asynchronism
    ❖ With more communication, harder to stay synchronous
    ❖ For a query, may require collaboration of severals micro-
    services
    ❖ Difficulties with HTTP
    ❖ Mandatory for event-driven reactions
    

    View Slide

34. Value by composition
    ❖ « dumb-pipe, smart endpoint »
    ❖ Some value is made by service composition
    ❖ Harder to visualize and think about
    ❖ Need tooling and design upfront
    

    View Slide

35. Distributed system
    ❖ Everything is a distributed system
    ❖ In monolith, easy to forget
    ❖ Network is not resilient
    ❖ Design for failure
    ❖ https://blogs.oracle.com/jag/resource/Fallacies.html
    

    View Slide

36. -Conway’s law
    « organizations which design systems ... are
    constrained to produce designs which are copies of
    the communication structures of these
    organizations »
    

    View Slide

37. Traditional organisation
    

    View Slide

38. Cross-Functionial organisation
    

    View Slide

39. Organisation
    ❖ Each team should manage the service lifetime from
    value definition to production and maintenance, « you
    build it, you run it »
    ❖ Require cross-functional teams
    ❖ Amazon’s Two Pizza Team (i.e. the whole team can be
    fed by two pizzas)
    

    View Slide

40. Prerequisites Don’t shoot
    yourself
    

    View Slide

41. Prerequisites
    ❖ Infrastructure
    ❖ Deployment, monitoring, reporting, debugging
    ❖ Feature re-splitting or refactoring is hard
    ❖ New design methods, DDD, bounded contexts
    

    View Slide

42. MicroServices VS
    Monolith Fight!
    

    View Slide

43. Monolith defenders
    ❖ Most companies don’t need micro-services
    ❖ Etsy, Facebook architecture are monolith at scale
    ❖ Focus on internal architecture first
    

    View Slide

44. Why not both?
    

    View Slide

45. When to micro-services
    

    View Slide

46. MicroServices & Monolith
    ❖ How to evolve?
    ❖ Keep legacy monolith
    ❖ New features as services
    ❖ Static, safe and legacy core
    ❖ Update on just one micro-service
    

    View Slide

47. Micro-services VS SOA
    ❖ « dumb-pipe, smart endpoint »
    ❖ Micro-Services = SOA + DevOPS
    ❖ MicroServices done right
    ❖ Share service orientation
    

    View Slide

48. Community
    ❖ More and more literature
    ❖ More and more open-source projects
    ❖ Document and explicit traps and challenges.
    

    View Slide

49. To continue
    ❖ API / Rest interface
    ❖ Container based deployment
    ❖ Good companion of DevOps / Lean / Agile
    

    View Slide

50. Conclusion
    ❖ Micro-services offer new leads to beat entropy
    ❖ But it’s not free
    ❖ Requires discipline and maturity
    

    View Slide

51. Litterature
    ❖ https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/
    ❖ http://www.occitech.fr/blog/2015/02/les-microservices/
    ❖ http://www.infoq.com/fr/news/2015/02/microservices-sharing-code
    ❖ http://highscalability.com/blog/2014/10/27/microservices-in-production-the-good-the-bad-the-it-
    works.html
    ❖ http://highscalability.com/blog/2015/4/27/how-can-we-build-better-complex-systems-containers-
    microserv.html
    ❖ https://medium.com/s-c-a-l-e/microservices-monoliths-and-laser-nail-guns-how-etsy-finds-the-right-
    focus-in-a-sea-of-cf718a92dc90
    ❖ http://www.jamesward.com/2015/06/08/comparing-application-deployment-2005-vs-2015
    ❖ http://martinfowler.com/articles/microservices.html
    ❖ http://www.touilleur-express.fr/2015/02/25/micro-services-ou-peon-architecture/
    ❖ http://daily.captaindash.com/anti-fragile-microservices-love-stress/
    

    View Slide

52. Litterature II
    ❖ http://www.boundary.com/blog/2014/08/microservices-conways-law/
    ❖ http://www.thoughtworks.com/insights/blog/microservices-nutshell
    ❖ https://speakerdeck.com/tastapod/microservices-software-that-fits-in-your-head
    ❖ http://bravenewgeek.com/from-mainframe-to-microservice-an-introduction-to-
    distributed-systems/
    ❖ http://dejanglozic.com/2014/10/20/micro-services-and-page-composition-
    problem/
    ❖ http://fr.slideshare.net/dbryant_uk/devoxxuk-2015-the-seven-deadly-sins-of-
    microservices-full-version
    ❖ http://martinfowler.com/articles/microservice-testing/
    

    View Slide