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. KEEP YOUR APPS ONLINE. MADE WITH
NODE.JS, SCALA, JAVA, RUBY, PHP,
PYTHON, GO…
Cloud & on premise ;-)

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

6. GIVE BACK TO THE COMMUNITY
NEVER
GONNA
LET YOU
DOWN
clever-cloud.com

7. WHEN YOU
NEED TO
SCALE
THERE ARE 2 WAYS

8. GROWING AND GROWING
UNTIL YOU EXPLODE OR
BECOME WEIRD

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

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

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

12. SCALE OUT

13. CREATE PARALLEL
WORK UNIT

14. CPU:
MANY CORES

15. APPS:
CLUSTERING

16. TEAM:
MICROSERVICE

17. SYNCHRONIZE
ACCESS TO
THE DATA BY
THE ACTORS

18. DATA MANAGEMENT
IS MANDATORY

19. ACCESS TO THE DATA IN A MUTABLE
STATE

20. MAKE EVERYBODY WORKS

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

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

23. IS THE
DATA
READABLE?

24. FIX STATE OF
THE DATA TO
ENSURE
ACCESSIBILITY

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

26. FIX THE DATA
IN A
IMMUTABLE
STATE

27. AVOID HISTORY

28. EXAMPLE ON COLLECTIONS
MANAGEMENT

29. CLASSICAL ITERATION WITH
LOOPS

30. FUNCTIONAL PROGRAMMING
MAP USING LAMBDA

31. EPHEMERAL
COPY

32. IMMUTABLE COLLECTION
+
JAVA 8 LAMBDA

33. DETERMINED
SCENARIO

34. RAM & SPACE

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

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

37. DATA QUALIFICATION

38. Data
Process
data
Data
pipeline

39. IMMUTABILITY
FOR YOUR
CODE

40. IMMUTABILITY
AS A PATTERN

41. LET’S TALK ABOUT
INFRASTRUCTURE

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

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

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

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

46. CREATE HISTORY

47. DOCUMENTATION

48. SPECIFIC

49. TAYLOR MADE

50. NOT ABLE TO SCALE

51. DO NOT
CREATE
HISTORY

52. EPHEMERAL
SERVERS?

53. IMMUTABLE
INFRASTRUCTURE

54. THERE IS ONE PROCESS:
BUILD

55. THEN, REGISTER

56. AND LIVE WITHOUT DATA

57. AND DIE WHEN MORE
UPDATED VERSION IS THERE

58. TRASH OLD VERSION

59. HOW TO MANAGE DATA?

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

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

62. FULLY AUTOMATED HOSTING FACTORY

63. PRODUCTION HAS TO BE PERFECT

64. PEOPLE ARE NOT PERFECT

65. PEOPLE HAVE NOTHING TO DO ON
PRODUCTION STUFF

66. ULTRON

67. AT CLEVER CLOUD SSH CONNECTION
IS A RED ALERT

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

69. APP FAIL?
REDEPLOY
NEW
INSTANCE

70. OPERATION
SYSTEM
UPDATE ?
REDEPLOY
NEW
INSTANCE

71. REBALANCE
HARDWARE
ALLOCATION?
REDEPLOY
NEW
INSTANCE

72. PREDICABLE
FAIL OF THE
APPLICATION?
REDEPLOY
NEW
INSTANCE

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

74. BECAUSE YOU WILL NOT RELY
ON A SERVER ANYMORE

75. CREATE A FACTORY OF INSTANCE

76. BE CONSISTENT AND PREDICTABLE

77. SERVICE
UPTIME
!=
SERVER
UPTIME

78. NO MORE OLYMPIC CONTEST ON
UPTIME

79. DOES IT
APPLY ON
DATA?

80. BASIC NOSQL VISION:
STORE EVERYTHING

81. NO MORE
DELETE OR
UPDATE

82. CQRS?
IMMUTABLE
DB?

83. BTRFS
COPY ON WRITE

84. Because history matter
GIT

85. THINK

86. IMMUTABILITY

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

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

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