12. 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
13. IF YOU ONLY SCALE UP,
YOU GONNA HAVE A BAD TIME
21. USE AN EVENT BROKER
TO MODULARIZE YOUR
APP
• AMQP
• Celery
• 0MQ
• Redis
• JMS
• Even some http chunk or websocket
• Some case : hadoop, akka…
• …
My talk about rabbitMQ: https://www.youtube.com/watch?v=15mzY2MfDgM&t=3s
22. My talk about rabbitMQ: https://www.youtube.com/watch?v=15mzY2MfDgM&t=3s
CRON + FS IS NEITHER AN EVENT
QUEUE NOR A JOB SCHEDULER
23. BIG CHANGE IN
SOFTWARE INDUSTRY
One instance
One organization
One data repository
One instance
(distributed)
Multiple organization
+ a lot of users
One data repository
YESTEDAY NOW
Multi-tenant
24. INSTANCE FOR ONE
ORGANIZATION
ACID
• Atomicity
• Consistency
• Isolation
• Durability
Powerful
data
management
• Transaction
• User
management
• One above one
Take advantage of ACID
database
27. EXAMPLE : E-SHOP ON
CLASSIC MODE
User A buy a
hdd
Database Transaction :
• Stock management
• Order management
• Invoice generation
• Customer Account reward
• …
Transaction
user A is
processed
Stock &
Order are just
perfectly
synchronize
28. EXAMPLE : E-SHOP ON
CLASSIC MODE
User A buy a
hdd
Database Transaction :
• Stock management
• Order management
• Invoice generation
• Customer Account reward
• …
Transaction
user A is
processed
Stock &
Order are just
perfectly
synchronize
User B buy a
hdd Transaction
user B is
processed
then
29. EXAMPLE : E-SHOP ON
MULTI-TENANT MODE
i.e. : Multiple shop of various sellers on the same instance
30. EXAMPLE : E-SHOP ON
MULTI-TENANT MODE
User A buy a
hdd on seller A
Database Transaction :
• Stock management
• Order management
• Invoice generation
• Customer Account reward
• …
Transaction
user A is
processed
Stock &
Order are just
perfectly
synchronize
User B buy a
book on seller B Transaction
user B is
processed
then
33. 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
?
34. USE ONLINE
DATABASE / BE
READY TO TEST
IN JUST A FEW
MINUTES
NO NEED TO TRASH YOUR COMPUTER
35. {P, DB, S} aaS
USE OPS FREE SOLUTION TO LEARN
AND START
37. 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
40. 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
41. USE STREAMING I/O TO
STREAM DATA DIRECTLY
TO DATABASE
HTTP Post data
Directly stream
your data to
Storage
backend
Say OK to
client
42. DO NOT USE
MEMORY AS
DATABASE
LIKE : SHARED / GLOBAL VARIABLE,
CACHE “IN THE CODE”, INTENSIVE
SESSION USAGE…
43. DO NOT USE A VARIABLE
FOR MORE THAN ONE
REQUEST
44. F(X) = X * 2
F(2) = 4
^ WE ASSUME THAT
FOR SAME INPUT, SAME OUTPUT