Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Adventures with Microservices


Published on

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

Published in: Technology
  • Be the first to comment

Adventures with Microservices

  1. 1. Adventures with micro-Services by Anand Agrawal @anand_agrawalanandagrawal84
  2. 2. What’s in it for you?
  3. 3. What? Why? How? When?
  4. 4. What are micro services? small independent composable services that do one thing well
  5. 5. What is the right size?
  6. 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. 7. Single responsibility Low coupling, high cohesion Small, well defined interfaces Object Oriented philosophy
  8. 8. “A 100k loc app is just 100 1k loc apps waiting to happen” - Jeff Bay
  9. 9. used micro services?Why we
  10. 10. Once upon a time...
  11. 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. 12. independent small that do one thingcomposable
  13. 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. 14. µService DB µService DB µService DB µService DB
  15. 15. How did we start?
  16. 16. Solve small, valuable problems
  17. 17. Start with plain old services
  18. 18. When a service starts doing too much, extract a smaller one
  19. 19. Orders PaymentsCustomers Legacy Results Order Processing Catalog (Games)
  20. 20. Looks like plain old services, what makes them ‘micro’?
  21. 21. single responsibility 1 service = 1 ‘resource’ (maybe 2!)
  22. 22. How do they communicate? RESTful contracts HTTP + JSON
  23. 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. 24. Orders PaymentsCustomers Communications Legacy Results Order Processing Scheduled Jobs Error reporting Catalog (Games)
  25. 25. Staying productive client gems ruby and rails devops automate, automate, automate feature toggles over branches
  26. 26. How do I make a change and still stay sane?
  27. 27. Test It!
  28. 28. Unit Tests is my object doing what it should?
  29. 29. Contract Tests is my service doing what it should? out of container only test contracts, not implementation
  30. 30. Integration Tests are all my services playing nicely together? testing distributed effects testing async actions
  31. 31. Ship It!
  32. 32. “we’re effectively pushing the complexity from the application into the infrastructure...” - James Lewis
  33. 33. Puppet Solo Provisioning begins at home - Vagrant Puppet scripts goes through CI just like app code ImmutableServer Provisioning
  34. 34. Continuous Integration UI# Services#Test# Puppet#Code# Integra6on# UAT# Performance# Produc6on# 10# 12# 20# 9# 8# 6# 3# Configs# 15# 18# 4b3ee42#
  35. 35. with every checkin... run unit tests run integration tests run acceptance tests build deployable package of the app ship often!!
  36. 36. CI + CD enables single-click deployment so easy, our product owner does it! it just works™ 3 mins to production (~25 servers)
  37. 37. Cost of adding a service? less than a day all the way to production
  38. 38. When to use micro-services?
  39. 39. Tradeoffs benefit cost small units of reuse/maintenance complex infrastructure grow independently learning curve scale independently network overhead independent DB fragmented data
  40. 40. Questions?
  41. 41. Thanks!!