Slide 1
Slide 1 text
HOW TO
SCALE YOUR
APP AND WIN
THE CLOUD
CHALLENGE
QUENTIN ADAM
@WAXZCE
2013
Slide 2
Slide 2 text
Quentin ADAM
Clever Cloud CEO
@waxzce on twitter
http://www.waxzce.org
WHO I AM ?
Slide 3
Slide 3 text
Java, scala, python, nodejs, php… apps scaling automatically in the cloud.
We cover your ass, you can focus on your own stuff
http://www.clever-cloud.com
PAAS PROVIDER
Slide 4
Slide 4 text
WHEN YOU
NEED TO
SCALE
THERE ARE 2 WAYS
Slide 5
Slide 5 text
GROWING AND GROWING
UNTIL YOU EXPLODE OR
BECOME WEIRD
Slide 6
Slide 6 text
OR SPLIT THE WORK AND
MAKE YOUR SOFTWARE
WORK AS A TEAM
Slide 7
Slide 7 text
Build an army of fat app
YOU CAN DO BOTH
Slide 8
Slide 8 text
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
Slide 9
Slide 9 text
SO, HOW TO
SCALE
OUT ?
JUST SOME FACTS
Slide 10
Slide 10 text
SPLIT PROCESS AND
STORAGE
Storage
• Databases
• Files
• Sessions
• Events
• …
Code
• Can be replicated
• Stateless
• Process
Slide 11
Slide 11 text
Picking one instance or another doesn’t matter
STATELESSNESS IS THE KEY
Slide 12
Slide 12 text
CONSIDER MORE
THINGS AS DATA
• User account
• Users data
• Files
• Sessions
• Events
Slide 13
Slide 13 text
CHOOSE
DATASTORE
WISELY
YOU CAN SHOULD USE MANY DATASTORES
Slide 14
Slide 14 text
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 ?
Slide 15
Slide 15 text
• Not a big volume
• DB have to manage
data TTL
• Data model : K/V
• Multiple writes at the
same time
• High availability
I need to store sessions
QUICK EXAMPLE
Slide 16
Slide 16 text
• Not a big volume
It’s OK, PG can handle
small quantity of data
• DB have to manage
data TTL
No, I have to do it
manually
• Data model : K/V
No, PG is relational
(mainly)
• Multiple writes at the
same time
No, PG is Atomic
• High availability
PG is awesome ;-) Use
of PG bouncer or
similar allow good
clustering
I need to store sessions
QUICK EXAMPLE
Slide 17
Slide 17 text
• Not a big volume
It’s OK, redis can
handle small quantity
of data
• DB have to manage
data TTL
Yes Redis can do it
• Data model : K/V Yes
• Multiple writes at the
same time
No, redis is pseudo
Atomic (master/slave)
• High availability
Redis is great, but
cauterization is rude…
I need to store sessions
QUICK EXAMPLE
Slide 18
Slide 18 text
• Not a big volume
It’s OK, CB can handle
small quantity of data
• DB have to manage
data TTL
Yes CB can do it
• Data model : K/V Yes
• Multiple writes at the
same time
OK, this is possible
with memcached
protocol
• High availability
Clustering is built in, no
downtime J
I need to store sessions
QUICK EXAMPLE
Slide 19
Slide 19 text
USE ONLINE
DATABASE / BE
READY TO TEST
IN JUST A FEW
MINUTES
NO NEED TO TRASH YOUR COMPUTER
Slide 20
Slide 20 text
DON’T BE THAT GUY
Slide 21
Slide 21 text
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
Slide 22
Slide 22 text
DO NOT CREATE MONSTERS
Slide 23
Slide 23 text
COMMON MISTAKES
Slide 24
Slide 24 text
DO NOT USE
MEMORY AS
DATABASE
LIKE : SHARED / GLOBAL VARIABLE,
CACHE “IN THE CODE”, INTENSIVE
SESSION USAGE…
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
DO NOT USE A VARIABLE
FOR MORE THAN ONE
REQUEST
Slide 27
Slide 27 text
2 + 2 = 4
FOR SAME INPUT, SAME OUTPUT
Slide 28
Slide 28 text
GET do not change data on server
BE HTTP CONSISTENT
Slide 29
Slide 29 text
And data will be lost
CODE WILL FAIL
Slide 30
Slide 30 text
DO NOT USE FILE
SYSTEM AS DATASTORE
File system are POSIX compliant
• POSIX is ACID
• POSIX is powerful but is bottleneck
• File System is nightmare of ops
• File System is create coupling (host provider/OS/language)
• Free SPOF multi tenant File System is a unicorn
STORE IN DATABASE, OR DATASTORE LIKE S3 (AWS)
DEDICATED TO FILE MANAGEMENT
Slide 31
Slide 31 text
CAREFUL USE OF
DARK MAGIC
Slide 32
Slide 32 text
SPLIT THE CODE :
MODULES
• Smallest code
base
• Deploy as
service for
each other
• Focus on best
technology for
a problem
Slide 33
Slide 33 text
SCALE YOUR TEAM
MODULARIZE YOUR TEAM
Slide 34
Slide 34 text
USE EVENT BROKER TO
MODULARIZE YOUR APP
• AMQP
• Celery
• 0MQ
• Redis
• JMS
• Some case : hadoop, akka…
• …
CRON is not an event queue
Slide 35
Slide 35 text
MAKE HARD
COMPUTATION ASYNC
Slide 36
Slide 36 text
ALWAYS USE A
REVERSE PROXY
Y U NOT USE ONE ?
Slide 37
Slide 37 text
DO NOT BUILD “THE
SERVER” WITH NO DOC
Slide 38
Slide 38 text
USE PROCESS
DEPLOYMENT
Slide 39
Slide 39 text
EASY MOVING OR
INCIDENT MANAGEMENT
Slide 40
Slide 40 text
KEEP CALM UNDER FIRE
Slide 41
Slide 41 text
TRACK BUG & GET METRICS
Slide 42
Slide 42 text
Quentin ADAM
Twitter : @waxzce
THX FOR LISTENING
& QUESTIONS TIME
clever
c l o u d