Once you have two providers, you are forced to only use the features offered by each of them and use an abstract layer (API agnostic dev).
Plus, AWS offers a wide range of strategies to ensure the availability of its infrastructure (Availability Zone, Regions, CDN etc.)
Abstraction layers don't necessarily need to produce lowest common denominator results.
Plus, AWS offers a wide range of strategies to ensure the availability of its infrastructure (Availability Zone, Regions, CDN etc.)
You still wind up vulnerable to quirks of the single provider though! For example, account freeze for whatever reason (financial quirks, legal issues, regulatory change) any multi-site failures (eg. financial, operational, legal, security) at that provider.
That said, if money is not a problem then go with whatever lets you get stuff done with the least pain.
However, cloud does have benefits that you lose with physical, eg. speed of initial deployment, speed of scale-out (no ordering/assembly/wiring/burn-in test/etc. lead times), maintenance and data center proximity issues (often translating to increased costs), masking of some of the legal/financial issues of multi-site presence (eg. if you want multi-jurisdictional points of presence), etc.
There are of course ways to use mixed strategies to combine cloud/third party services/CDN with physical infrastructure.
As always, "right tool for the job". I just felt it was worth mentioning there are limitations with single-provider cloud infrastructures as it's possible to get excited about the benefits of a particular approach without considering the full picture.
But in general, I agree with the article.
Granted node and nginx don't take long to run an update on. But the more you keep piling on updates the slower your true "time to ready" increases. And that can take a while from ec2 launch to ELB registration.
Why not have best of both and use puppet/chef to create your AMI anytime they require a security update?
This results in slower startups for new machines, but the flexibility seems to be worth it. Eventually we'll get to a point where the system will just build a new ami anytime a cookbook change is committed.
I am using the nodejs port though - npm install dashing-js
Also, for some apps deploying code during instance launch can be time consuming. Depending on your monitors and auto scale config, this might be acceptable. For some it may be appropriate to put code right in the ami and only ever deploy via new ami.
What I'd really like to see is details of how the traffic monitoring works, how you calculate how much extra capacity to spin up, and how quickly you can react to load events.
