Some advice from the guy who handle your applications uptime - scalaIO 2013
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 754 views

 

Statistics

Views

Total Views
754
Views on SlideShare
749
Embed Views
5

Actions

Likes
2
Downloads
6
Comments
0

1 Embed 5

https://twitter.com 5

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

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

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