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!

28.
Data Architecture

29.
Problem

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

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

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

33.
CQRS

34.
Shared mutable state ....

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

36.
Eventual Consistency

37.
Operation Overhead

38.
Operability

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

41.
UI - Service - Data skeleton

42.
Web Server

43.
Services Configuration
Archaius
Spring-Cloud

44.
Services Discovery
Eureka
Mesos DNS

45.
Services calls

46.
Edge Service

47.
Logs
Parser
Log files
Dashboard
Indexer

48.
Monitoring / Tracing

49.
Deploy

50.
Immutable Infrastructure

51.
Platform as a Service

52.
Anti-Fragile

53.
High number of moving part

54.
High number of moving part

55.
Difference between Error and Failure

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

57.
Impact of a switch going down?

58.
Impact of a datacenter going down?

59.
Impact on the customer?

60.
Failure protection

61.
Failover Strategy

62.
No impact on developers?

63.
Agile Coaching

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

65.
Each service needs it own architecture

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

67.
Incident Drills

68.
Learning and Teaching Culture

69.
Existing Stacks

70.
Microservice Architecture

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