1. HOW TO
SCALE YOUR
APP SOME ADVICE FROM
THE GUY WHO HANDLES
YOUR APP UPTIME
QUENTIN ADAM AT SCALA.IO
@WAXZCE
2013

2. MY DAY TO DAY WORK :
CLEVER CLOUD, MAKE YOUR APP RUN
ALL THE TIME

3. THERE ARE 2 WAYS
WHEN YOU
NEED TO
SCALE

4. GROWING AND GROWING
UNTIL YOU EXPLODE OR
BECOME WEIRD

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

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

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

8. SO, HOW TO
SCALE OUT
?
JUST SOME FACTS

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

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

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

12. TRUST YOUR
MIDDLEWARE

13. USE AN EVENT BROKER
TO MODULARIZE YOUR
APP
• AMQP
• Celery
• 0MQ
• Redis
• JMS
• Even some http chunk or websocket
• Some case : hadoop, akka…
• …

14. CRON + FS IS NEITHER AN EVENT
QUEUE NOR A JOB SCHEDULER

15. CHOOSE
YOUR
DATASTORE
WISELY
YOU CAN SHOULD USE MANY DATASTORES

16. DATASTORE CHOICES
ARE DRIVEN BY USAGE
Do I mostly
read or
write ?
Do I need
relational ?
Do I need
concurrent
access ?
Do I need
atomicity of
requests ?
Do I need
big storage
capacity ?
Make
decisions
based on
needs
Do I need
high
availability ?

17. USE ONLINE
DATABASE / BE
READY TO TEST
IN JUST A FEW
MINUTES
NO NEED TO TRASH YOUR COMPUTER

18. COMMON MISTAKES

19. DO NOT USE THE FILE
SYSTEM AS A DATASTORE
File system are POSIX compliant
•
•
•
•
•
POSIX is ACID
POSIX is powerful but is a bottleneck
File System is the nightmare of ops
File System creates coupling (host provider/OS/language)
SPOF-free multi tenant File System is a unicorn
STORE IN DATABASE, OR IN A DATASTORE LIKE
S3/RIAKCS DEDICATED TO FILE MANAGEMENT

20. LOGS IN FILES
I HATE IT

21. USE STREAMING I/O TO
STREAM DATA DIRECTLY
TO DATABASE
HTTP Post data
Temporarily
store as file
or in memory
Store it into
your storage
backend
Say OK to
client

22. USE STREAMING I/O TO
STREAM DATA DIRECTLY
TO DATABASE
HTTP Post data
Directly stream
your data to
Storage
backend
Say OK to
client

23. DO NOT USE
MEMORY AS
DATABASE
LIKE : SHARED / GLOBAL VARIABLE,
CACHE “IN THE CODE”, INTENSIVE
SESSION USAGE…

24. DO NOT USE A VARIABLE
FOR MORE THAN ONE
REQUEST

25. F(X) = X * 2
F(2) = 4
^ WE ASSUME THAT
FOR SAME INPUT, SAME OUTPUT

26. IT’S LIKE MATH FUNCTION
You have to understand that : you’re functional programing addicts ;-)

27. RESPECT HTTP
Example : GET should not change data on server

28. CODE
WILL
FAIL
data will be lost

29. CAREFUL USE OF
DARK MAGIC

30. DO NOT CREATE MONSTERS

31. MAKE HARD
COMPUTATION ASYNC

32. SPLIT THE CODE :
MODULES
• Smallest code
base
• Deploy as
service for
each other
• Focus on best
technology for
a problem

33. SCALE YOUR TEAM
MODULARIZE YOUR TEAM

34. ALWAYS USE A
REVERSE PROXY
Y U NO USE ONE ?

35. DO NOT BUILD “THE
SERVER” WITH NO DOC

36. USE PROCESS
DEPLOYMENT

37. THE GOOD WAY OF
DEPLOY AN APP :
git push

38. EASY MOVING OR
INCIDENT MANAGEMENT

39. KEEP CALM UNDER FIRE

40. TRACK BUG & GET METRICS

41. THX FOR LISTENING
& QUESTIONS TIME
I’m @waxzce on twitter
I’m the CEO of
sponsors
a non exclusive scala PaaS
provider, give it a try ;-)