How to scale your app and win the cloud challenge
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

How to scale your app and win the cloud challenge

on

  • 2,692 views

while42.org #1 paris event

while42.org #1 paris event

Statistics

Views

Total Views
2,692
Views on SlideShare
2,640
Embed Views
52

Actions

Likes
3
Downloads
19
Comments
0

3 Embeds 52

https://twitter.com 43
http://www.google.com 8
http://pulse.me&_=1373775426996 HTTP 1

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

How to scale your app and win the cloud challenge Presentation Transcript

  • 1. HOW TO SCALE YOUR APP AND WIN THE CLOUD CHALLENGE QUENTIN ADAM @WAXZCE 2013
  • 2. Quentin ADAM Clever Cloud CEO @waxzce on twitter http://www.waxzce.org WHO I AM ?
  • 3. Java, scala, python, nodejs, php… apps scaling automatically in the cloud. We cover your ass, you can focus on your own stuff http://www.clever-cloud.com PAAS PROVIDER
  • 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. SO, HOW TO SCALE OUT ? JUST SOME FACTS
  • 10. SPLIT PROCESS AND STORAGE Storage • Databases • Files • Sessions • Events • … Code • Can be replicated • Stateless • Process
  • 11. Picking one instance or another doesn’t matter STATELESSNESS IS THE KEY
  • 12. CONSIDER MORE THINGS AS DATA • User account • Users data • Files • Sessions • Events
  • 13. CHOOSE DATASTORE WISELY YOU CAN SHOULD USE MANY DATASTORES
  • 14. 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 ?
  • 15. • Not a big volume • DB have to manage data TTL • Data model : K/V • Multiple writes at the same time • High availability I need to store sessions QUICK EXAMPLE
  • 16. • Not a big volume It’s OK, PG can handle small quantity of data • DB have to manage data TTL No, I have to do it manually • Data model : K/V No, PG is relational (mainly) • Multiple writes at the same time No, PG is Atomic • High availability PG is awesome ;-) Use of PG bouncer or similar allow good clustering I need to store sessions QUICK EXAMPLE
  • 17. • Not a big volume It’s OK, redis can handle small quantity of data • DB have to manage data TTL Yes Redis can do it • Data model : K/V Yes • Multiple writes at the same time No, redis is pseudo Atomic (master/slave) • High availability Redis is great, but cauterization is rude… I need to store sessions QUICK EXAMPLE
  • 18. • Not a big volume It’s OK, CB can handle small quantity of data • DB have to manage data TTL Yes CB can do it • Data model : K/V Yes • Multiple writes at the same time OK, this is possible with memcached protocol • High availability Clustering is built in, no downtime  I need to store sessions QUICK EXAMPLE
  • 19. USE ONLINE DATABASE / BE READY TO TEST IN JUST A FEW MINUTES NO NEED TO TRASH YOUR COMPUTER
  • 20. DON’T BE THAT GUY
  • 21. 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
  • 22. DO NOT CREATE MONSTERS
  • 23. COMMON MISTAKES
  • 24. DO NOT USE MEMORY AS DATABASE LIKE : SHARED / GLOBAL VARIABLE, CACHE “IN THE CODE”, INTENSIVE SESSION USAGE…
  • 25. DO NOT USE A VARIABLE FOR MORE THAN ONE REQUEST
  • 26. 2 + 2 = 4 FOR SAME INPUT, SAME OUTPUT
  • 27. GET do not change data on server BE HTTP CONSISTENT
  • 28. And data will be lost CODE WILL FAIL
  • 29. DO NOT USE FILE SYSTEM AS DATASTORE File system are POSIX compliant • POSIX is ACID • POSIX is powerful but is bottleneck • File System is nightmare of ops • File System is create coupling (host provider/OS/language) • Free SPOF multi tenant File System is a unicorn STORE IN DATABASE, OR DATASTORE LIKE S3 (AWS) DEDICATED TO FILE MANAGEMENT
  • 30. CAREFUL USE OF DARK MAGIC
  • 31. SPLIT THE CODE : MODULES • Smallest code base • Deploy as service for each other • Focus on best technology for a problem
  • 32. SCALE YOUR TEAM MODULARIZE YOUR TEAM
  • 33. USE EVENT BROKER TO MODULARIZE YOUR APP • AMQP • Celery • 0MQ • Redis • JMS • Some case : hadoop, akka… • … CRON is not an event queue
  • 34. MAKE HARD COMPUTATION ASYNC
  • 35. ALWAYS USE A REVERSE PROXY Y U NOT USE ONE ?
  • 36. DO NOT BUILD “THE SERVER” WITH NO DOC
  • 37. USE PROCESS DEPLOYMENT
  • 38. EASY MOVING OR INCIDENT MANAGEMENT
  • 39. KEEP CALM UNDER FIRE
  • 40. TRACK BUG & GET METRICS
  • 41. Quentin ADAM Twitter : @waxzce THX FOR LISTENING & QUESTIONS TIME