Skip to main content

Biggest project management mistake

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:

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:
  1. Automation and tests
  2. Blue-green deployments
  3. Reporting
  4. Backups
  5. Logging


Popular posts from this blog

On working remote

The last company I worked for, did have an office space, but the code was all on Github, infra on AWS, we tracked issues over Asana and more or less each person had at least one project they could call "their own" (I had a bunch of them ;-)). This worked pretty well. And it gave me a feeling that working remote would not be very different from this. So when we started working on our own startup, we started with working from our homes. It looked great at first. I could now spend more time with Mom and could work at leisure. However, it is not as good as it looks like. At times it just feels you are busy without business, that you had been working, yet didn't achieve much. If you are evaluating working from home and are not sure of how to start, or you already do (then please review and add your views in comments) and feel like you were better off in the office, do read on. Remote work is great. But a physical office is better. So if you can, find yourself a co-working s

Capture and compare stdout in python unit tests

A recent fan of TDD, I set out to write tests for whatever comes my way. And there was one feature where the code would print messages to the console. Now - I had tests written for the API but I could not get my head around ways to capture these messages in my unittests. After some searching and some stroke of genius, here's how I accomplished capturing stdout.

15 minutes of courage

"I Quit" , said she and walked out as briskly as she could, her face as stern as a stone. She didn't look back. I wanted her to. I felt helpless, somewhat creepy, and a sudden chill went down my spine. I didn't know what to do. I wanted to just run away. Run away from her. Run away from this world. Run away to some distant place where I could be myself. Some place where I could cry to my heart's content. But I was not one of those who would leave the ground, wounded! I had always been the one who took life head on. So was it the time to lean back and contemplate what actually went wrong? No. That won't be the man, the world knew! So.. was it the time to build a castle around my feelings and play cold? ~ Prince Mishra