Scaling microservices at Gilt - Adrian Trenaman

of 29 /29
scaling μ- services at gilt [email protected] Microservices Dublin Meetup, Engine Yard, Dublin 24th Feb 2015 Adrian Trenaman, VP Engineering, Gilt

Embed Size (px)

Transcript of Scaling microservices at Gilt - Adrian Trenaman

  • scaling -services at [email protected] Dublin Meetup, Engine Yard, Dublin24th Feb 2015

    Adrian Trenaman, VP Engineering, Gilt

  • we source luxury brands and lifestyle goods

  • we shoot the product in our studios

  • we receive

  • we sell every day at noon

  • stampede

  • 2007 - ruby-on-rails monolith

  • 2011: java, scala, loosely-typed services

    Hidden linkages; buried business logic

    Monolithic Java App; huge bottleneck for innovation.

    lots of duplicated code :(

    teams focused on business lines

    Large loosely-typed JSON/HTTP services

  • enter: -services

    How can we arrange our teams around strategic initiatives? How can we make it fast and easy to get to change to production?

  • 2015: micro-services

  • service growth over time: point of inflexion === scala.

  • what are all these services doing?

  • lines of code per service

  • # source files per service

  • # running instances per service

  • from bare-metal...


  • to vapour.

  • liftnshift + elastic teams

  • AWS instance sizing

  • evolution of architecture and tech organisation

  • Lessen dependencies between teams: faster code-to-prod

    Lots of initiatives in parallel

    Your favourite here

    We (heart) -servicesGraceful degradation of service

    Disposable Code: easy to innovate, easy to fail and move on.

  • six -service challengesno one ever said this was gonna be easy

  • 1. stagingWe find it hard to maintain staging environments across multiple teams with lots of services.

    We think TiP is the way to go: invest is automation, use dark canaries in prod.

  • 2. ownershipWho owns that service? What happens if that person goes away?

    We have chosen for teams and departments to own and maintain their services. No throwing this stuff over the fence.

  • 3. deploymentServices need somewhere to live. Were building tooling over docker and AWS to give

    elasticity + fast provisioning + service isolation + repeatable, immutable deployment.

  • 4. lightweight APIsWeve settled on REST-style APIs.

    Developing Separate interface from implementation; an AVRO for REST (Mike Bryzek, CTO)

    Note: need 'dumb' zero-dependency clients to those APIs.

  • 5. audit + alertingHow do we stay compliant while giving engineers full autonomy in prod?

    Really smart alerting:

    orders[shipTo: US].count.5m == 0

  • 6. io explosionEach service call begets more service calls; some of which are redundant

    This is still a worry for us. We currently dont automatically detect loops.

  • scaling -services at [email protected] Dublin Meetup, Engine Yard, Dublin24th Feb 2015

    Adrian Trenaman, VP Engineering, Gilt