The all functional programming world, Docker, Clever Cloud, micro service architecture, logs append only DB… All of this rely on the immutability at some point: infrastructure immutability, data immutability, append only. This is the way we now build some of the best scalable applications and infrastructure. The talk is made to understand why Immutability rules the scalability and why it’s important.

1. IMMUTABILITY, FROM
CODE TO
INFRASTRUCTURE,
THE WAY OF
SCALABILITY
@WAXZCE
QUENTIN ADAM AT

2. Quentin ADAM from the Clever Cloud
@waxzce on twitter – github- soundcloud – instagram ….
WHO AM I ?

3. MY DAY TO DAY WORK :
CLEVER CLOUD, THE IT
AUTOMATION COMPANY

4. And learn a lot of things about your code, apps, and good/bad design…
KEEP YOUR APPS ONLINE. MADE WITH
NODE.JS, SCALA, JAVA, RUBY, PHP,
PYTHON, GO…

5. AND LEARN A LOT OF THINGS ABOUT
YOUR CODE, APPS, AND GOOD/BAD
DESIGN…

6. WHEN YOU
NEED TO
SCALE
THERE ARE 2 WAYS

7. GROWING AND GROWING
UNTIL YOU EXPLODE OR
BECOME WEIRD

8. OR SPLIT THE WORK AND
MAKE YOUR SOFTWARE
WORK AS A TEAM

9. Build an army of fat app
YOU CAN DO BOTH

10. SO WE NEED TO BE ABLE
TO DISPATCH THE WORK
SCALE OUT
• Many workers
doing the same
thing
• No SPOF
• Growing is more
easy
• Introduce best
practice
SCALE UP
• 1 Fat instance
• 1 Fat application
• SPOF (single point
of failure)
• Hard to maintain
• Always has a limit
• Short term
meaning

11. SCALE OUT

12. CREATE PARALLEL
WORK UNIT

13. CPU:
MANY CORES

14. APPS:
CLUSTERING

15. TEAM:
MICROSERVICE

16. SYNCHRONIZE
ACCESS TO
THE DATA BY
THE ACTORS

17. DATA MANAGEMENT
IS MANDATORY

18. ACCESS TO THE DATA IN A MUTABLE
STATE

19. MAKE EVERYBODY WORKS

20. CONSIDER
VARIABLE OR
VM AS A
“DATA BOX”

21. POSSIBLE STATE IN A
MUTABLE STATE
reading
value
updating
value at a
particular
version
nothing
lock by a
editor
History …

22. IS THE
DATA
READABLE?

23. FIX STATE OF
THE DATA TO
ENSURE
ACCESSIBILITY

24. POSSIBLE STATE IN
AN IMMUTABLE STATE
defined
undefined
Very simple to predicate

25. FIX THE DATA
IN A
IMMUTABLE
STATE

26. AVOID HISTORY

27. EXAMPLE ON COLLECTIONS
MANAGEMENT

28. CLASSICAL ITERATION WITH
LOOPS

29. FUNCTIONAL PROGRAMMING
MAP USING LAMBDA

30. EPHEMERAL
COPY

31. IMMUTABLE COLLECTION
+
JAVA 8 LAMBDA

32. DETERMINED
SCENARIO

33. RAM & SPACE

34. SPLIT PROCESS AND
STORAGE
Storage
• Databases
• Files
• Sessions
• Events
• …
Code
• Can be replicated
• Stateless
• Process

35. CONSIDER MORE
THINGS AS DATA
• User account
• Users data
• Files
• Sessions
• Events

36. DATA QUALIFICATION

37. Data
Process
data
Data
pipeline

38. IMMUTABILITY
FOR YOUR
CODE

39. IMMUTABILITY
AS A PATTERN

40. LET’S TALK ABOUT
INFRASTRUCTURE

41. 40 times in 5 years price drop of AWS
SERVERS COSTS ARE GOING DOWN

42. Google I/O 2015
“RACE TO ZERO”
I.E THE SERVER IS FREE

43. In fact, all you have is…
COOL.
YOU HAVE A SERVER.

44. HOSTING
Backup Updates Certification
Agreement Process Provisioning
Security
Hardware
maintenance

45. CREATE HISTORY

46. DOCUMENTATION

47. SPECIFIC

48. TAYLOR MADE

49. NOT ABLE TO SCALE

50. DO NOT
CREATE
HISTORY

51. EPHEMERAL
SERVERS?

52. IMMUTABLE
INFRASTRUCTURE

53. THERE IS ONE PROCESS:
BUILD

54. THEN, REGISTER

55. AND LIVE WITHOUT DATA

56. AND DIE WHEN MORE
UPDATED VERSION IS THERE

57. TRASH OLD VERSION

58. HOW TO MANAGE DATA?

59. SPLIT DATA AND PROCESS:
FS COMPOSITION
Runtime
• local
• replicable
• updated
Data
• file system
• block storage
• replicated
• copy on write?

60. VM, docker, kubernetes, puppet, ansible, vmware… This is not the problem
TECHNOLOGIES?

61. FULLY AUTOMATED HOSTING FACTORY

62. PRODUCTION HAS TO BE PERFECT

63. PEOPLE ARE NOT PERFECT

64. PEOPLE HAVE NOTHING TO DO ON
PRODUCTION STUFF

65. ULTRON

66. AT CLEVER CLOUD SSH CONNECTION
IS A RED ALERT

67. AN INSTANCE IS DEAD OR ALIVE AND
THAT’S ALL

68. APP FAIL?
REDEPLOY
NEW
INSTANCE

69. OPERATION
SYSTEM
UPDATE ?
REDEPLOY
NEW
INSTANCE

70. REBALANCE
HARDWARE
ALLOCATION?
REDEPLOY
NEW
INSTANCE

71. PREDICABLE
FAIL OF THE
APPLICATION?
REDEPLOY
NEW
INSTANCE

72. Picking one instance or another doesn’t matter
STATELESSNESS IS THE KEY

73. BECAUSE YOU WILL NOT RELY
ON A SERVER ANYMORE

74. CREATE A FACTORY OF INSTANCE

75. BE CONSISTENT AND PREDICTABLE

76. SERVICE
UPTIME
!=
SERVER
UPTIME

77. NO MORE OLYMPIC CONTEST ON
UPTIME

78. DOES IT
APPLY ON
DATA?

79. BASIC NOSQL VISION:
STORE EVERYTHING

80. NO MORE
DELETE OR
UPDATE

81. CQRS?
IMMUTABLE
DB?

82. BTRFS
COPY ON WRITE

83. Because history matter
GIT

84. THINK

85. IMMUTABILITY

86. IMMUTABILITY : NEVER DELETE,
ALWAYS CLONE, BE STATELESS

87. AND LOG ALL TO GET AN EVENT
STREAM ;-)

88. I’m on twitter : @waxzce
quentin.adam@clever-cloud.com
THANK YOU !
ANY QUESTIONS ?
Clever Cloud gift coupon:
BZHCAMP16