Adrian Trenaman from Gilt discussed the evolution of their microservices architecture, highlighting shifts from a monolithic Java application to a more flexible microservices approach using Scala. He outlined several challenges faced, including maintenance of staging environments, service ownership, deployment logistics, and ensuring compliance while enabling engineer autonomy. Gilt is focusing on automation, lightweight RESTful APIs, and improving alerting mechanisms to address these issues and facilitate faster innovation.

1. scaling μ-
services at gilt
ade@gilt.com
Microservices Dublin Meetup,
Engine Yard, Dublin
24th Feb 2015
Adrian Trenaman, VP Engineering, Gilt

2. we source luxury brands and lifestyle goods

3. we shoot the product in our studios

4. we receive

5. we sell every day at noon

6. stampede

7. 2007 - ruby-on-rails monolith

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

9. 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?”

10. 2015: micro-services

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

12. what are all these services doing?

13. lines of code per service

14. # source files per service

15. # running instances per service

16. from bare-metal...
PHX
IAD

17. … to vapour.

18. lift’n’shift + elastic teams

19. AWS instance sizing

20. evolution of architecture and tech organisation

21. Lessen dependencies
between teams: faster code-
to-prod
Lots of initiatives in parallel
Your favourite
<tech/language/framework>
here
We (heart) μ-services
Graceful degradation of
service
Disposable Code: easy to
innovate, easy to fail and
move on.

22. six μ-service
challenges
no one ever said this was gonna be easy

23. 1. staging
We 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.

24. 2. ownership
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.

25. 3. deployment
Services need somewhere to live. We’re
building tooling over docker and AWS to give
elasticity + fast provisioning + service isolation
+ repeatable, immutable deployment.

26. 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
those APIs.

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

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

29. scaling μ-
services at gilt
ade@gilt.com
Microservices Dublin Meetup,
Engine Yard, Dublin
24th Feb 2015
Adrian Trenaman, VP Engineering, Gilt