Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices @BlaBlaCar

Microservices @BlaBlaCar

A presentation about microservices at BlaBlaCar.

Talk given at sfPot March 2015 at SensioLabs

Olivier Dolbeau

March 17, 2015
Tweet

More Decks by Olivier Dolbeau

Other Decks in Programming

Transcript

  1. What’s the v3? • after the v2 (thanks cap’tain obvious!)

    • Full sf2 application • contains EVERYTHING ◦ web ◦ admin ◦ workers ◦ dead code ◦ ...
  2. 18 août 2011 First commit 6 days after: Steve Jobs

    resigns as the CEO of Apple Inc.
  3. Thanks v3 • Pragmatic! • Everything in the same place

    • only one application to deploy • only one application to explain to newcomers (even if a lot of time is needed to understand everything) It was a good choice at this moment.
  4. 24 906 Commits There is “only” 15 506 commits for

    symfony/symfony There is “only” 10 228 commits for joyent/node There is “only” 9 266 commits for twbs/bootstrap There is 44 809 commits for rails/rails (but it’s ruby… #troll)
  5. Problems of a very huge code base • Very (VERY)

    Hard to maintain • Deployment process (including tests) is too long
  6. Definition “In computing, microservices is a software architecture design pattern,

    in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task.” You know from where comes this definition
  7. How? Workers first. • mail • sms • user-action •

    … We now have 60+ workers in… 60+ git repositories.
  8. Pros • easy to: ◦ understand ◦ write / launch

    tests ◦ deploy • always the same code base: ◦ same command to consume ◦ same deployment script ◦ … • We made OSS: swarrot/swarrot
  9. Cons • process: ◦ new repo ◦ new build plan

    in bamboo ◦ a bit of chef for deployment • new side projects: ◦ to configure our broker (Rabbit) ◦ to deal with configuration • increase ops complexity
  10. Think global! • Multi DC. \o/ • Need to split

    data across the world. • Need to shard data.
  11. How to shard users? You gonna hate Doctrine ORM. You

    gonna hate all your listeners. You gonna hate everyone.
  12. Goals • identify & isolate the business logic • identify

    & isolate data calls • without rewriting the whole application • without impacting the actual delivery • must be usable everywhere (not only in our main application) Do what we want with our data and our business
  13. Implementation Strict separation of concerns • business • data One

    repository for everything • tried with more => complex for development • still easily splittable
  14. Data • 1 interface. Can have several implementations. • easy

    to ◦ add cache ◦ change backend ◦ shard data • Strict rules: ◦ findOne* => return an array or throw exception ◦ findBy* => return an Adapter ◦ ...
  15. • Lots of entry points! (called “action”) • Request /

    Response / Handler pattern • Flat request / response => no objects. \o/ • can call 0-n times the data layer. Business
  16. • concise • event dispatched into RabbitMQ • We always

    have a response object or an exception. No more null everywhere. \o/
  17. Pros • Separation of concern • The ability to isolate

    anything! • strict rules (exceptions & co) • easy to understand
  18. Cons • versioning • applications updates • new side projects

    (again) ◦ to deal with fixtures • kind of duplicate code
  19. Facts • Need to deploy the whole application • 1

    bundle • 54 controllers • 36 957 NLOC • Lot of shared code • Can break the website
  20. Goal • Several independent applications • Centralized application to handler

    permissions / connection • A bit like SensioConnect for all Sensio products
  21. The silver bullet doesn’t exist! Microservices comes with several drawbacks

    but it is worth it! We will continue to move forward We need your help! ;)