The document discusses the complexities and benefits of microservices architecture, emphasizing its role in scaling development teams and enabling parallel releases. It highlights challenges such as team dependencies, operational issues, and the necessity of robust testing and operational practices. The author advocates for a structured approach to architecture and management, including principles for improving data architecture and continuous deployment.

1. Microservices Architecture
Nirvana or Nightmare?

2. About me
christophe.marchal@ilegra.com
@toff63
http://github.com/toff63
http://francesbagual.net

3. ilegra

4. SOA Services in 5
minutes

5. Just another flavor of SOA

6. SOA isn’t Web Services

7. Contract Versioning

8. Service Design

9. Microservices isn’t
always the best
architecture

10. Not everybody likes Microservices

11. Small company

12. Disruptive Values

13. Doesn’t really match most of companies

14. Microservices
Architecture is primarily
to scale people

15. Scaling people without architecture

16. In my previous project

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. Scaling Teams

19. Benefits
➔ Teams are independant
➔ Parallel development and releases
➔ Small teams tend to iterate faster
➔ Easy to experiment

20. Ownership

21. Handoff
Client
(Business)
Business
Analyst
Developer QA / Tester Ops

22. When there is a problem, this is no one baby

23. Logs written by dev and read by Ops

24. More services, more problems

25. Escalation process
TI doesn’t
deliver
Business
Developers
create unstable
software
Operation
Operation is too
slow
Developer

26. Management 3.0

27. You code it, You run it!

29. Data Architecture

30. Problem

31. Potential solution: Product service call other services
● Simple
● Concurrency issue
● Single Responsability
Principle Issue
● Inconsistency issue

32. Potential solution: Broker
● Single Responsibility
Principle
● Inconsistency
● Concurrency
● Contract issue
● Performance issue

33. Potential solution: Writes via Message Bus
● Single Responsibility Principle
● Inconsistency
● Concurrency
● Contract
● Complexity

34. CQRS

35. Shared mutable state ....

36. Base of Data Architecture == Functional Principles
Immutable Data
Structure
Pure Functions

37. Eventual Consistency

39. Operation Overhead

40. Operability

41. 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

42. Normalization

43. UI - Service - Data skeleton

44. Web Server

45. Services Configuration
Archaius
Spring-Cloud

46. Services Discovery
Eureka
Mesos DNS

47. Services calls

48. Edge Service

49. Logs
Parser
Log files
Dashboard
Indexer

50. Monitoring / Tracing

51. Deploy

52. Immutable Infrastructure

53. Platform as a Service

55. Anti-Fragile

56. High number of moving part

57. High number of moving part

58. Difference between Error and Failure

59. Impact of a server going down or getting slow?

60. Impact of a switch going down?

61. Impact of a datacenter going down?

62. Impact on the customer?

63. Failure protection

64. Failover Strategy

65. No impact on developers?

66. Agile Coaching

67. XP isn’t enough! But is a good start :)

68. Each service needs it own architecture

69. Developers need to test more stuff
➔ Unit tests
➔ Functional tests
➔ Contract tests
➔ Backward compatibility tests
➔ Forward compatibility tests
➔ Stress tests
➔ Chaos tests

70. Incident Drills

71. Learning and Teaching Culture

72. Existing Stacks

73. Microservice Architecture

74. 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