some advice from the guy who handle your applications uptime - scalaio 2013

HOW TO SCALE YOUR APP SOME ADVICE FROM THE GUY WHO HANDLES YOUR APP UPTIME

QUENTIN ADAM AT SCALA.IO

@WAXZCE2013

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

WHEN YOU NEED TO SCALE

THERE ARE 2 WAYS

GROWING AND GROWING UNTIL YOU EXPLODE OR BECOME WEIRD

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

Build an army of fat app

YOU CAN DO BOTH

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

BEST LONG

TERM

SOLUTION

SO, HOW TO SCALE OUT ?JUST SOME FACTS

SPLIT PROCESS AND STORAGE

Storage• Databases• Files• Sessions• Events• …

Code• Can be replicated• Stateless• Process

Picking one instance or another doesn’t matter

STATELESSNESS IS THE KEY

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 case : hadoop, akka…

• …

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

CHOOSE YOUR DATASTORE WISELYYOU CAN SHOULD USE MANY DATASTORES

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 ?

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

LOGS IN FILES I HATE IT

USE STREAMING I/O TO STREAM DATA DIRECTLY TO DATABASE

HTTP Post dataTemporarily store as file

or in memory

Store it into your storage

backend

Say OK to client

USE STREAMING I/O TO STREAM DATA DIRECTLY TO DATABASE

HTTP Post data

Directly stream your data to

Storage backend

Say OK to client

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

DO NOT USE A VARIABLE FOR MORE THAN ONE REQUEST

F(X) = X * 2F(2) = 4^ WE ASSUME THATFOR SAME INPUT, SAME OUTPUT

You have to understand that : you’re functional programing addicts ;-)

IT’S LIKE MATH FUNCTION

Example : GET should not change data on server

RESPECT HTTP

data will be lost

CODE WILL FAIL

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 TEAMMODULARIZE 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

I’m @waxzce on twitter

I’m the CEO of

a non exclusive scala PaaS provider, give it a try ;-)

THX FOR LISTENING & QUESTIONS TIME

sponsors