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

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

3. 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…

4. WHEN YOU
NEED TO
SCALE
THERE ARE 2 WAYS

5. GROWING AND GROWING
UNTIL YOU EXPLODE OR
BECOME WEIRD

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

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

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

9. IF YOU ONLY SCALE UP,
YOU GONNA HAVE A BAD TIME

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

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

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

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

14. TRUST YOUR
MIDDLEWARE

15. USE AN EVENT BROKER
TO MODULARIZE YOUR
APP

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

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

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

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

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

21. {P, DB, S} aaS
USE OPS FREE SOLUTION TO LEARN
AND START

22. COMMON MISTAKES

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

24. DO NOT USE THE FILE
SYSTEM AS A DATASTORE

25. LOGS IN FILES
I HATE IT

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

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

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

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

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

31. IT’S LIKE MATH FUNCTION

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

33. data will be lost
CODE
WILL
FAIL

34. CAREFUL USE OF
DARK MAGIC

35. DON’T BE THAT GUY

36. DO NOT USE A
TECHNOLOGY BECAUSE
YOU <3 IT OR BECAUSE
IT’S HYPE : USE IT
BECAUSE IT FITS YOUR
NEEDS
BALANCE YOUR LEARNING CURVE WITH
THE TIME SAVED

37. DO NOT CREATE MONSTERS

38. MAKE HARD
COMPUTATION ASYNC

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

40. SMALLEST CODE BASE POSSIBLE
FOR EACH PROGRAM

41. EACH MODULE
IS VIEWED AS
A SERVICE BY
OTHERS
HTTP OR AMQP COMUNICATION
OR AS A CLIENT

42. USE EVENT BROKER TO
MODULARIZE YOUR APP
• AMQP
• Celery
• 0MQ
• Redis
• JMS
• Some case : hadoop, akka…
• …
CRON is not an event queue

43. FOCUS ON THE BEST
TOOL TO SOLVE YOUR
PROBLEM

44. SCALE YOUR TEAM
MODULARIZE YOUR TEAM

45. THE POWER OF
REWRITE EVERYTHING

46. SMALL CODE BASE + MULTIPLE
TECHNOLOGIES =
LEGACY KILLER

47. REWRITE IS QUICK BECAUSE
YOU KNOW ALL THE PROBLEMS
BEFORE IT HAPPENS

48. HAPPY DEVELOPER WORKS BETTER :
ARE YOU HAPPY WHEN YOU START
YOUR IDE?

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

50. USE PROCESS
DEPLOYMENT

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

52. EASY MOVING OR
INCIDENT MANAGEMENT

53. KEEP CALM UNDER FIRE

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

55. TRICK WITH OTHERS PROTOCOLS

56. TRACK BUG & GET METRICS

57. I’m @waxzce on twitter
I’m the CEO of
A PaaS provider, give it a try
;-)
THX FOR LISTENING
& QUESTIONS TIME