I have spent some time working on a project, and built 8 micro services and 2 applications, and planned to carve out a few more. Deployment was carried out in a farm of 25 servers in production with a single click in less than 3 minutes. This presentation is about the experiences with building a micro service based architecture - the good, the bad and the ugly. - What are micro services? - When/Why/How micro services? - Why NOT micro services? - Managing Continuous Integration and Continuous Delivery with micro services - A few design principles that we followed and that worked for us

1. Adventures
with
micro-Services
by Anand Agrawal
@anand_agrawalanandagrawal84

2. What’s in it for you?

3. What?
Why?
How?
When?

4. What are micro services?
small independent composable
services
that do one thing well

5. What is the right size?

6. Unix philosophy
Write programs that do one thing well.
Write programs that work together.
cat | grep | sed | awk | ...
HTTP is the new pipe!

7. Single responsibility
Low coupling, high cohesion
Small, well defined interfaces
Object Oriented philosophy

8. “A 100k loc app is
just 100 1k loc apps
waiting to happen”
- Jeff Bay

9. used micro services?Why we

10. Once upon a time...

11. lots of legacy, no reuse
not flexible, high cost of change
concentrated complexity
no one knows how it works
90 year old business

12. independent small that do one thingcomposable

13. Adventure so far
25 VM’s in production
10 micro-services
one click deployment
60+ VM’s across environments
guess who does the deployments?

14. µService
DB
µService
DB
µService
DB
µService
DB

15. How did we start?

16. Solve small, valuable problems

17. Start with plain old services

18. When a service starts doing too much,
extract a smaller one

19. Orders PaymentsCustomers
Legacy Results
Order
Processing
Catalog
(Games)

20. Looks like plain old services,
what makes them ‘micro’?

21. single responsibility
1 service = 1 ‘resource’
(maybe 2!)

22. How do they communicate?
RESTful contracts
HTTP + JSON

23. Thumb Rules
1 top level resource (2 at most)
bounded contexts
focus on contracts
extract cross cutting concerns
avoid coupling
sophisticated logging and monitoring

24. Orders PaymentsCustomers
Communications
Legacy Results
Order
Processing
Scheduled
Jobs
Error
reporting
Catalog
(Games)

25. Staying productive
client gems
ruby and rails
devops
automate, automate, automate
feature toggles over branches

26. How do I make a change
and still stay sane?

27. Test It!

30. Unit Tests
is my object doing what it should?

31. Contract Tests
is my service doing what it should?
out of container
only test contracts, not implementation

32. Integration Tests
are all my services playing nicely together?
testing distributed effects
testing async actions

33. Ship It!

34. “we’re effectively pushing the
complexity from the application
into the infrastructure...”
- James Lewis

35. Puppet Solo
Provisioning begins at home - Vagrant
Puppet scripts goes through CI just like app code
ImmutableServer
Provisioning

36. Continuous Integration
UI# Services#Test# Puppet#Code#
Integra6on#
UAT#
Performance#
Produc6on#
10# 12# 20#
9#
8#
6#
3#
Configs#
15# 18#
4b3ee42#

37. with every checkin...
run unit tests
run integration tests
run acceptance tests
build deployable package of the app
ship often!!

38. CI + CD
enables
single-click deployment
so easy, our product owner does it!
it just works™
3 mins to production (~25 servers)

39. Cost of adding a service?
less than a day
all the way to production

40. When to use micro-services?

41. Tradeoffs
benefit cost
small units of reuse/maintenance complex infrastructure
grow independently learning curve
scale independently network overhead
independent DB fragmented data

42. Questions?

43. Thanks!!