No one denies that capacity planning is hard. There are books written on the subject. The points you make are exactly the reason why you need to do capacity planning and plan for mitigating failures. If you aren't planning on 2x (in fact more) growth then I'm confused as to what kind of growth you really expect in your service.
If you aren't giving yourself room for expected and unexpected loads, you're doing it wrong. Add capacity and load testing to your process.
If you work on systems where you have the occasional 2x spike in traffic or planning for 2x capacity requirements in the future is easy then you don't have the same problems as suhail has.
I work in advertising for example. We could have 10 partners at 1x. Add 10 more and be at 1.1x or 2x, then add a large partner and be at 7x. There isn't a pattern to when we get partners from any of these groups but when we get them they need to go live as quickly as possible and sourcing and prepping hardware in situations like that isn't feasible. Nor is it feasible to have hardware on standby for the occasional 7x partner since you don't know when they are coming along and they could end up being a 10x partner.
If you aren't giving yourself room for expected and
-->unexpected<-- loads, you're doing it wrong.
You're using that word, I'm not sure it means what you think it means.
Over here in the real world, many applications (and notably web-applications) have one thing in common: They change all the time.
Your capacity plan from October might have been amazingly accurate for the software that was deployed and the load signature that was observed then.
Sadly now, in November, we have these two new features that hit the database quite hard. Plus, to add insult to injury, there's another old feature (that we had basically written off already) that is suddenly gaining immense popularity - and nobody can really tell how far that will go.
Capacity planning isn't just hard, it is costly. You have to profile every new version of your app, and every new version of the software you depend on. You have to update your planning models with that data, and then you have to provision extra hardware to handle whatever traffic spikes you think you'll be faced with within your planning window. Most of the time, those resources will be idle, but you will still be paying for them. Plus in the face of an extraordinary event, you'll be giving users a degraded experience.
Using "the cloud" doesn't solve all those problems but your costs can track your needs more closely, and with less up-front investment. Rather than carefully planning revisions to your infrastructure you can build a new one test it, cut over to it, and then ditch the old one.
You should still profile your app under load so you can be confident that you can indeed scale up easily, but even that is easier. You can bring up a full-scale version to test for a day and then take it down again.
I'm not against capacity planning, but it has it's time and place.
Bing uses a lot of Microsoft technologies including C# and .NET framework languages but as with many large services (or sets of services in this case) the components crawling, processing, indexing and serving content are written in a variety of languages including C, C++, etc and are managed by a myriad of tools languages that support features.
So you're saying the BankSimple team should consist of folks who have built complex systems, designed and implemented interfaces that are engaging to customers, and are knowledgeable about banking, right?
I'm pretty sure this article is one of those filler pieces that are in the writer's back pocket in case he can't think of something else to write about.
I take my iPhone and MBP up to the Bellevue and Redmond offices all the time. I get some weird looks sometimes when I pull out the laptop in the cafeteria but when they see I'm running Windows 7 and I'm doing stuff on the intranet, their attitude turns to curiosity. I've had many questions like "How does CorpNet work on your Mac?" My usual response: "Very well."
Sure you can eat your own dog food or whatever the cool new term for this is but there's also something about using the tools that work well for the job. I don't really run anything important for work on my Mac. All of my code builds/runs on lab machines or a desktop that sits in the office which I can connect to via Remote Desktop Connection. My Mac works great as a thin client to these machines.
Most of these (at least now) are made of sugar and baking soda. They used to be made of mercury thiocyanate back when we didn't know mercury poisoning was trouble.
It's been a while but I could start to explain it and maybe someone can pick it up from my rusty memory.
Mercury thiocyanate, Hg(SCN)2, decomposes at about 165 degrees Farenheit[1] to elemental components. I would guess that the shape of the product in that video is most likely due to the gases that are formed (most likely cyanide and mercury gas). I'm guessing the products are sulphur, cyanide vapor and mercury vapor. I'm also guessing that there are some oxides of sulphur and nitrogen forming since oxygen is readily available.
I have always wondered why there aren't more visible chemical 'sniffers' in all airports as I've seen at NY's Penn & Grand Central Stations. They're not really in the way and there are specific security protocols in place if one of them go off. iRobot is already producing bomb sniffing bots for the military and I doubt it'd be too hard for the technology to be adapted for airport checkpoints.
The sad reality is that we've more or less given our government emergency powers to issue such ludicrous directives to the airlines and for what? Some semblance of security? I guess Ma and Pa Kettle feel more safe on the airlines on their one round-trip flight they take every two years to see the grand kiddies but for those of us who fly more than that, it's a pain in ass and we're smart enough to realize where the holes are in security. I've heard plenty of instances of people bringing things that they didn't expect they could through security by mistake.
Our representatives in government aren't going to revoke these powers any time soon unless we ask them to.
I'm with you, but people asked for it. Until Americans come to terms with the fact that the world is a dangerous place, this will continue. Every lawsuit that pins liability on someone else for someone's actions that they should have realized could have an adverse outcome reinforces this mentality.
It seems the only deaths Americans are willing to accept as part of life are car crashes. All other causes are unacceptable and should be sued or enforced out of existence, even if they constitute a small fraction of that number.
Agreed 100%, but you forgot one more category of deaths that Americans seem more than happy to live with: deaths from preventable or easily (and cheaply!) treatable medical conditions, as well as deaths from medical errors (one commonly-cited IOM report places the total annual number of preventable deaths due to medical error in the same ballpark as the number of people killed in traffic accidents).
There are some review articles that are very readable for non-scientists written by an old boss of mine (Dr. Mark Mattson at the National Institute on Aging) on dietary intake.
Mattson is an interesting (albeit, a bit harebrained) dude. He completely believes in this caloric restriction stuff so much that he lives the lifestyle and follows a really strict diet.
Do you know if there have been any studies which made an effort to distinguish average-weight and average calorie intake? Hight calorie intake is associate with obesity and obesity is associated with many health problems. But what is the cause and what is the effect?
Do, say, long distance athletes, who consume and use massive calorie levels, suffer the same health problems as overweight sedentary people? Seriously, I'm curious if people have looked this.
If you aren't giving yourself room for expected and unexpected loads, you're doing it wrong. Add capacity and load testing to your process.