This was the first talk by @simon_elisha I went to at ReInvent, and was a packed room. It was targeted towards developers going from inception of an app to growing it to 10 million users. Following are the notes I took…
– We will need a bigger box is the first issue, when you start seeing traffic to an application. Single box is an anti pattern because of no failover etc. move out your db from the web server etc…you could use RDS or something too.
– SQL or NoSQL?
Not a binary decision; maybe use both? A blended approach can reduce technical debt. Maybe just start with SQL because it’s familiar and there are clear patterns for scalability. Nosql is great for super low latency apps, metadata data sets, fast lookups and rapid ingesting data.
So for 100 users…
You can get by using route53, ELB, multiple web instances.
For 10000 users…
– Use cloud front to cache any static assets.
– Get your session state out of the webservers. Session state could be stored in dynamo db because it’s just unrelated data.
– Also might be time for elastic cache now which is just hosted redis or memcached.
Auto scaling…
Min, max servers running in multiple az zones. AWS makes this really simple.
If you end up at the 500k users situation you probably really want:
– metrics and alarms
– automated builds and deploys
– centralized logging
must haves for log metrics to collect:
– host level metrics
– aggregate level metrics
– log analysis
– external site performance
Use a product for this, because there are plenty available, and you can focus on what you’re really trying to accomplish.
Create tools to automate so you save your time especially to manage your time. Some of the ones that you can use are: elastic beanstalk, aws opsworks more for developers and cloud formation and raw ec2 for ops. The key is to be able to repeat those deploys quickly. You probably will need to use puppet and chef to manage the actual ec2 instances..
Now you probably need to redesign your app when you’re at the million user mark. Think about using a service oriented architecture. Loose coupling for the win instead of tight coupling. You can probably put a queue between 2 pieces
Key tip: don’t reinvent the wheel.
Example of what to do when you have a user uploading a picture to a site.
Simple workflow service
– workers and deciders: provides orchestration for your code.
When your data tier starts to break down 5-10 mill users
– federation
Split by function or purpose
Gotcha- You will have issues with join queries
– sharding
This works well for one table with billions of rows.
Gotcha- operationally confusing to manage
– shift to nosql
Sorta similar to federation
Gotcha- crazy architecture change. Use dynamo db.
Final Tips
the agile admin 