Tuesday, October 13, 2015

Microservices Architecture

Microservices Architecture



Microservices Architecture from Izzet Mustafaiev

 Microservices Architecture

  1. 1. μServices Architecture
  2. 2. ● SA at EPAM Systems ● primary skill is Java ● hands-on-coding with Groovy, Ruby ● trying to learn some Scala and Erlang ● passionate about agile, clean code and devops Izzet Mustafayev@EPAM Systems @webdizz webdizz izzetmustafaiev http://webdizz.name
  3. 3. Agenda ● What is this? ● Architecture ● Case study ● Existing tools ● Summary ● How to get there? ● Q&A
  4. 4. ● Small (10-100 LOC) Overview
  5. 5. ● Small (10-100 LOC) ● Lightweight (run several per box) Overview
  6. 6. ● Small (10-100 LOC) ● Lightweight (run several per box) ● Takes strength of platform/language (polyglot) Overview
  7. 7. ● Small (10-100 LOC) ● Lightweight (run several per box) ● Takes strength of platform/language (polyglot) ● Independent (development/deployment) Overview
  8. 8. ● Small (10-100 LOC) ● Lightweight (run several per box) ● Takes strength of platform/language (polyglot) ● Independent (development/deployment) ● Stateless (everything persisted in DB) Overview
  9. 9. ● Small (10-100 LOC) ● Lightweight (run several per box) ● Takes strength of platform/language (polyglot) ● Independent (development/deployment) ● Stateless (everything persisted in DB) ● Monitored (health and business value) Overview
  10. 10. ● Design ● Implementation ● Delivery ● Monitoring Architecture
  11. 11. Design ● What ab SOA? ● Externalize Configuration ● Versioning ● Communication Contract ● Asynchronicity ● Reusability ● Scalability ● Availability
  12. 12. What ab SOA? ● Sensible idea ● Combat challenges of large monolithic applications ● Lack of guidance
  13. 13. Externalize Configuration ● Support for X > 1 environments ● Run-time changes
  14. 14. Versioning ● Leave multiple old microservice versions running ● Fast introduction vs. slow retirement asymmetry
  15. 15. Communication Contract ● Own service - own client ● Thin transport
  16. 16. Asynchronicity ● Non-blocking ● Reactive model ● Messaging to send and forget
  17. 17. Reusability ● Each service does one dedicated thing ● Utilize suitable components/frameworks
  18. 18. ● Cohesive ● Stateless ● Independent Scalability
  19. 19. ● Fault-tolerance ● Introduce failures Availability
  20. 20. Implementation ● Separate Concerns
  21. 21. Separate Concerns ● Inverse Conway’s law – teams own service groups
  22. 22. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice
  23. 23. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice ● One developer independently produces a microservice
  24. 24. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice ● One developer independently produces a microservice ● Each microservice is it’s own build
  25. 25. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice ● One developer independently produces a microservice ● Each microservice is it’s own build ● Stateful cached data access layer
  26. 26. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice ● One developer independently produces a microservice ● Each microservice is it’s own build ● Stateful cached data access layer ● Lightweight mocked dependencies
  27. 27. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice ● One developer independently produces a microservice ● Each microservice is it’s own build ● Stateful cached data access layer ● Lightweight mocked dependencies ● Easy to run locally
  28. 28. Delivery ● Disposability ● Containerisation
  29. 29. ● Build ● Run ● Destroy Disposability
  30. 30. ● Container as deployment artifact ● Environment agnostic ● New version - new container ● All dependencies built in Containerisation
  31. 31. ● Blue-green pattern ● Feature toggle ● Database migration/versioning Zero-down-time
  32. 32. Frequency ● Fast rollouts ● Fast rollbacks
  33. 33. ● Technical ● Business ● Stats Monitoring
  34. 34. ● Hardware monitoring ● Resources utilisation ● Health checking Technical monitoring
  35. 35. ● Business aware metrics ● A/B testing metrics Business monitoring
  36. 36. ● Increased traffic velocity makes individual events less important ● More vertical components requires more measurement ● Failure Rate is more informative than individual failures Stats matter on scale
  37. 37. Benefits
  38. 38. ● Polyglot technology stack ● Polyglot persistence ● Frameworks ● Thin transport Toolset unchained
  39. 39. ● HTTP stack ● Independent provisioning ● Fine tuning ● Elasticity Scalability
  40. 40. ● Development ● Testing ● Deployment ● Reliability Independence
  41. 41. Shortcomings
  42. 42. ● More responsibility from Devs to support Ops Shortcomings
  43. 43. ● More responsibility from Devs to support Ops ● Polyglot infrastructure (if any) Shortcomings
  44. 44. ● More responsibility from Devs to support Ops ● Polyglot infrastructure (if any) ● Orchestration Shortcomings
  45. 45. ● More responsibility from Devs to support Ops ● Polyglot infrastructure (if any) ● Orchestration ● Costs Shortcomings
  46. 46. Twitter before
  47. 47. Twitter now*
  48. 48. Twitter requests
  49. 49. ● Speed wins in the marketplace Lessons learned
  50. 50. ● Speed wins in the marketplace ● Remove friction from product development Lessons learned
  51. 51. ● Speed wins in the marketplace ● Remove friction from product development ● High trust, low process Lessons learned
  52. 52. ● Speed wins in the marketplace ● Remove friction from product development ● High trust, low process ● Freedom and responsibility culture Lessons learned
  53. 53. ● Speed wins in the marketplace ● Remove friction from product development ● High trust, low process ● Freedom and responsibility culture ● Simple patterns automated by tooling Lessons learned
  54. 54. ● Speed wins in the marketplace ● Remove friction from product development ● High trust, low process ● Freedom and responsibility culture ● Simple patterns automated by tooling ● Microservices for speed and availability Lessons learned
  55. 55. ● Speed wins in the marketplace ● Remove friction from product development ● High trust, low process ● Freedom and responsibility culture ● Simple patterns automated by tooling ● Microservices for speed and availability ● Use statistics to monitor behavior Lessons learned
  56. 56. Toolset ● Dropwizard ● Spring Boot ● Vert.X ● More...
  57. 57. Dropwizard http://dropwizard.github.io/dropwizard/ Java framework for developing ops- friendly, high-performance, RESTful web services. - pulls together stable, mature libraries from the Java ecosystem into a simple, light-weight package - has out-of-the-box support for sophisticated configuration, application metrics, logging, operational tools, and much more
  58. 58. Spring Boot http://projects.spring.io/spring-boot/ Takes an opinionated view of building production-ready Spring applications. - favors convention over configuration and is designed to get you up and running as quickly as possible. - production-ready features such as metrics, health checks and externalized configuration
  59. 59. Vert.X http://vertx.io/ ● Lightweight, reactive, application platform ● Superficially similar to Node.js - but not a clone! ● Inspired also from Erlang/OTP ● Polyglot ● High performance ● Simple but not simplistic
  60. 60. More... ● Ratpack http://www.ratpack.io/ ● Sinatra http://www.sinatrarb.com/ ● Webbit https://github.com/webbit/webbit ● Finagle http://twitter.github.io/finagle/ ● Connect http://www.senchalabs.org/connect/ ● XDropWizard https://github.com/timmolter/XDropWizard
  61. 61. Summary
  62. 62. Summary ● Speed wins in the marketplace
  63. 63. Summary ● Speed wins in the marketplace ● Separated concerns at app level
  64. 64. Summary ● Speed wins in the marketplace ● Separated concerns at app level ● Focused and automated
  65. 65. Summary ● Speed wins in the marketplace ● Separated concerns at app level ● Focused and automated ● Elastically scalable
  66. 66. Summary ● Speed wins in the marketplace ● Separated concerns at app level ● Focused and automated ● Elastically scalable ● Polyglot architecture
  67. 67. ● Automate repeating activities ● “Run what you wrote” – root access and duty ● Freedom and responsibility for developers How to get there?
  68. 68. References ● http://martinfowler.com/articles/microservices.html ● http://yobriefca.se/blog/2013/04/28/micro-service- architecture/ ● http://goo.gl/4dOVjj ● http://goo.gl/RGgnd3 ● http://goo.gl/TmZ4Ee ● http://12factor.net/ ● http://goo.gl/tnPxLP
  69. 69. Q&A
  70. 70. Izzet Mustafayev@EPAM Systems @webdizz webdizz izzetmustafaiev http://webdizz.name
at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)