How to scale your app and win the cloud challenge?

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 J 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…
26. DO NOT USE A VARIABLE FOR MORE THAN ONE REQUEST
27. 2 + 2 = 4 FOR SAME INPUT, SAME OUTPUT
28. GET do not change data on server BE HTTP CONSISTENT
29. And data will be lost CODE WILL FAIL
30. 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
31. CAREFUL USE OF DARK MAGIC
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. USE EVENT BROKER TO MODULARIZE YOUR APP •  AMQP •  Celery •  0MQ •  Redis •  JMS •  Some case : hadoop, akka… •  … CRON is not an event queue
35. MAKE HARD COMPUTATION ASYNC
36. ALWAYS USE A REVERSE PROXY Y U NOT USE ONE ?
37. DO NOT BUILD “THE SERVER” WITH NO DOC
38. USE PROCESS DEPLOYMENT
39. EASY MOVING OR INCIDENT MANAGEMENT
40. KEEP CALM UNDER FIRE
41. TRACK BUG & GET METRICS
42. Quentin ADAM Twitter : @waxzce THX FOR LISTENING & QUESTIONS TIME clever c l o u d