Successfully reported this slideshow.
Your SlideShare is downloading. ×

Building Resilient Microservices

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 29 Ad

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Building Resilient Microservices (20)

More from IndicThreads (20)

Advertisement

Recently uploaded (20)

Building Resilient Microservices

  1. 1. Building Resilient Microservices Gurpreet S. Sachdeva Aricent
  2. 2. Who AM I? • Java / Cloud Technology Enthusiast • Director – Technology @ Aricent, Gurgaon • Co-Founder Delhi/NCR JUG • I blog @ www.thistechnologylife.com • Java Code Geek partner • @gssachdeva • https://www.linkedin.com/in/gurpreets
  3. 3. Microservices Evolution https://www.morpheusdata.com/blog/2014-10-24-the-new-rea
  4. 4. What Exactly is a Microservice The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data. http://martinfowler.com/articles/microservices.html
  5. 5. Microservice Properties
  6. 6. Microservice Polyglot Architecture
  7. 7. OPERATIONAL MATURITY IS VITAL http://martinfowler.com/bliki/MicroservicePrereq uisites.html • Not all monoliths are bad applications
  8. 8. Traditional Application Architecture • Easy to • Develop, Test, Deploy
  9. 9. Scale Cube
  10. 10. Y-Axis Scaling • Apply X-axis and Z-axis scaling to each service independently • Partitioning Strategies • Noun • Verb • SRP • Unix Utilities
  11. 11. Conway’s Law “Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” -Melvin Conway, 1968 Can your teams be organized around microservices
  12. 12. Popular Examples http://techblog.netflix.com ~ 600 services http://highscalability.com/amazon- architecture 100-150 services to build a page http://www.addsimplicity.com/downlo ads/eBaySDForum2006-11-29.pdf http://queue.acm.org/detail.cfm? id=1394128
  13. 13. Monolith First http://martinfowler.com/bliki/MonolithFirst.html
  14. 14. Microservices – Inner & Outer Architecture
  15. 15. Microservices – Inner & Outer Architecture
  16. 16. Facets of Monitoring
  17. 17. 12 Factor App Principles
  18. 18. Design for Failure • Failure will ALWAYS occur • Dependent services may be unavailable or too slow to respond • Horizontal clustering • Resilience Patterns to the rescue • CicuitBreaker, Bulkhead, Caching, Timeout, Retry, Messaging, etc.
  19. 19. Netflix OSS Projects Over 100 NetflixOSS projects @ netflix.github.com
  20. 20. Cloud Foundry to Rescue • Many moving parts • Orchestration => Cloud Foundry
  21. 21. Data Strategy • Multiple microservices NOT to share the same database model and perform updates on it • Separation of at least read/write access • Ideally: Separate data stores for each service
  22. 22. Inter-Service Communication • In a monolith architecture, most of the communication is synchronous • Synchronous communication • Mostly REST is used, Other choices: Protocol Buffers, thrift • May require asynchronous communication as well • ZeroMQ, RabbitMQ, Kafka
  23. 23. How to Test? http://martinfowler.com/articles/microservice-testing
  24. 24. Continuous Delivery • Reliable Software Releases through Build, Test and Deployment Automation • DONE = Shippable into Production
  25. 25. Continuous Integration Tool Set
  26. 26. Prepare for DevOps Devops (From Verticals to collaborative teams)
  27. 27. Spring Boot • Opinionated Spring application architecture - Convention over Configuration • Production-ready features, externalized configuration, metrics and health checks • Spring Cloud – Umbrella project for cloud connectors, on top of Spring Boot
  28. 28. Take Aways Microservices aren’t micro! Everything comes at a price No framework is a silver bullet
  29. 29. THANK YOU

Editor's Notes

  • Problem starts when
    Technical debt builds up
    Hard to change without breaking stuff
    Expensive QA & test cycles
    Long term commitment to a technology stack

×