View
150
Download
2
Category
Preview:
Citation preview
scaling μ-services at giltade@gilt.comMicroservices Dublin Meetup, Engine Yard, Dublin24th Feb 2015
Adrian Trenaman, VP Engineering, Gilt
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?”
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.
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.
Recommended