O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
Microservices Architecture
Nirvana or Nightmare?
About me
christophe.marchal@ilegra.com
@toff63
http://github.com/toff63
http://francesbagual.net
ilegra
SOA Services in 5
minutes
Just another flavor of SOA
SOA isn’t Web Services
Contract Versioning
Service Design
Microservices isn’t
always the best
architecture
Not everybody likes Microservices
Small company
Disruptive Values
Doesn’t really match most of companies
Microservices
Architecture is primarily
to scale people
Scaling people without architecture
In my previous project
Issues
➔ Teams depending from other teams to release
➔ Feature synchronization overhead
➔ Creating stubs to parallelize de...
Scaling Teams
Benefits
➔ Teams are independant
➔ Parallel development and releases
➔ Small teams tend to iterate faster
➔ Easy to experi...
Ownership
Handoff
Client
(Business)
Business
Analyst
Developer QA / Tester Ops
When there is a problem, this is no one baby
Logs written by dev and read by Ops
More services, more problems
Escalation process
TI doesn’t
deliver
Business
Developers
create unstable
software
Operation
Operation is too
slow
Develop...
Management 3.0
You code it, You run it!
Data Architecture
Problem
Potential solution: Product service call other services
● Simple
● Concurrency issue
● Single Responsability
Principle Iss...
Potential solution: Broker
● Single Responsibility
Principle
● Inconsistency
● Concurrency
● Contract issue
● Performance ...
Potential solution: Writes via Message Bus
● Single Responsibility Principle
● Inconsistency
● Concurrency
● Contract
● Co...
CQRS
Shared mutable state ....
Base of Data Architecture == Functional Principles
Immutable Data
Structure
Pure Functions
Eventual Consistency
Operation Overhead
Operability
12 Factors
➔ One codebase tracked in
revision control, many deploys
➔ Explicitly declare and isolate
dependencies
➔ Store ...
Normalization
UI - Service - Data skeleton
Web Server
Services Configuration
Archaius
Spring-Cloud
Services Discovery
Eureka
Mesos DNS
Services calls
Edge Service
Logs
Parser
Log files
Dashboard
Indexer
Monitoring / Tracing
Deploy
Immutable Infrastructure
Platform as a Service
Anti-Fragile
High number of moving part
High number of moving part
Difference between Error and Failure
Impact of a server going down or getting slow?
Impact of a switch going down?
Impact of a datacenter going down?
Impact on the customer?
Failure protection
Failover Strategy
No impact on developers?
Agile Coaching
XP isn’t enough! But is a good start :)
Each service needs it own architecture
Developers need to test more stuff
➔ Unit tests
➔ Functional tests
➔ Contract tests
➔ Backward compatibility tests
➔ Forwa...
Incident Drills
Learning and Teaching Culture
Existing Stacks
Microservice Architecture
Summary
➔ Architecture to scale Teams
➔ Highly Flexible
➔ Highly complex
➔ Ownership using Management 3.0
➔ Development Ma...
Arquitetura orientada a micro serviços: Nirvana ou pesadelo?
Arquitetura orientada a micro serviços: Nirvana ou pesadelo?
Arquitetura orientada a micro serviços: Nirvana ou pesadelo?
Arquitetura orientada a micro serviços: Nirvana ou pesadelo?
Próximos SlideShares
Carregando em…5
×

Arquitetura orientada a micro serviços: Nirvana ou pesadelo?

475 visualizações

Publicada em

Arquitetura orientada a micro serviços está na moda. É fácil achar artigos falando bem desse tipo de arquitetura com todos os seus beneficio. Porém, esse tipo de arquitetura vem com seu conjunto de armadilhas e assume muitas coisas sobre a TI da sua empresa. <br><br>
Nessa palestra mostrarei em quais contextos esse tipo de arquitetura faz sentido, os desafios que vem com ela, o tipo de arquitetura de dados que ela implica e as stacks mais maduras para trabalhar com micro serviços.

Publicada em: Educação
  • Seja o primeiro a comentar

Arquitetura orientada a micro serviços: Nirvana ou pesadelo?

  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

×