Moving to the Cloud

  • Comments posted to this topic are about the item Moving to the Cloud

  • Moving to the cloud should make for an interesting future.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • IMHO the cloud is going to be the biggest change in the way we use SQL Server since the original Sybase port. I think it is likely that by 2015 it will be hard for IT to justify the continued use of any application that is not in the cloud.

    The main driver for moving to cloud is cost reduction. From what am seeing, cloud-based SLAs will be much more standardised that what we are used to, with the end-users seeing the cost implications of their choices. Standardisation of services means less staff needed to manage them, and possibly with less value placed on troubleshooting skills. The end result is far cheaper IT for those applications in the cloud compared to traditional methods of operation. IMHO IT will not be given the budget to keep things in-house when they can be put in the cloud.

    Writing apps for the cloud uses an offset of the skills needed for in-house hosting. This will mean it will become harder to find staff who can maintain in-house apps, making them seem more expensive and less flexible than cloud apps. Those old enough to have experienced the move away from mainframes in spite of their superior facilities know how quickly things can move if the bean counters want it to, even if the people close to the technology see more problems than solutions in the move.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • Yeah, I can totally see the big global finance houses entrusting trillions of dollars in transactions to Microsoft's Cloud architecture - just to name one example. Email? Sure. Documents and spreadsheets? No problem. CRM? Definitely. The blood and guts of the enterprise? Um...no.

    I would dearly love to know Microsoft's DR plan for their cloud-based licensing database. I wonder if it involves some sort of in-house redundancy. If it's absolutely mission-critical, are they really going to allow the public wire to be their weakest link? That just sounds like a bad idea.


    James Stover, McDBA

  • [EDIT: I'm seconding James Stover's post]

    While I can see the case for cloud-based applications involving non-critical, non-sensitive data, you won't see our financial, HR, regulatory, competitive, or proprietary data out there anytime soon.

    The disaster recover requirement alone is a show stopper. We are directed to exercise our DR plans twice yearly. So will the provider participate?

    In the case of cloud-based apps, the first scenario I'd test is an Internet outage. Now what? Use a local instance of the database? I thought part of the idea was to eliminate the need for internal architecture and administration. This selling point falls flat.

    I think I'll just keep a close hold on my data and connections for now.

  • Don't forget that not matter how quick the internet connection, internal connections are at least an order of magnitued faster (or does speed not matter any more?)

    Security is another issue. And what happens when your cloud supplier is based (or stores information) in a country with different government access standards? What control do you have over that? What if your business involves handling of classified or restricted information?

    ...

    -- FORTRAN manual for Xerox Computers --

  • Maybe a lot of us have been sort of working "in the clouds" and just not thought of it that way.

    The company I work for is located in New Orleans. It is supported by our parent company (located in Houston) on corporate servers which are in Austin, Texas.

    This puts the storage of both our data and application software in the hands of others, on equipment we don't own, with access to the data and software through communications lines that we also don't own.*

    So, from a practical standpoint, how is that so far different from being "in the cloud"?

    (*Certainly not my ideal way of doing things given our experience with "inclement weather caused service interruptions" [read hurricanes], but not my call...)

  • I think that there will be lots of movement to the cloud, much like we've seen email and web services move to cloud providers. However I don't share Ed's vision either. I've heard this about outsourcing, and web sites over the last two decades. We still have internal staffs, even in small companies.

    I do think, and would like to see, more cloud based deployments internally, as just generic services that aren't necessarily tied to a machine. You ask for a database, and you just get one that's on your network. You deploy to it in a private cloud, connect to it, everything as a cloud based service. It's just something you control, and you add more servers (internally) to it as you need them.

  • Cloud computing makes a lot of sense for MS and for a lot of customers. For MS because their marketing model is changing to a pay as you use service rather than a single fee purchase followed by efforts to get you to upgrade. The rate of introduction of new & improved technologies will be able to slow. For customers because concerns about DR largely disappear. I know alot of us are not comfortable with that. But that is really cost effective for a lot of small shops. As far as big shops with 100's of gig and Terabytes of data, they are not likely to benefit as much. But they are also customers that already pay for support ongoing.

  • Ralph Nickname (6/21/2010)


    But that is really cost effective for a lot of small shops.

    Having worked in mostly small shops, it is also very high risk.

    If you've purchased the hardware and software, you can still keep running if you have to take the drastic step of cutting out maintenance on them. You just stop paying the bill (granted at some risk).

    However, if you stop paying the bill in the cloud world you can suddenly find yourself unable to continue operating at all.

    And what happens if your business has to retract? Are the cloud vendors going to let you drop back a tier on volume readily, or are you stuck paying for a volume/service level that you can no longer justify or afford?

  • The other DR issue is how quickly will the cloud provider respond when you are down? Having dealt with co-location facilities, the guy renting a rack is way down the list of people to respond to when there is a larger issue in the facility.

  • The benefits and challenges are all very similar to timesharing a mainframe; replace "timesharing" with "scaling usage" and "mainframe" with "cloud of x86 hardware".

    Challenges include, as others have mentioned

    Regulatory compliance

    Security

    Mass data movement back and forth

    Ability to physically oversee equipment

    Your priority with your vendor

    What do you do when your vendor pulls an Enron/Lehman Brothers and vanishes suddenly?

    What do you do when the price gets hiked suddenly?

    What do you do when you need more resources for a time, and they're not present at your vendor (some other group is using them at that time)? Average demand is neat until a peak hits enough groups at once to cause issues (year end financial reporting, perhaps augmented by new regulations coming into effect).

  • I think there is some lack of the warm and fuzzy with the clients that we have, and I don't particularly have it either. Especially when it comes to financial, medical, and proprietary data.

    I also think that the atmosphere for this transition may be suffering a little from the current cyber-wars headlines in the news.

    Tom Garth
    Vertical Solutions[/url]

    "There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves." -- Will Rogers
  • bwillsie-842793 (6/21/2010)


    Maybe a lot of us have been sort of working "in the clouds" and just not thought of it that way.

    The company I work for is located in New Orleans. It is supported by our parent company (located in Houston) on corporate servers which are in Austin, Texas.

    This puts the storage of both our data and application software in the hands of others, on equipment we don't own, with access to the data and software through communications lines that we also don't own.*

    So, from a practical standpoint, how is that so far different from being "in the cloud"?

    (*Certainly not my ideal way of doing things given our experience with "inclement weather caused service interruptions" [read hurricanes], but not my call...)

    You've already answered your own question - "It is supported by our parent company..."

    I think that's the key - you still have some marignal degree of control over the application architecture. Once you hand it over to MS (or anyone else), you are at their mercy. As I say, maybe that's good enough for spreadsheets but not your core LOB apps. It's going to take a lot more that fluffy marketing bullsh*t to convince me otherwise.


    James Stover, McDBA

  • James Stover (6/21/2010)


    bwillsie-842793 (6/21/2010)


    Maybe a lot of us have been sort of working "in the clouds" and just not thought of it that way.

    The company I work for is located in New Orleans. It is supported by our parent company (located in Houston) on corporate servers which are in Austin, Texas.

    This puts the storage of both our data and application software in the hands of others, on equipment we don't own, with access to the data and software through communications lines that we also don't own.*

    So, from a practical standpoint, how is that so far different from being "in the cloud"?

    (*Certainly not my ideal way of doing things given our experience with "inclement weather caused service interruptions" [read hurricanes], but not my call...)

    You've already answered your own question - "It is supported by our parent company..."

    I think that's the key - you still have some marignal degree of control over the application architecture. Once you hand it over to MS (or anyone else), you are at their mercy. As I say, maybe that's good enough for spreadsheets but not your core LOB apps. It's going to take a lot more that fluffy marketing bullsh*t to convince me otherwise.

    Agreed. A parent company has MUCH more incentive to come through for a subsidiary (they both have to answer to the same top management) than an outside company has (there are times when it is cheaper to lose an occasional small customer).

    ...

    -- FORTRAN manual for Xerox Computers --

Viewing 15 posts - 1 through 15 (of 18 total)

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