Some advice from the guy who handle your applications uptime - scalaIO 2013
•Download as PPTX, PDF•
3 likes•1,080 views
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Some advice from the guy who handle your applications uptime - scalaIO 2013
Similar to Some advice from the guy who handle your applications uptime - scalaIO 2013 (20)
More from Quentin Adam
More from Quentin Adam (20)
Recently uploaded
Recently uploaded (20)
Some advice from the guy who handle your applications uptime - scalaIO 2013
- 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
- 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
- 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
- 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 ;-)