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.

Microservices Architecture: Nirvana or Nightmare

1,240 views

Published on

Microservice oriented architecture is very fashion. It is very easy to find posts describing success story with this kind of architecture. However, this kind of architecture comes with a set of traps and assume a lot of things about your company's IT.

In this task I will show in which context this kind of architecture makes sense, the challenges coming with it, the kind of data architecture it implies and the most mature existing stacks to work with.

Transcript available http://francesbagual.net/2015/11/03/Microservices-architecture-Nirvana-or-Nightmare-part-i.html

Published in: Technology
  • Be the first to comment

Microservices Architecture: Nirvana or Nightmare

  1. 1. Microservices Architecture Nirvana or Nightmare?
  2. 2. About me christophe.marchal@ilegra.com @toff63 http://github.com/toff63 http://francesbagual.net
  3. 3. ilegra
  4. 4. SOA Services in 5 minutes
  5. 5. Just another flavor of SOA
  6. 6. SOA isn’t Web Services
  7. 7. Contract Versioning
  8. 8. Service Design
  9. 9. Microservices isn’t always the best architecture
  10. 10. Not everybody likes Microservices
  11. 11. Small company
  12. 12. Disruptive Values
  13. 13. Doesn’t really match most of companies
  14. 14. Microservices Architecture is primarily to scale people
  15. 15. Scaling people without architecture
  16. 16. In my previous project
  17. 17. Issues ➔ Teams depending from other teams to release ➔ Feature synchronization overhead ➔ Creating stubs to parallelize development ➔ Release synchronization overhead ➔ Impossible to experiment ➔ Very little innovation
  18. 18. Scaling Teams
  19. 19. Benefits ➔ Teams are independant ➔ Parallel development and releases ➔ Small teams tend to iterate faster ➔ Easy to experiment
  20. 20. Ownership
  21. 21. Handoff Client (Business) Business Analyst Developer QA / Tester Ops
  22. 22. When there is a problem, this is no one baby
  23. 23. Logs written by dev and read by Ops
  24. 24. More services, more problems
  25. 25. Escalation process TI doesn’t deliver Business Developers create unstable software Operation Operation is too slow Developer
  26. 26. Management 3.0
  27. 27. You code it, You run it!
  28. 28. Data Architecture
  29. 29. Problem
  30. 30. Potential solution: Product service call other services ● Simple ● Concurrency issue ● Single Responsability Principle Issue ● Inconsistency issue
  31. 31. Potential solution: Broker ● Single Responsibility Principle ● Inconsistency ● Concurrency ● Contract issue ● Performance issue
  32. 32. Potential solution: Writes via Message Bus ● Single Responsibility Principle ● Inconsistency ● Concurrency ● Contract ● Complexity
  33. 33. CQRS
  34. 34. Shared mutable state ....
  35. 35. Base of Data Architecture == Functional Principles Immutable Data Structure Pure Functions
  36. 36. Eventual Consistency
  37. 37. Operation Overhead
  38. 38. Operability
  39. 39. 12 Factors ➔ One codebase tracked in revision control, many deploys ➔ Explicitly declare and isolate dependencies ➔ Store config in the environment ➔ Treat backing services as attached resources ➔ Strictly separate build and run stages ➔ Execute the app as one or more stateless processes ➔ Export services via port binding ➔ Export services via port binding ➔ Scale out via the process model ➔ Maximize robustness with fast startup and graceful shutdown ➔ Keep development, staging, and production as similar as possible ➔ Treat logs as event streams ➔ Run admin/management tasks as one-off processes
  40. 40. Normalization
  41. 41. UI - Service - Data skeleton
  42. 42. Web Server
  43. 43. Services Configuration Archaius Spring-Cloud
  44. 44. Services Discovery Eureka Mesos DNS
  45. 45. Services calls
  46. 46. Edge Service
  47. 47. Logs Parser Log files Dashboard Indexer
  48. 48. Monitoring / Tracing
  49. 49. Deploy
  50. 50. Immutable Infrastructure
  51. 51. Platform as a Service
  52. 52. Anti-Fragile
  53. 53. High number of moving part
  54. 54. High number of moving part
  55. 55. Difference between Error and Failure
  56. 56. Impact of a server going down or getting slow?
  57. 57. Impact of a switch going down?
  58. 58. Impact of a datacenter going down?
  59. 59. Impact on the customer?
  60. 60. Failure protection
  61. 61. Failover Strategy
  62. 62. No impact on developers?
  63. 63. Agile Coaching
  64. 64. XP isn’t enough! But is a good start :)
  65. 65. Each service needs it own architecture
  66. 66. Developers need to test more stuff ➔ Unit tests ➔ Functional tests ➔ Contract tests ➔ Backward compatibility tests ➔ Forward compatibility tests ➔ Stress tests ➔ Chaos tests
  67. 67. Incident Drills
  68. 68. Learning and Teaching Culture
  69. 69. Existing Stacks
  70. 70. Microservice Architecture
  71. 71. Summary ➔ Architecture to scale Teams ➔ Highly Flexible ➔ Highly complex ➔ Ownership using Management 3.0 ➔ Development Mastering using Agile Coaching ➔ Agile deploy thanks to a Platform as a Service ➔ Data Architecture ➔ DevOps

×