<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>The Wisdom of Clouds - Latest Comments in Do Your Cloud Applications Need To Be Elastic?</title><link>http://cloudcomputing.disqus.com/</link><description></description><atom:link href="https://cloudcomputing.disqus.com/do_your_cloud_applications_need_to_be_elastic/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Wed, 29 Apr 2009 05:01:30 -0000</lastBuildDate><item><title>Re: Do Your Cloud Applications Need To Be Elastic?</title><link>http://blog.jamesurquhart.com/2008/11/do-your-cloud-applications-need-to-be.html#comment-8804269</link><description>&lt;p&gt;Thanks for this post - i have been trying to work out which to chose - colocation or on site this is a great cost analysis break down. Cheers&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">colocation</dc:creator><pubDate>Wed, 29 Apr 2009 05:01:30 -0000</pubDate></item><item><title>Re: Do Your Cloud Applications Need To Be Elastic?</title><link>http://blog.jamesurquhart.com/2008/11/do-your-cloud-applications-need-to-be.html#comment-4021209</link><description>&lt;p&gt;Hey James -- sorry for the delay, disqus didn't let me know there was a reply ;)&lt;/p&gt;&lt;p&gt;We're an early-stage startup, so no, we had no existing infrastructure bar a few colo servers which could be entirely replaced by EC2 instances.&lt;/p&gt;&lt;p&gt;Being able to use small numbers of servers at a time and be billed for just the CPU time used is great for us.  Of course, we also have inelastic parts of the infrastructure that could be hosted elsewhere at a colo for less cost, and personally, I would probably have done this given the choice; but mgmt were happier just to use EC2 as widely as possible, despite the additional costs, since it keeps things simpler.&lt;/p&gt;&lt;p&gt;For example, we also use S3 heavily, and EC2-to-S3 traffic is extremely fast and cheap compared to external-to-S3; so that's proving to be an effective point of lock-in.  (We don't mind.)&lt;/p&gt;&lt;p&gt;Regarding locally-hosted servers on our own infrastructure -- that was simply out.  There's a massive amount of investment that would be required to get a sufficiently-reliable infrastructure set up, and a good deal of coding and config to get an EC2ish elastic server provisioning system going on that. Further down the line, that might be appropriate, but not yet... it's a lot easier to let Amazon do it for us ;)&lt;/p&gt;&lt;p&gt;There's definitely a point where we *could* migrate to our own infrastructure in the future, and open source apps like Eucalyptus make that more viable -- but in my opinion it's very far off indeed...&lt;/p&gt;&lt;p&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jmason</dc:creator><pubDate>Wed, 26 Nov 2008 05:18:58 -0000</pubDate></item><item><title>Re: Do Your Cloud Applications Need To Be Elastic?</title><link>http://blog.jamesurquhart.com/2008/11/do-your-cloud-applications-need-to-be.html#comment-4005122</link><description>&lt;p&gt;See, now that's an interesting use case.&lt;/p&gt;&lt;p&gt;Did you do a cost comparison compared to running virtual machines on your own infrastructure?  Did you have your own infrastructure to start with?&lt;/p&gt;&lt;p&gt;Also, have you ever done a spreadsheet projection about your costs if you become wildly successful?  Is there a tipping point where owning your own stuff starts to look more attractive?  That's what Animoto was predicting a few months ago.&lt;/p&gt;&lt;p&gt;Thanks for the comment.  I hadn't thought of this angle at all.&lt;/p&gt;&lt;p&gt;James&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jamesurquhart</dc:creator><pubDate>Tue, 25 Nov 2008 10:05:04 -0000</pubDate></item><item><title>Re: Do Your Cloud Applications Need To Be Elastic?</title><link>http://blog.jamesurquhart.com/2008/11/do-your-cloud-applications-need-to-be.html#comment-4002770</link><description>&lt;p&gt;There's another reason to use an EC2-like cloud without horizontally scaling a single application; if you want to deploy another copy of the app, either from a different version-control branch (dev vs staging vs production deployments), or to run separate apps with customizations for different customers.  These aren't scaling an existing app up, they're creating new copies of the app, and EC2 works nicely to do this -- I'm using it for that purpose right now.&lt;/p&gt;&lt;p&gt;(Also, w.r.t. figures: most of our EC2 nodes are the 10c/hour variety; the classic "many cheap servers vs. fewer big servers" scaling model.)&lt;br&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Justin Mason</dc:creator><pubDate>Tue, 25 Nov 2008 06:08:57 -0000</pubDate></item><item><title>Re: Do Your Cloud Applications Need To Be Elastic?</title><link>http://blog.jamesurquhart.com/2008/11/do-your-cloud-applications-need-to-be.html#comment-3968450</link><description>&lt;p&gt;No, but then the Amazon figures don't reflect administrative OPEX, security/patching OPEX, regulatory compliance OPEX, backup system OPEX (or possibly even CAPEX), et. al.  Don't be fooled, Amazon just gives you some servers; you are still responsible for provisioning, monitoring, patching, securiting, assuring compliance, providing a backup plan should Amazon go down, etc., etc., etc.  Developers think there is nothing to do once the server is provisioned.  System administrators responsible for availability and compliance know much more is at stake.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jamesurquhart</dc:creator><pubDate>Sun, 23 Nov 2008 11:03:28 -0000</pubDate></item><item><title>Re: Do Your Cloud Applications Need To Be Elastic?</title><link>http://blog.jamesurquhart.com/2008/11/do-your-cloud-applications-need-to-be.html#comment-3967936</link><description>&lt;p&gt;From whence are these figures derived?  Do the on-premise figures reflect administrative OPEX, security/patching OPEX, regulatory compiance OPEX, backup system CAPEX/OPEX, et. al.?&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Roland Dobbins</dc:creator><pubDate>Sun, 23 Nov 2008 09:59:55 -0000</pubDate></item><item><title>Re: Do Your Cloud Applications Need To Be Elastic?</title><link>http://blog.jamesurquhart.com/2008/11/do-your-cloud-applications-need-to-be.html#comment-3965978</link><description>&lt;p&gt;Again, if it doesn't need to be running all of the time (and you can remember to shut the dang thing off), it may be a candidate for EC2/S3.  However, just note that there are 24X7 costs for every EC2 instance, whether it is on or not, in the form of S3/EBS.&lt;/p&gt;&lt;p&gt;I'm just warning people to do the math before committing to the cloud.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jamesurquhart</dc:creator><pubDate>Sun, 23 Nov 2008 03:37:03 -0000</pubDate></item><item><title>Re: Do Your Cloud Applications Need To Be Elastic?</title><link>http://blog.jamesurquhart.com/2008/11/do-your-cloud-applications-need-to-be.html#comment-3965070</link><description>&lt;p&gt;But how do you spin up a program for 12 hours a day on EC2 without having a presence already in the cloud that you would have to pay for?&lt;/p&gt;&lt;p&gt;And these number don't include maintenance, bandwidth, and S3. Keeping a data center up is not a part time job.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">james</dc:creator><pubDate>Sun, 23 Nov 2008 00:41:05 -0000</pubDate></item><item><title>Re: Do Your Cloud Applications Need To Be Elastic?</title><link>http://blog.jamesurquhart.com/2008/11/do-your-cloud-applications-need-to-be.html#comment-3953086</link><description>&lt;p&gt;Even in the case of accounting systems, CRM etc., many business work less than 12 hours per day, 5 days a week, if the instances are powered up only for those hours of use(as many businesses currently do with their in-office servers and PCs), then the cloud can also be cost-effective for these types of applications.&lt;/p&gt;&lt;p&gt;Tom&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tom Gleeson</dc:creator><pubDate>Sat, 22 Nov 2008 08:56:37 -0000</pubDate></item></channel></rss>