This holds true for developers, project managers, entrepreneurs, everybody who has shipped software to the real world. The biggest mistake one can make while shipping software is not shipping buggy code or half-baked features (and they are all easy to uncover given sufficient QA), or not planning for failure. The biggest mistake that folks make is - not planning for success.
Trust me - shit breaks loose when your app gets hot over the night! So here's a list of concerns one needs to plan for, before launching a site:
Caching
Cache everything - images, javascript, style sheets, html templates - everything. I use nginx at the frontend proxy layer and it does a full page caching for entire html pages. Works like a charm!
At the application layer, use Redis as a TTL-based cache.
Deliver static content really fast
Images, JS, stylesheets - they need to be rendered by a specialized static files host - a CDN in essence. Use a managed service provider (Amazon CloudFront), or deploy nginx (with local caching) over a separate box and serve yourself.
Scaling load-balancers/frontend proxies
Plan your deployment in such a way that adding and removing first layer application servers should be ridiculously simple. This means a load-balancer is an absolute must. Here again - you can use Amazon ELB or deploy nginx or haproxy. But if you happen to deploy a load-balancer yourself, keep in mind that servers die all the time and you don't want your release sabotaged by a dead load-balancer. Plan for failure. What happens when the load-balancer dies? You spin up a new one! And that should be ridiculously simple - use AMIs, docker, vagrant, puppet, chef, anything.
Scaling application servers
Keep a couple of application servers in standby so that when the load comes in, you can just plow them in quickly. A better strategy is to use docker or other packaging tools which let you spawn applications quickly.
Use event-based I/O at application server layer. For python (flask, django) applications, I use uwsgi as the app container. Gunicorn is also a good choice.
Scaling Databases
Index your tables and views correctly. Shard. This machine needs to be high on memory. Increase max parallel connections setting before going live.
Logging and alerts
You cannot improve something you cannot measure. And your users mailing you about app crashes is not the best idea of usability testing. Use NewRelic agents on your web server components, use Crashlytics in your mobile app. If hell is breaking loose - you should be the first to know, not your users. ELK and ElastAlert make a good choice too, but for beginners, a NewRelic based alerting mechanism is good enough. Amazon users can very well use CloudWatch.
This is part one of the post. In part two, I will talk about:
Trust me - shit breaks loose when your app gets hot over the night! So here's a list of concerns one needs to plan for, before launching a site:
Caching
Cache everything - images, javascript, style sheets, html templates - everything. I use nginx at the frontend proxy layer and it does a full page caching for entire html pages. Works like a charm!
At the application layer, use Redis as a TTL-based cache.
Deliver static content really fast
Images, JS, stylesheets - they need to be rendered by a specialized static files host - a CDN in essence. Use a managed service provider (Amazon CloudFront), or deploy nginx (with local caching) over a separate box and serve yourself.
Scaling load-balancers/frontend proxies
Plan your deployment in such a way that adding and removing first layer application servers should be ridiculously simple. This means a load-balancer is an absolute must. Here again - you can use Amazon ELB or deploy nginx or haproxy. But if you happen to deploy a load-balancer yourself, keep in mind that servers die all the time and you don't want your release sabotaged by a dead load-balancer. Plan for failure. What happens when the load-balancer dies? You spin up a new one! And that should be ridiculously simple - use AMIs, docker, vagrant, puppet, chef, anything.
Scaling application servers
Keep a couple of application servers in standby so that when the load comes in, you can just plow them in quickly. A better strategy is to use docker or other packaging tools which let you spawn applications quickly.
Use event-based I/O at application server layer. For python (flask, django) applications, I use uwsgi as the app container. Gunicorn is also a good choice.
Scaling Databases
Index your tables and views correctly. Shard. This machine needs to be high on memory. Increase max parallel connections setting before going live.
Logging and alerts
You cannot improve something you cannot measure. And your users mailing you about app crashes is not the best idea of usability testing. Use NewRelic agents on your web server components, use Crashlytics in your mobile app. If hell is breaking loose - you should be the first to know, not your users. ELK and ElastAlert make a good choice too, but for beginners, a NewRelic based alerting mechanism is good enough. Amazon users can very well use CloudWatch.
This is part one of the post. In part two, I will talk about:
- Automation and tests
- Blue-green deployments
- Reporting
- Backups
- Logging
Comments
Post a Comment