Slashdot Mirror
Sending Excess Load To the Cloud?
TristanBrotherton writes "Cloud computing seems to be a good choice for startups like ours, looking to scale easily with users. (We're providing a series of Web services, assets, and Web applications to users of our mobile client.) There are the obvious choices of Google, Amazon, and smaller shops like EngineYard. The biggest issue we have in choosing cloud computing to run our applications is trust in their robustness. If the provider goes down, we suffer. In traditional hosting environments we mitigate this with multiple sites / vendors. It's not really feasible to host on multiple compute services, so I wondered if a better option might be to set up a small (perhaps two servers) origin infrastructure in a traditional manner at a datacenter, running our applications, but then send excess load, or in the event of our origin servers failing, all load, to compute services. This would give us the best of both worlds. Has anyone done this, or had experience in designing Web applications to scale seamlessly across both environments? Is there particular load-balancing hardware we can use to do this?"
Unless your "cloud" provider offers a service level guarantee with teeth, is contractually obligated to continue to provide the service for some period of time, and has sound financial fundamentals, this is risky.
I think we'll see a big shutdown of money-losing web services over the next year.
Please don't use it. Every time you use a buzz-phrase God kills a kitten.
http://www.zombieapocalypse.tv/
The answer is to not get tied into a single service provider. You need a cloud computing solution that is standard-based (formal or defacto) and that lots of providers are supporting. And you have to be prepared to migrate your stuff if/when the industry moves on to the next version of the standard ... or the next "big leap forward" after cloud computing.
And that is all hard to do.
There is always a software solution when it comes to good L4-7 problem and not just load balancer but whole application delivery controller. One that works not only in your data center, one that can easily work in virtual environment (VMWare ESX for example) or Clound. Look at www.zeus.com (only software ADC on Gartner's Magic Quadrant).
yup, im in slashdot alright...
Did you read the question? Just curious...
yeah, I hate it when people spell matter wrong.
jack of all tribes, master of nuns.
There, "you are still in slashdot" for ya.
If your sole consideration is application availability, then your idea might make sense. But since you said you don't trust the application hosting company's "robustness," do you still trust them to protect and secure your data adequately? In other words, if you don't trust your IT service supplier in one dimension, why would you still trust them in other service quality dimensions?
Have you thought about establishing a contract with a formal Service Level Agreement (SLA), including penalties and escrow (or equivalent) for non-performance? That would seem to be a much more straightforward and comprehensive way to establish "trust."
Break n' bake servers work out really well with Amazon's EC2. I've never had to use it for anything really critical but so long as you maintain a set of closely sync'd liveUSB and AMI images I don't see why you'd have a problem. Just make sure that your existing failover mechanisms automatically initiate the backup plan, notify you, and isolate your local system for forensics or repair, since a security breach that will take down your local system has a high likelihood of succeeding in the cloud.
It's very probable that none of these offerings will work well if your application integration is not aware of itself as a group of applications and services.
Think about it: Install Apache on one host. OK. Now, two hosts... Well, do you round robin DNS, or do you run a squid reverse proxy, do you buy something else...
Next, how are you going to monitor this monster, Nagios or OpenView... or something else.
How many people are responsible for this puppy?
Oh, yeah... And I'm just talking about static web hosting, you start having all kinds of fun when you want to track user sessions, etc.
My advice to you is to look into an Application Service Provider. Make them do all of the integration work.
If you can afford Internet connectivity to a pair of servers, you can probably afford an Application Service Provider.
Given that you're talking about satisfying your base load with 2 servers and you can buy pretty decent 1U rackmount machines for $1-2k each....a)have cash on hand to buy that extra capacity b)have a vendor who can supply the equipment quickly c)tell your colo that you anticipate growing (so please don't put you in a rack where there's no room nearby, or if they can't do that, that you'll need some sort of wiring or VLANs), and d)have some sort of plan to quickly deploy the host O/S and app software. Oh yeah...and e)don't build your app with crap like Ruby/mongrel.
Please help metamoderate.
Yes I did, but what does he think he's going to accomplish by shifting the service into the cloud, why not just have backup servers in many datacenters? What exactly is the difference?
If you are running a web-based, hosted financial application, outsourcing "to the cloud" is a non-starter. If you are hosting pictures of kitty cats, the cloud can be an excellent resource.
Throw a server up, upload some files, start up a PG or MySQL database, and integrity is easy. But as soon as you introduce the 2nd system, integrity issues start jumping out of the woodwork. It gets worse with each additional node. Redundancy isn't just fancy-sounding, it's damned hard to do right, and as soon as you introduce it, you have to accept an elevated error rate because the number of things that can go wrong go UP, even as the number of catastrophic system failures drop.
For a great example of redundancy in action, take a look in the mirror. You have individual cells dying by the millions every minute. Your memory is fuzzy at best, your pattern-recognition in your brain frequently sees things that aren't there, and you make stupid mistakes every single day. And that's fine, because the overall system is pretty damned redundant and resilient. A mash of protein goo and calcium deposits able to sustain one of the most complex information systems around, reliably, 24x7, for an average of 70 years or so apiece.
Good luck getting any kind of hosting platform to maintain that kind of uptime, no matter the expense! But in biology, minor errors are so commonplace that they are hard to catalogue, let alone count.
So pick your battle, and realize that high-performance, high-redundancy clustering is very, very difficult to do well.
In the meantime, spend money on good quality hardware, and use top-notch colo hosting. The cost of doing it right is actually significantly lower than doing it "on the cheap" so spend money where it counts (good quality infrastructure) and save where it matters. (EG: public opinion) It's almost odd - if you look for the very, very best colo, regardless of cost, you'll find that their monetary cost is probably one of the lower ones around. (head scratcher) I've found this to be rather consistent with several reviews under my belt.
Also, I find it best to use whitebox systems with midrange hardware. These are quality, high-performance hardware developed with everything but the name brand. In my case, I've standardized on 1U multicore X86/64 systems with hot-swap, high performance 15k SCSI drives put out by Tyan and SuperMicro. There are a large number of dealers of such systems, my current favorite is Aberdeen Inc. They can sell you an amazing amount of performance and reliability for around $2500.
This is the stuff that Sun will sell you for $8,000/pop. They will stand up to day-in, day-out heavy use for years, with hundreds or thousands of users every day, millions of website hits per day, etc. They are high performance. This is quality hardware. And with the money you save, you can have an immediate hot backup for less than the cost of the "premium support" of the big guys, and more redundancy in the meantime.
My $0.02. Since it's free advice, you're free to use it as you see fit!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Distributed computing of any kind is complex and not something to be undertaken with no experience or assistance. Hire someone who knows their stuff to help you out. Being with a business case and don't be surprised if running your own cloud turns out not to be the way to go.
These posts express my own personal views, not those of my employer
Before I signed on to something like that, I'd spend some time meditating about Internet security. It's dubious at best and seems, if anything, to be slowly deteriorating. Is your situation such that you can deal with all your data being captured? How about it being altered? What future security constraints could shut you down for days, or weeks, or permanently? If you are OK on those things, then maybe.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
It actually has a reasonable definition.
The point of "the cloud" is:
Data availability - You can get to it from anywhere. It's on the web, or it's accessible via some sort of network call using a standard protocol.
Data portability - You can move it from one location to another...including a local machine or another node in the "cloud". (Gmail provides IMAP access, for example...a standard protocol, allowing you to use your data in ways Google never thought of.)
Resource expandability/shrinkability - You can use whatever amount of space/CPU you need, and buy more on demand. When you don't need it anymore, you can give it back, quickly and easily...either completely automatically or via API calls.
A "cloud" service can be an end-user service, like Gmail, or it can be a developer-targeted service, like AWS.
Ideally, some standards will emerge, reliability will improve, and we'll all find "cloud computing" to be a reasonable part of our infrastructure, no matter what we do. And, those pieces of the puzzle that are currently missing from the existing "cloud" services will hopefully find there way into place.
So, the name is being abused...but the concepts that it concisely represents are good concepts. They're good for consumers and good for developers, and they will be a part of our lives going forward (and we'll like it!). If you're building web services and you're not trying to figure out how to provide availability, portability, and right-sizing of resources, then you're going to miss out on lots of opportunities to have less negative impact on the environment, and lots of opportunities to save your users time and money.
The Internet is not "the cloud". The Internet is the way cloud services are delivered. Without the basic characteristics I mentioned, you're just building regular old web applications.
Work out how to build the servers as cheaply as possible. If peak load starts to get troublesome, add some more servers.
Cloud computing is a buzzword. Big server farms are may be dull, but it's a tried and tested technology that works. Ask Google.
Right , so in other words its a catch all term for remote computing. So why not call it , oh , I dunno , "remote computing"? A term thats been around since someone came up with the idea of RPCs.
Comment removed based on user account deletion
mater - French verb meaning to ogle. (As in "stare at girls"). Could this have been what he wanted to say?
There are a number of emerging technologies that enable very smooth scaling between single data centre (trad colo), single data centre + single cloud provider, single data centre + multiple cloud providers, multiple data centre + multiple cloud providers and all using the same base application stack.
These emerging technologies enable the configuration of your application, using underlying grid-type infrastructure, to deploy in multiple physical and virtual environments.
By virtualising the virtualisation (for want of a better term) they enable the rick to be spread so widely as to reduce it below the level of concern.
This enable the application architect to choose the correct mix from highly available but expensive infrastructure (e.g. data centre) and highly scalable and better cost infrastructure (e.g. cloud service with no SLA) to support the application. Flexible scalability and Flexible resilience.
Watch this space as these new players come up fast.
Data availability - Data replication across multiple sites. Not new.
Data portability - How is this new. And please don't try to pretend that the use of IMAP by GMail is in any way innovative.
Resource expandability/shrinkability - This just isn't available outside of the mainframe world. Unless you've written software for some sort of funky cluster thing (unlikely) then the cloud is something like VMWare ESX, and the maximum expansion you're ever going to get is to the size/capabilities of a single one of the racks. AFAIK it's not possible at this time to have a single OS image (of a standard OS you program normally for) across multiple x86 machines.
Because its something different?
"Cloud" is more like a giant cluster of VMs which you can turn on and of node by node at will. And best of all: you only pay for the running time. No investemnts up front for hardware.
It isnt the internet just because you use the internet to connect to it.
Your Beowulf cluster in your basement isnt your LAN either.
bickerdyke
Have you tried managing racks worth of servers in many locations?
That said, most cloud services today ARE very expensive. EC2, for example, can be trivially beaten with managed hosting, and in some cases totally crushed by maintaining your own servers.
What cloud services give you (and you pay through the nose for) is the ability to scale quickly. Trouble is, most people never need to scale that quickly.
Using clouds for "overflow" from a cheaper base setup is not a new idea, and it's definitively a good one. Particularly since it allows you to cut it a lot closer with your base setup. Without overflow capacity elsewhere, you need enough extra capacity in your base setup to handle reasonable growth plus any spikes. With overflow capacity using a cloud service, you only need to handle enough of your daily traffic that whatever you end up using of the overflow capacity is cheaper than adding more servers to your base. As soon as it isn't, you add more servers.
Sounds pretty cool. It seems that Mosix relies on multi-process programming to acheive scalability for any particular application. That's fine (there are lots of ways of doing it and distributed/parallel programming is not as hard as people make out), but it's not the sort of magic that the cloud seems to be touting.
Best bet for DR web hosting is duplicating the applications in two or more physically different locations.
In order to realize some return on such an expensive deployment, you need to be able to sweat all your assets. the only way to do that cost effectively is by adding some sort of load balancing across these applications. Most frequantly used solutions for hese types of environments are DNS based load balancing. Both Cisco and Radware offer a GLSB solution. In my experience, and I'll probably be killed for this, but the Radware solution is better.
my 2c
PS. i work for an independent integrator and not for either vendor.
It's my sig. Since when is an off-topic signature a problem?
I'm surprised \. is posting this without referring to the Stallman interview that was all over the nerd sites like reddit yesterday. It is very relevant. You missed it? Come on guys, you're not always the fastest and I don't care, but this is a fail.
(We're providing a series of Web services, assets, and Web applications to users of our mobil
This guy has the PHB manual talking points inserted rectally so hard it's still coming out of his mouth. I can't even take people seriously when they talk like this. Probably why I live in my Mom's basement instead of having a corporate job and a girlfriend.
I didn't claim any single one of those qualities is new...the point is that the term (like the term AJAX) is a concise way of describing a set of qualities that previously existed.
And, if you believe resource expandability/shrinkability is only available in mainframes, I'd humbly suggest you look at Xen on Linux and Zones on Solaris. Note I didn't say this up/down sizing had to be infinite, or across multiple machines...and, of course, mainframes do not provide infinite sizing, either. It merely needs to scale up and down to fit the size of a given task. For the vast majority of computing tasks, a small piece of a single CPU will do.
You're putting words in my mouth and then disputing those words.
"Right , so in other words its a catch all term for remote computing."
Does "remote computing" connote any of the qualities I mentioned? I never thought it did...and I've been using "remote computing" in the form of VNC, remote desktop, ssh, etc. for a decade or more. I never had an expectation any of those qualities applied to any of those services.
Oh, yeah, thanks for the heads up about the error.
Funnily enough this is a project I am working on right now.
I'm coming at it from an HPC (high performance computing) perspective. We'll have a cluster in-house supporting the base load and overflow to a utility computing provider.
Job scheduling software (currently torque but also trialing slurm) is used and once the total load has passed a threshold more remote compute VMs are fired up.
We should have it in production by - /me checks gantt chart - last month.
It seems like an idea whose time has come.
Backups are for wimps. Real men post their data in comments and have slashdot mirror it
If using a remote machine for some sort of computing services , be it data processing or display, isn't remote computing then what would you call it? Fluffy clouding? Dress it up all you want but ultimately all this "cloud" crap is just accessing data and/or services from a remote machine. Which has been done for decades.
Sorry the term pisses you off so. I view it as nothing more than a convenient term to cover a set of concepts. I don't think we're in agreement on what it means, however, and I can see how you'd find it irritating to use a new term for something that seems like an old concept to you.
I promise I'll never force you to use the term "cloud computing". But, to say that it's the same as "remote computing" is to say, "I don't know what one of these two terms means". Cloud computing (or whatever you want to call it) brings along with it certain expectations that never existed with "remote computing" of old--things like ssh, VNC, remote desktop, X11, provide none of the qualities that make something a "cloud" service...except possibly, "available everywhere", by some very limited definitions of "available" and "everywhere".
Did anyone else read the title "Sending Execs To The Cloud"?
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
I've been wondering something similar, but what Im looking for is something that is the equivalent of google docs, calendar, ect that I can host on my own webserver. (dreamhost is pretty awesome) For my work at a newer IT Support company and for my own school and personal files, and since Im always running all over town and use my iron-key, a easy to install cloud computing setup would make my life a lot simpler, and if there is no such thing, there is definitely a market for it. Any ideas anyone?
"It's ok, I'm completely secure as long as my iron is off"
My company is a development partner with http://mor.ph/ and we're doing exactly this. A website we're working on has high load twice a year, and other than that it can be handled by a single web server. What we're doing is augmenting our year-long server with a few extra app servers running at mor.ph during the two peak seasons.
The problems you worry about in this case are the same as any distributed HA web serving: having another site handle master-server failover gracefully, etc.
-Josh Adams
http://isotope11.com/
-knewter
My apologies if I've offended, it's just that use of buzzwords annoys me. I've looked at Xen, and VMWare and they're great products, but this is really no different from "Virtual Datacentre" or Virtual Hosting.
Cloud is an annoying term that actually obscures what's going on, and what's going on is already well understood.
Much like "Web 2.0", imho. Meaningless on its own, describing things that are already in place and, despite having slowly evolved to the present state with no overt revolutions, seem to suddenly need a new name.
They want their timesharing back.
As long as these "cloud" services remain incompatible there is no "cloud": just a bunch of competing timesharing services. There will be no "cloud" until you can switch your "excess load" from one provider to another with complete transparency.
I'm not holding my breath.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Why not go for dedicated servers for each app?
Does this help if the provider's servers are out of your control? As the submitter said, "If the provider goes down, we suffer."
Seems to me that if you can't afford someone else's servers to go down, you run your own or find someone you trust to do so on your behalf. Simple as that.
I'm a little surprised this is even a question.
The cloud computing does not solve every problem going. Nor does map/reduce or XML.
As a side affair I run a DTP Software as a Service (Service). This makes extensive use of 'Cloud' stuff.
Use neutral technologies that work on many cloud computing platforms. Postgres, Java, and Linux Image. As a quick startup, run VitualBox on each of the Cloud infrastructures, and then only code for your VirtualBox instance.
You have to write all the bridging, bootstrapping and aliveness code for the idosyncracies of each Cloud platform. But you always have to do some of this work, right?
And then of course you rent some dedicated servers which act as the common case and have an SLA. If you get the VirtualBox stuff right, you can simply deploy your cloud image to these dedicated boxes. When load gets too much, send it to someone elses cloud.
None of this is rocket-science. You get very little 'for free' like the marketting hype suggests.
It is my opinion that with Cloud Computing services, you must have in-office snapshots of your filesystems/databases. Access to these should not be reliant on any 3rd party. Also have off site, but physical backup (tapes)
[% slash_sig_val.text %]
If I'm hosting anything dealing with customer information, especially privileged information like bank accounts or medical information, I'm going to make very sure the company I contract with will indemnify me if they screw up, and I'm going to make sure they have a bond to back it up.
I'd much rather have only 99% uptime and 99.999999999999999999999999999999999999999999999999999999999999999% information security than the other way around.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I call myth. Cloud providers benefit heavily from economies of scale which is something that you as a little startup simply can't. On Amazon you can run a "midrange" server (i.e. ec2 large-instance) with plenty of traffic and a few hundred gigs of persistent storage for roughly $350/month. That is pretty close the amount that elsewhere you'll pay monthly for some empty rackspace and a bit of traffic without a single server in it.
As a rule of thumb you may assume circa $300/month for each additional server on amazon. Without upfront hardware-costs, without maintenance costs (as in fixing and replacing stuff if it's your own hardware), and with a provisioning-latency that is really hard to beat.
Yes, amazon is not "cheap" by any means. But it cannot be "trivially beaten" either.
I think he meant that the advice about your sig was off-topic, not that your signature was off-topic. And I think the advice was along the lines of "you just let a hundred thousand bandwidth destroying fucktards know where your publicly vandalizeable web-resource is, so stock up on butt-lube and server-slag-extinguishers, you're in for a ride!"
UTF-8: There and Back Again
"...Has anyone done this, or had experience in designing Web applications to scale seamlessly across both environments? Is there particular load-balancing hardware we can use to do this?"
A "global" (DNS) load balancer will do. The function of such a device is to monitor the health of multiple sites that can receive traffic, and direct traffic among sites that are confirmed as "up" according to your specifications. A short (<60 seconds) TTL is given in the DNS answer to force local DNS cache servers to expire quickly and check for DNS changes caused by an outage.
Normally such a device answers with A (IP address) records. However, in case your Cloud provider requires their own DNS (to balance load among their cloud sites), it is possible for your "global" balancer to hand out an appropriate CNAME record to defer resolution to your cloud provider's DNS.
Assuming you also have a traditional load balancer in front of your 2 dedicated servers, then what you'd probably want to do is set up the "global" load balancer to:
Sorry to pitch only a single product, but the only enterprise-level DNS product I know of that will hand out both A and CNAME records is F5's "Global Traffic Manager". They put it on a 1-unit standalone hardware, or you can get it as a software add-on to existing (traditional) F5 BIG-IP load balancer hardware.
This signature intentionally left unblank.
Disclaimer: I work as a software engineer at Salesforce.com.
Depending on your needs and budget, Force.com might be a viable option. It's all proprietary, but they do provide enterprise-class service level agreements and have delivered enterprise-grade levels of uptime to companies big and small ( http://trust.salesforce.com/trust/status/ ). Its Apex programming language is Java-like ( http://www.salesforce.com/platform/application-development/apex-programming-language/ ), and it's possible to write arbitrary user interfaces on it using its Java server faces extending VisualForce page layout markup language ( http://www.salesforce.com/platform/application-development/visualforce/ ).
Salesforce ensures via its processes throughout the company that no one except for you and anyone who you explicitly temporarily authorize, such as a support person in a service call, will see your data.
As new releases are created, Salesforce ensures that the APIs for previous versions do not regress, meaning that if you build an API integration on the latest version of the API and continue to use it as more Salesforce.com versions get released, your integration will work indefinitely until you decide to use the latest version of the API, and Salesforce.com hasn't dropped support for any of its obsolete API versions in years.
Depending on what you want to do with the platform, it's possible to sell your software to customers on the AppExchange. Customers, including those who already use Salesforce.com and those who do not, can install your AppExchange package and be up and running quickly. Customers who do not use Salesforce.com can use it via a platform license that you can sell directly to your customers, thus relegating Salesforce.com to be the underlying platform and giving you more complete control over your interactions with your customers. This is platform as a service (PaaS). I know, I know.. Buzzwords ;-)
Relevant URLs:
Force.com: http://www.force.com/
Salesforce.com's cloud status: http://trust.salesforce.com/trust/status/
Apex programming language: http://www.salesforce.com/platform/application-development/apex-programming-language/
VisualForce: http://www.salesforce.com/platform/application-development/visualforce/
AppExchange: http://www.salesforce.com/platform/appexchange/
API and integrations: http://www.salesforce.com/platform/integration/
Hopefully, this helps. Please don't mod me as troll ;-). I'm trying to be helpful and informative to the original poster.
I once blew my load in a heavenly body, does that count?
What the FUCK is "cloud computing"?
Are we talking the same thing we called distributed apps back in the 90s? You know, another one of those .com BUSTS?
I mean, if you want "5 nines", do it yourself.
Stop looking for someone to blame things on. When I was active in IT, that was what we looked for when trying to outsource our server farm, nothing more. Someone else to blame things on.
If you have enough business that you need that level of SLA, then might I suggest actually HAVING a small IT department. That means pony up the bread for someone to run it, and cough up a couple servers.
More expensive today, but the residuals of owning your own farm go SO far beyond having someone to simply blame for the downtime.
--Toll_Free
The mention of Engine Yard probably means we're dealing with a Ruby on Rails application.
I'd say the question is irrelevant since we all know that rails can't scale.
Yes, there are many vendors participating in the VMware cloud concept.
The Virtual Datacenter OS and the vCloud idea really does look interesting. If you can find that keynote online, it may be worth watching. They gave a live demo.
http://www.vmware.com/company/news/releases/vcloud_vmworld08.html
http://www.vmware.com/technology/virtual-datacenter-os/cloud-vservices/
Bad boys rape our young girls but Violet gives willingly.
Perhaps he meant alma mater of none.
Oh, yeah, it's not easy to pad these out to 120 characters.
The efficient model would look like:
Storage and bandwidth of a CDN web proxy will be about 1/2 that of a cloud service.
Sites like plentyoffish.com get away with just 4 servers by using a CDN. With only four machines then the choice of "cloud" vs. "real machine" becomes a "don't care".
I noticed that you didn't mention Mosso, one of the first large scale cloud providers that has been doing this for years. They are a division of Rackspace as well. As far as robustness is concerned, there was a great write-up of the Mosso platform last week on this blog: http://matthewsacks.com/techblog/2008/09/23/rackspaces-mosso-hosting-cloud-review/
Yes, my company has done this for a client and we are about to do it for one more. We have 3 servers hosted at 'traditional' hosing providers (one at Rimu Hosting, the other at ServerBeach), and during peak load, we fire up Amazon EC2 instances and throw traffic towards them. The 'real hardware' servers can handle normal traffic and redundancy (any one can fail), we just use the cloud for handling peak traffic. We also use the cloud for creating a multiple machine staging environment for testing. We can fire that up, deploy to test, and have the client check out all the new features, and it only costs us a dollar or two.
As cost effective as short bursts are, if they stay up for any amount of time, they cease to be cost effective. I never understand why people think EC2 is so cost effective when, at 10 cents an hour, you will pay $72/month... When you can get a virtual machine that is as performant from a company like Rimu for ~$30-40, or a dedicated resource for something like $90.
-db
EC2 is great. It allows fast saving, recovery and on-demand provisioning as needed. The cost is on par or maybe a bit more than most service providers, but I like the pay-as-you-need-it self service -- no server monkeys, hardware failures, etc.
Even though EC2 is great, and has an SLA claiming 99.9% uptime or you don't pay, I need a disaster plan. I'm still looking for an EC2 AMI to xen image process, so I can take my existing AMIs and move them to my own xen server or a hosted xen server if Amazon EC2 or S3 should go down for any reason. Just because it is a cloud doesn't mean it's always up. Sometimes it's sunny because the cloud isn't there (there's a Nagios plugin for that).
TossableDigits.com: Temporary Phone Numb
Try reading this blog post about "cloudbursting" and the pages it links to. It talks about using your fixed infrastructure, but also expanding to the cloud when you need a sudden burst of power/infrastructure.
A cloud is usually the first sign I have excess load.
Oh wait, this isn't the methane gas thread!
I've had a look at Bluelock http://bluelock.com/ and what they're doing with VMWare's cloud technology may be the difference you're looking for. VMware is extending a virtual cloud to any datacenter running VMware - that's a pretty fascinating approach that could put the big boys on their heels! http://vmware.com/cloud
Dunno. The last time I sent my excess load to the cloud, God killed a kitten.
C|N>K
Cost and complexity.
Using clouds for "overflow" from a cheaper base setup is not a new idea, and it's definitively a good one.
I've been trying to dig up sources on this, but can't seem to find any. Any places, companies, sources that you're aware of that do this well?
That said, most cloud services today ARE very expensive. EC2, for example, can be trivially beaten with managed hosting, and in some cases totally crushed by maintaining your own servers.
Most people who say that the Elastic Compute Cloud is expensive with respect to managed hosting fail to expand the acronym Elastic Compute Cloud and take special note of the first word, Elastic.
If your computing needs are Static, then yes, you can do better with managed hosting or maintaining your own servers. Maybe you have a load spike at a certain time of day or time of month or time of year. Maybe it happens at unpredictable times (you get slashdotted, you get hard during events of some sort, when your commercial runs on TV, etc.). In that case, you can build an application on EC2 that can automatically add capacity when needed and remove capacity when it is no longer needed.
Another situation is when you have a small web site or service, and you think you are poised for explosive growth, but you are not sure. These things can be hard to predict, both in terms of timing and scale. When you site goes viral, do you want to be calling Dell asking how soon they can ship you a few (or a few dozen) more servers? Or do you want your service to automatically scale to meet the demand, whatever that may be?
Again, if your computing needs are Static, you will do better somewhere else. But if your Elastic, then the Elastic Compute Cloud can be extremely cost-effective.
Not to belabor the point, or anything.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock