The Woes of Cloud Computing

  • Comments posted to this topic are about the item The Woes of Cloud Computing

  • I've found that one of the biggest reasons why people originate or move databases to the cloud is so that you don't have to have a lot of hardware locally. Once that's done, it's not like people are going to have a free server with enough storage space just idling around wait for you to move something back from the cloud.

    Because of that, one of two things will likely happen... either the requirement to move something back from the cloud will suddenly become a whole lot less important or there will be a huge panic tring to get equipment in place along with the funding to get it there.

    My recommendation is to be very, very careful about what you migrate to the cloud to begin with because, once it's there, it's going to be a real bugger to bring back locally. To coin a phrase... "What goes up... may just stay there." 😛

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • "The cloud isn't the ultimate answer, and you ought to have a backup plan, which should include the ability to move your services back to your own data center."

    This is a strange and rather unrealistic statement. If a company moves to the cloud, they are (99.99% of the time) sold on the cloud from an economic standpoint. So what IT Director is going to invest in Cloud computing AND have to maintain a Data Center 'just in case'. Try pushing that one past a CEO and you will either be laughed out of the office, or worse, fired for being slightly braindead as you double or triple IT costs.

    Cloud computing suffers from the same lack of vision that has plagued technology for decades. It all sounds like a great idea until you really get under the hood and realize what you are giving away, and worse, what the unknowns are. As much as it has application in some limited implementations, generally its more like the Palm Pilot or other such "change the world" inventions - that never changed the world.

    Think of it this way - suppose you use an on-line backup service in your personal or professional life. Have you read the fine print in the agreement? Do you know that if they lose all your data they have lawyers who have already insured you cannot hold them liable? Does that sound like a "good idea"? Of course, they didn't tell you that when you joined up. It all sounded so good until the inevitable struck.

    If you go to the Cloud, be darn sure you read the fine print - as many companies have discovered, its not worth the risk because although they are happy to sell you, at this point they are not that interested in supporting you in a crisis, because of course, there never will be any crisis. Yeah, right... That surely has never happened in technology...

    There's no such thing as dumb questions, only poorly thought-out answers...
  • I don't know about bring it back in-house, but you certainly want the option to be able to move to another provider, should your provider have a large price increase or go out of business.

  • At this point, my impression is that it makes more sense to migrate datamarts and reporting databases to the cloud, and keep in-house those transactional databases that serve their core operations. There are situations where an organization needs to stand up additional instances of reporting servers to faciliate development teams or scale out to improve performance. However, it may not make economic sense to keep spare hardware and licenses sitting around in a closet just to faciliate these occasional needs, which sometimes may even be temporary or experimental in nature. So, my thinking is: scale up the transactional databases and keep in-house, and scale out the reporting databases and datamarts, for which the cloud offers new possibilities.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • As a financial company, we rather lock all the data in our server room than put it on internet. An old style lock could stop any hacker.

    Plus , the compute power is dirt cheap nowaday. The cost of 4 nodes cluster is less than 100k, and it could serve 2000 users very well.

    Why bother?!

    _______________________________________________________________

  • ... plus my favorite reminder that many industries have legal requirements to keep data on the premises (such as pharmacies) or at least in the state (brokerages). For those, cloud is DOA.

  • Jeff Moden (8/3/2011)


    I've found that one of the biggest reasons why people originate or move databases to the cloud is so that you don't have to have a lot of hardware locally. Once that's done, it's not like people are going to have a free server with enough storage space just idling around wait for you to move something back from the cloud.

    Because of that, one of two things will likely happen... either the requirement to move something back from the cloud will suddenly become a whole lot less important or there will be a huge panic tring to get equipment in place along with the funding to get it there.

    My recommendation is to be very, very careful about what you migrate to the cloud to begin with because, once it's there, it's going to be a real bugger to bring back locally. To coin a phrase... "What goes up... may just stay there." 😛

    One of the issues people have found is that development costs can skyrocket in the cloud. Developers send data back and forth, test things, eat up transactions with things like cross joins, etc. So those local servers still have a place.

  • blandry (8/4/2011)


    "The cloud isn't the ultimate answer, and you ought to have a backup plan, which should include the ability to move your services back to your own data center."

    This is a strange and rather unrealistic statement. If a company moves to the cloud, they are (99.99% of the time) sold on the cloud from an economic standpoint. So what IT Director is going to invest in Cloud computing AND have to maintain a Data Center 'just in case'. Try pushing that one past a CEO and you will either be laughed out of the office, or worse, fired for being slightly braindead as you double or triple IT costs.

    I'm not sure that's true. Over time, perhaps, but most of the people moving to the cloud, including MS, are doing so an application at a time. So they still have some local resources. They may even always have some local resources for things like development.

    There also are applications that people move to the cloud because of a "burst" of demand that may tail off and they decide to bring it back in house.

  • Steve Jones - SSC Editor (8/4/2011)


    . . . There also are applications that people move to the cloud because of a "burst" of demand that may tail off and they decide to bring it back in house.

    For burst demand, cloud is ideal. I had a client who is running Web sites for kiddie leagues, with tools that allow create their site easily. When the registration opens, they are running 500 tps for several hours; on any other day, 1 or 2 tps.

    It makes sense to keep the app serving the pages and the databases in the cloud, and have local hardware just to serve pageframes and support development. They have not migrated yet, though, because they bought their hefty iron two years ago.

  • "The cloud isn't the ultimate answer, and you ought to have a backup plan, which should include the ability to move your services back to your own data center."

    Having a backup plan doesn't necessitate having the hardware onsite (or even purchased). As a minimum you need to have worked out a way to pull your applications and data down from the cloud, and know what it will cost if you, or someone with access to the cheque book, decide to throw the switch. When the big cheeze starts asking pointed questions about the performance of your cloud based applications you can pull out your plan and say "Here is what we need, and a rough timeline, to get out of the cloud, sign there, initial there, and fill in the GL account to charge there and we'll start ordering hardware."

    You didn't transition into the cloud instantly you won't transition out instantly either. Without the change-over plan worked out in advance you may just find that your cloud application's extracts don't actually give you back all of your data in a usable format.

    -D

  • When you put a 7/24 business on the cloud. How any days you could lost to rebuild an in-house data center when your cloud provider having a trouble? Guess the CIO will blame you or the provider?

    _______________________________________________________________

  • michael wang-201906 (8/4/2011)


    When you put a 7/24 business on the cloud. How any days you could lost to rebuild an in-house data center when your cloud provider having a trouble? Guess the CIO will blame you or the provider?

    Since the decision to move the corporate database to a cloud provider would ultimately be up to the CIO, not the developer, upper management would have to blame themselves for that one. They can't blame the poor guy who's been called in implement the fallback plan, unless they think he's just taking too much time to stage the in-house environment. The decision to move to the cloud should not be done without weighing the benefits versus the potential risk and definate loss of control. Management is really putting it on the line with that decision.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • michael wang-201906 (8/4/2011)


    When you put a 7/24 business on the cloud. How any days you could lost to rebuild an in-house data center when your cloud provider having a trouble? Guess the CIO will blame you or the provider?

    Lots of people do this now. The "cloud" is being talked about like it's something new, but plenty of companies have their 24/7 website at a hosting provider, or even a co-location facility. Lots of companies have moved mail offsite as well.

    Reliability is hit and miss, but not necessarily worse than an in house data center. I've worked in plenty of companies that lots mail for a day or two across a couple of years time.

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply