Your SlideShare is downloading. ×
0
HOW TO
SCALE YOUR
APP SOME ADVICE FROM
THE GUY WHO HANDLES
YOUR APP UPTIME
QUENTIN ADAM AT SCALA.IO
@WAXZCE

2013
MY DAY TO DAY WORK :
CLEVER CLOUD, MAKE YOUR APP RUN
ALL THE TIME
THERE ARE 2 WAYS

WHEN YOU
NEED TO
SCALE
GROWING AND GROWING
UNTIL YOU EXPLODE OR
BECOME WEIRD
OR SPLIT THE WORK AND
MAKE YOUR SOFTWARE
WORK AS A TEAM
YOU CAN DO BOTH
Build an army of fat app
SO WE NEED TO BE ABLE
TO DISPATCH THE WORK
SCALE OUT

SCALE UP

• Many workers
doing the same
thing

• 1 Fat instance

• 1...
SO, HOW TO
SCALE OUT
?
JUST SOME FACTS
SPLIT PROCESS AND
STORAGE
Storage
• Databases
• Files
• Sessions
• Events
•…

Code
• Can be replicated
• Stateless
• Proce...
STATELESSNESS IS THE KEY
Picking one instance or another doesn’t matter
CONSIDER MORE
THINGS AS DATA
• User account

• Users data
• Files
• Sessions
• Events
TRUST YOUR
MIDDLEWARE
USE AN EVENT BROKER
TO MODULARIZE YOUR
APP
• AMQP

• Celery
• 0MQ
• Redis
• JMS
• Even some http chunk or websocket
• Some...
CRON + FS IS NEITHER AN EVENT
QUEUE NOR A JOB SCHEDULER
CHOOSE
YOUR
DATASTORE
WISELY
YOU CAN SHOULD USE MANY DATASTORES
DATASTORE CHOICES
ARE DRIVEN BY USAGE
Do I mostly
read or
write ?

Do I need
relational ?

Do I need
concurrent
access ?

...
USE ONLINE
DATABASE / BE
READY TO TEST
IN JUST A FEW
MINUTES
NO NEED TO TRASH YOUR COMPUTER
COMMON MISTAKES
DO NOT USE THE FILE
SYSTEM AS A DATASTORE
File system are POSIX compliant

•
•
•
•
•

POSIX is ACID
POSIX is powerful but ...
LOGS IN FILES
I HATE IT
USE STREAMING I/O TO
STREAM DATA DIRECTLY
TO DATABASE

HTTP Post data

Temporarily
store as file
or in memory

Store it in...
USE STREAMING I/O TO
STREAM DATA DIRECTLY
TO DATABASE

HTTP Post data

Directly stream
your data to
Storage
backend

Say O...
DO NOT USE
MEMORY AS
DATABASE
LIKE : SHARED / GLOBAL VARIABLE,
CACHE “IN THE CODE”, INTENSIVE
SESSION USAGE…
DO NOT USE A VARIABLE
FOR MORE THAN ONE
REQUEST
F(X) = X * 2
F(2) = 4

^ WE ASSUME THAT
FOR SAME INPUT, SAME OUTPUT
IT’S LIKE MATH FUNCTION
You have to understand that : you’re functional programing addicts ;-)
RESPECT HTTP
Example : GET should not change data on server
CODE
WILL
FAIL
data will be lost
CAREFUL USE OF
DARK MAGIC
DO NOT CREATE MONSTERS
MAKE HARD
COMPUTATION ASYNC
SPLIT THE CODE :
MODULES
• Smallest code
base

• Deploy as
service for
each other
• Focus on best
technology for
a problem
SCALE YOUR TEAM
MODULARIZE YOUR TEAM
ALWAYS USE A
REVERSE PROXY

Y U NO USE ONE ?
DO NOT BUILD “THE
SERVER” WITH NO DOC
USE PROCESS
DEPLOYMENT
THE GOOD WAY OF
DEPLOY AN APP :

git push
EASY MOVING OR
INCIDENT MANAGEMENT
KEEP CALM UNDER FIRE
TRACK BUG & GET METRICS
THX FOR LISTENING
& QUESTIONS TIME
I’m @waxzce on twitter

I’m the CEO of

sponsors
a non exclusive scala PaaS
provider, g...
Upcoming SlideShare
Loading in...5
×

Some advice from the guy who handle your applications uptime - scalaIO 2013

582

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
582
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Some advice from the guy who handle your applications uptime - scalaIO 2013"

  1. 1. HOW TO SCALE YOUR APP SOME ADVICE FROM THE GUY WHO HANDLES YOUR APP UPTIME QUENTIN ADAM AT SCALA.IO @WAXZCE 2013
  2. 2. MY DAY TO DAY WORK : CLEVER CLOUD, MAKE YOUR APP RUN ALL THE TIME
  3. 3. THERE ARE 2 WAYS WHEN YOU NEED TO SCALE
  4. 4. GROWING AND GROWING UNTIL YOU EXPLODE OR BECOME WEIRD
  5. 5. OR SPLIT THE WORK AND MAKE YOUR SOFTWARE WORK AS A TEAM
  6. 6. YOU CAN DO BOTH Build an army of fat app
  7. 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. 8. SO, HOW TO SCALE OUT ? JUST SOME FACTS
  9. 9. SPLIT PROCESS AND STORAGE Storage • Databases • Files • Sessions • Events •… Code • Can be replicated • Stateless • Process
  10. 10. STATELESSNESS IS THE KEY Picking one instance or another doesn’t matter
  11. 11. CONSIDER MORE THINGS AS DATA • User account • Users data • Files • Sessions • Events
  12. 12. TRUST YOUR MIDDLEWARE
  13. 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. 14. CRON + FS IS NEITHER AN EVENT QUEUE NOR A JOB SCHEDULER
  15. 15. CHOOSE YOUR DATASTORE WISELY YOU CAN SHOULD USE MANY DATASTORES
  16. 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. 17. USE ONLINE DATABASE / BE READY TO TEST IN JUST A FEW MINUTES NO NEED TO TRASH YOUR COMPUTER
  18. 18. COMMON MISTAKES
  19. 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. 20. LOGS IN FILES I HATE IT
  21. 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. 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. 23. DO NOT USE MEMORY AS DATABASE LIKE : SHARED / GLOBAL VARIABLE, CACHE “IN THE CODE”, INTENSIVE SESSION USAGE…
  24. 24. DO NOT USE A VARIABLE FOR MORE THAN ONE REQUEST
  25. 25. F(X) = X * 2 F(2) = 4 ^ WE ASSUME THAT FOR SAME INPUT, SAME OUTPUT
  26. 26. IT’S LIKE MATH FUNCTION You have to understand that : you’re functional programing addicts ;-)
  27. 27. RESPECT HTTP Example : GET should not change data on server
  28. 28. CODE WILL FAIL data will be lost
  29. 29. CAREFUL USE OF DARK MAGIC
  30. 30. DO NOT CREATE MONSTERS
  31. 31. MAKE HARD COMPUTATION ASYNC
  32. 32. SPLIT THE CODE : MODULES • Smallest code base • Deploy as service for each other • Focus on best technology for a problem
  33. 33. SCALE YOUR TEAM MODULARIZE YOUR TEAM
  34. 34. ALWAYS USE A REVERSE PROXY Y U NO USE ONE ?
  35. 35. DO NOT BUILD “THE SERVER” WITH NO DOC
  36. 36. USE PROCESS DEPLOYMENT
  37. 37. THE GOOD WAY OF DEPLOY AN APP : git push
  38. 38. EASY MOVING OR INCIDENT MANAGEMENT
  39. 39. KEEP CALM UNDER FIRE
  40. 40. TRACK BUG & GET METRICS
  41. 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 ;-)
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×