Scaling microservices at Gilt - Adrian Trenaman
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...
PHXIAD
-
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 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 dont automatically detect loops.
-
scaling -services at [email protected] Dublin Meetup, Engine Yard, Dublin24th Feb 2015
Adrian Trenaman, VP Engineering, Gilt