2011: java, scala, loosely-typed services
teams focused on
“How can we arrange our teams around
strategic initiatives? How can we make it
fast and easy to get to change to
evolution of architecture and tech organisation
between teams: faster code-
Lots of initiatives in parallel
We (heart) μ-services
Graceful degradation of
Disposable Code: easy to
innovate, easy to fail and
no one ever said this was gonna be easy
We find it hard to maintain staging
environments across multiple teams with lots of
We think TiP is the way to go: invest is
automation, use dark canaries in prod.
Who ‘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.
Services need somewhere to live. We’re
building tooling over docker and AWS to give
elasticity + fast provisioning + service isolation
+ repeatable, immutable deployment.
4. lightweight APIs
We’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
5. audit + alerting
How 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 explosion
Each 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.
services at gilt
Microservices Dublin Meetup,
Engine Yard, Dublin
24th Feb 2015
Adrian Trenaman, VP Engineering, Gilt