Your SlideShare is downloading. ×
How to scale your applications ? - #bzhcamp
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

How to scale your applications ? - #bzhcamp

510

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
510
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • disposable
  • Transcript

    • 1. HOW TO SCALE YOUR APP SOME ADVICE FROM THE GUY WHO HANDLES YOUR APP UPTIME QUENTIN ADAM AT @WAXZCE 2013
    • 2. MY DAY TO DAY WORK : CLEVER CLOUD, MAKE YOUR APP RUN ALL THE TIME
    • 3. 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…
    • 4. WHEN YOU NEED TO SCALE THERE ARE 2 WAYS
    • 5. GROWING AND GROWING UNTIL YOU EXPLODE OR BECOME WEIRD
    • 6. OR SPLIT THE WORK AND MAKE YOUR SOFTWARE WORK AS A TEAM
    • 7. Build an army of fat app YOU CAN DO BOTH
    • 8. 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
    • 9. IF YOU ONLY SCALE UP, YOU GONNA HAVE A BAD TIME
    • 10. SO, HOW TO SCALE OUT ? JUST SOME FACTS
    • 11. SPLIT PROCESS AND STORAGE Storage • Databases • Files • Sessions • Events • … Code • Can be replicated • Stateless • Process
    • 12. Picking one instance or another doesn’t matter STATELESSNESS IS THE KEY
    • 13. CONSIDER MORE THINGS AS DATA • User account • Users data • Files • Sessions • Events
    • 14. TRUST YOUR MIDDLEWARE
    • 15. USE AN EVENT BROKER TO MODULARIZE YOUR APP
    • 16. USE AN EVENT BROKER TO MODULARIZE YOUR APP • AMQP • Celery • 0MQ • Redis • JMS • Even some http chunk or websocket • Some case : hadoop, akka… • …
    • 17. CRON + FS IS NEITHER AN EVENT QUEUE NOR A JOB SCHEDULER
    • 18. CHOOSE YOUR DATASTORE WISELY YOU CAN SHOULD USE MANY DATASTORES
    • 19. 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 ?
    • 20. USE ONLINE DATABASE / BE READY TO TEST IN JUST A FEW MINUTES NO NEED TO TRASH YOUR COMPUTER
    • 21. {P, DB, S} aaS USE OPS FREE SOLUTION TO LEARN AND START
    • 22. COMMON MISTAKES
    • 23. 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
    • 24. DO NOT USE THE FILE SYSTEM AS A DATASTORE
    • 25. LOGS IN FILES I HATE IT
    • 26. 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
    • 27. USE STREAMING I/O TO STREAM DATA DIRECTLY TO DATABASE HTTP Post data Directly stream your data to Storage backend Say OK to client
    • 28. DO NOT USE MEMORY AS DATABASE LIKE : SHARED / GLOBAL VARIABLE, CACHE “IN THE CODE”, INTENSIVE SESSION USAGE…
    • 29. DO NOT USE A VARIABLE FOR MORE THAN ONE REQUEST
    • 30. F(X) = X * 2 F(2) = 4 ^ WE ASSUME THAT FOR SAME INPUT, SAME OUTPUT
    • 31. IT’S LIKE MATH FUNCTION
    • 32. Example : GET should not change data on server RESPECT HTTP
    • 33. data will be lost CODE WILL FAIL
    • 34. CAREFUL USE OF DARK MAGIC
    • 35. DON’T BE THAT GUY
    • 36. 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
    • 37. DO NOT CREATE MONSTERS
    • 38. MAKE HARD COMPUTATION ASYNC
    • 39. SPLIT THE CODE : MODULES • Smallest code base • Deploy as service for each other • Focus on best technology for a problem
    • 40. SMALLEST CODE BASE POSSIBLE FOR EACH PROGRAM
    • 41. EACH MODULE IS VIEWED AS A SERVICE BY OTHERS HTTP OR AMQP COMUNICATION OR AS A CLIENT
    • 42. USE EVENT BROKER TO MODULARIZE YOUR APP • AMQP • Celery • 0MQ • Redis • JMS • Some case : hadoop, akka… • … CRON is not an event queue
    • 43. FOCUS ON THE BEST TOOL TO SOLVE YOUR PROBLEM
    • 44. SCALE YOUR TEAM MODULARIZE YOUR TEAM
    • 45. THE POWER OF REWRITE EVERYTHING
    • 46. SMALL CODE BASE + MULTIPLE TECHNOLOGIES = LEGACY KILLER
    • 47. REWRITE IS QUICK BECAUSE YOU KNOW ALL THE PROBLEMS BEFORE IT HAPPENS
    • 48. HAPPY DEVELOPER WORKS BETTER : ARE YOU HAPPY WHEN YOU START YOUR IDE?
    • 49. DO NOT BUILD “THE SERVER” WITH NO DOC
    • 50. USE PROCESS DEPLOYMENT
    • 51. THE GOOD WAY OF DEPLOY AN APP : git push
    • 52. EASY MOVING OR INCIDENT MANAGEMENT
    • 53. KEEP CALM UNDER FIRE
    • 54. ALWAYS USE A REVERSE PROXY Y U NO USE ONE ?
    • 55. TRICK WITH OTHERS PROTOCOLS
    • 56. TRACK BUG & GET METRICS
    • 57. I’m @waxzce on twitter I’m the CEO of A PaaS provider, give it a try ;-) THX FOR LISTENING & QUESTIONS TIME

    ×