DISQUS

The Wisdom of Clouds: Do Your Cloud Applications Need To Be Elastic?

  • Tom Gleeson · 1 year ago
    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.

    Tom
  • james · 1 year ago
    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?

    And these number don't include maintenance, bandwidth, and S3. Keeping a data center up is not a part time job.
  • jamesurquhart · 1 year ago
    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.

    I'm just warning people to do the math before committing to the cloud.
  • Roland Dobbins · 1 year ago
    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.?
  • jamesurquhart · 1 year ago
    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.
  • Justin Mason · 1 year ago
    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.

    (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.)
  • jamesurquhart · 1 year ago
    See, now that's an interesting use case.

    Did you do a cost comparison compared to running virtual machines on your own infrastructure? Did you have your own infrastructure to start with?

    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.

    Thanks for the comment. I hadn't thought of this angle at all.

    James
  • jmason · 1 year ago
    Hey James -- sorry for the delay, disqus didn't let me know there was a reply ;)

    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.

    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.

    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.)

    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 ;)

    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...
  • colocation · 7 months ago
    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