Scaling micro services at gilt

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

PHXIAD

… to vapour.

lift’n’shift + 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 <tech/language/framework> 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. We’re building tooling over docker and AWS to give

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

4. lightweight APIsWe’ve settled on REST-style APIs.

Developing http://apidoc.me. 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: http://cavellc.github.io

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 don’t automatically detect loops.

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

Adrian Trenaman, VP Engineering, Gilt