• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
How to scale your applications ? - #bzhcamp
 

How to scale your applications ? - #bzhcamp

on

  • 411 views

 

Statistics

Views

Total Views
411
Views on SlideShare
411
Embed Views
0

Actions

Likes
1
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • disposable

How to scale your applications ? - #bzhcamp How to scale your applications ? - #bzhcamp Presentation Transcript

  • HOW TO SCALE YOUR APP SOME ADVICE FROM THE GUY WHO HANDLES YOUR APP UPTIME QUENTIN ADAM AT @WAXZCE 2013
  • MY DAY TO DAY WORK : CLEVER CLOUD, MAKE YOUR APP RUN ALL THE TIME
  • 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…
  • 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
  • IF YOU ONLY SCALE UP, YOU GONNA HAVE A BAD TIME
  • 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
  • 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 WISELY YOU 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
  • {P, DB, S} aaS USE OPS FREE SOLUTION TO LEARN AND START
  • 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
  • DO NOT USE THE FILE SYSTEM AS A DATASTORE
  • 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 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 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
  • Example : GET should not change data on server RESPECT HTTP
  • data will be lost CODE WILL FAIL
  • CAREFUL USE OF DARK MAGIC
  • DON’T BE THAT GUY
  • 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
  • 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
  • SMALLEST CODE BASE POSSIBLE FOR EACH PROGRAM
  • EACH MODULE IS VIEWED AS A SERVICE BY OTHERS HTTP OR AMQP COMUNICATION OR AS A CLIENT
  • USE EVENT BROKER TO MODULARIZE YOUR APP • AMQP • Celery • 0MQ • Redis • JMS • Some case : hadoop, akka… • … CRON is not an event queue
  • FOCUS ON THE BEST TOOL TO SOLVE YOUR PROBLEM
  • SCALE YOUR TEAM MODULARIZE YOUR TEAM
  • THE POWER OF REWRITE EVERYTHING
  • SMALL CODE BASE + MULTIPLE TECHNOLOGIES = LEGACY KILLER
  • REWRITE IS QUICK BECAUSE YOU KNOW ALL THE PROBLEMS BEFORE IT HAPPENS
  • HAPPY DEVELOPER WORKS BETTER : ARE YOU HAPPY WHEN YOU START YOUR IDE?
  • 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
  • ALWAYS USE A REVERSE PROXY Y U NO USE ONE ?
  • TRICK WITH OTHERS PROTOCOLS
  • TRACK BUG & GET METRICS
  • I’m @waxzce on twitter I’m the CEO of A PaaS provider, give it a try ;-) THX FOR LISTENING & QUESTIONS TIME