Should We Move to Azure?

  • I think for me, having to go to someone on-prem and saying I need X, Y, and Z to make this work has a high tenancy to lead to acquiring and purchasing additional hardware, setup, and costs. This requires a lot of prep in some organizations to make happen. Cloud on the other hand, it's extremely easy to spin up on hardware you do not own. The ability to be lean there is pretty awesome. It also can be put into your hands a lot easier than someone else.

    On top of that, another cool benefit I've noticed lately is the fact AWS, Azure and the works have new tech and features coming out all the time. While you may just need a VM and SQL Server, you also have the ability to pivot towards other tech you may not event try because you just don't want to spend the time also finding a test bed, installing it yourself and all that jive. They do make it very accessible for you to try out Hadoop for example, or PostgreSQL, and so forth extremely easy.

    But yeah, I could totally be fine with my existing hardware I could feel and touch. I could have my own dedicated disks that are not virtualized and all that jive. Sounds really awesome up until the point I pivot to needing more and needing it fast.

  • I think xsevensinzx hit it on the head - cloud services have automated the request process for asking for more hardware or services - that process alone in some organisations is either unavailable to many or takes a ridiculous amount of time and energy.

    It very much standardises the platform and processes as well for employees between companies - no more learning new admin processes every time you move to a new company or knowing "the" person to talk to about all the undocumented configurations that take a few months or years to get to grips with.

  • David.Poole - Wednesday, November 8, 2017 1:57 AM

    I've spent 3 years dealing with AWS so I would be asking whether the tasks that go away due to the move to a cloud provider allow you to pursue activities that are more beneficial to your organisation.
    ...
    If a company starts shifting to the cloud there comes a tipping point beyond which the cost of paying for their own data centre just doesn't make sense.  You end up with a few systems having to bear the brunt of the costs of that on-premise data centre, at which point on-premise no-longer makes financial sense.

    We're already slightly in the cloud at Rackspace. We started moving many things off-premise to ease the burden on IT. We don't really have less IT, but they can do more because they don't play hardware games. Been a positive move.

  • bkubicek - Wednesday, November 8, 2017 6:37 AM

    I have a hard time believing that the cloud would be cost effective for a site like SQLServerCentral.  It seems like the pricing in the cloud it still a bit expensive.  I guess that might be a good first step is to better quantify how much is running the site currently costing you?  How much more would it cost to put it in the cloud?  Then the debate might be more on if that cost difference was worth it or not?

    Ben

    Cheaper than our hosting costs now in Azure/EC2.

  • Dalkeith - Wednesday, November 8, 2017 8:07 AM

    I think xsevensinzx hit it on the head - cloud services have automated the request process for asking for more hardware or services - that process alone in some organisations is either unavailable to many or takes a ridiculous amount of time and energy.

    It very much standardises the platform and processes as well for employees between companies - no more learning new admin processes every time you move to a new company or knowing "the" person to talk to about all the undocumented configurations that take a few months or years to get to grips with.

    Not to ignore xsevensinzx, but for both of you, we have much of this already. We have demo systems in EC2, and I can click a button to spin up a new copy of one in about 10 minutes. Rather amazing. Adding more hardware fairly easy. 

    It's pretty easy at Rackspace now, but a bit pricey.

  • The reason we left the mainframes, back in the 80's was so we owned our data, etc...
    We were not left to the discretion of the provider for access to our data and their ability to change their "rates of service" to access our data. 
    Do you really want to go backwards, and allow you data to become hostage to MS, or AWS or any other provider.
    Yes, you should have co-locations even if one of them is "The Cloud" but never give all of your systems to anyone who can take advantage of you.

  • Frank W Fulton Jr - Wednesday, November 8, 2017 5:20 PM

    The reason we left the mainframes, back in the 80's was so we owned our data, etc...
    We were not left to the discretion of the provider for access to our data and their ability to change their "rates of service" to access our data. 
    Do you really want to go backwards, and allow you data to become hostage to MS, or AWS or any other provider.
    Yes, you should have co-locations even if one of them is "The Cloud" but never give all of your systems to anyone who can take advantage of you.

    You echo my thoughts on this subject.  I know that some folks will argue many advantages but I loath the idea of data possibly being held hostage, being at the whim of any "decisions" the provider may make to rate, hardware, RPO, RTO, and not trusting their security, etc, etc, etc.  That may sound a bit old fashioned but I'll also state that I didn't get this old by not being cautious.

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

  • Jeff Moden - Wednesday, November 8, 2017 6:20 PM

    Frank W Fulton Jr - Wednesday, November 8, 2017 5:20 PM

    The reason we left the mainframes, back in the 80's was so we owned our data, etc...
    We were not left to the discretion of the provider for access to our data and their ability to change their "rates of service" to access our data. 
    Do you really want to go backwards, and allow you data to become hostage to MS, or AWS or any other provider.
    Yes, you should have co-locations even if one of them is "The Cloud" but never give all of your systems to anyone who can take advantage of you.

    You echo my thoughts on this subject.  I know that some folks will argue many advantages but I loath the idea of data possibly being held hostage, being at the whim of any "decisions" the provider may make to rate, hardware, RPO, RTO, and not trusting their security, etc, etc, etc.  That may sound a bit old fashioned but I'll also state that I didn't get this old by not being cautious.

    I think these are fair concerns, especially with the security piece. Just taking the most recent major breach with Equifax, you kind of know that they have this information, but you really don't put much concern into it because you may automatically assume they are locked up tighter than anyone else in the world. Then it hits you, they just got compromised and your social was potentially part of some theft along with your CC number if you had an account with them.

    We are surely putting a lot more blind trust into companies than we used to. Cloud platforms are not immune to this either. But, at what point do you start being similar to the person who never goes outside their home because they fear the world? When is the risk necessary in order to push forward? You may find that you are always stuck in that house while the world (i.e.: technology) passes you by.

  • xsevensinzx - Wednesday, November 8, 2017 10:07 PM

    Jeff Moden - Wednesday, November 8, 2017 6:20 PM

    Frank W Fulton Jr - Wednesday, November 8, 2017 5:20 PM

    The reason we left the mainframes, back in the 80's was so we owned our data, etc...
    We were not left to the discretion of the provider for access to our data and their ability to change their "rates of service" to access our data. 
    Do you really want to go backwards, and allow you data to become hostage to MS, or AWS or any other provider.
    Yes, you should have co-locations even if one of them is "The Cloud" but never give all of your systems to anyone who can take advantage of you.

    You echo my thoughts on this subject.  I know that some folks will argue many advantages but I loath the idea of data possibly being held hostage, being at the whim of any "decisions" the provider may make to rate, hardware, RPO, RTO, and not trusting their security, etc, etc, etc.  That may sound a bit old fashioned but I'll also state that I didn't get this old by not being cautious.

    I think these are fair concerns, especially with the security piece. Just taking the most recent major breach with Equifax, you kind of know that they have this information, but you really don't put much concern into it because you may automatically assume they are locked up tighter than anyone else in the world. Then it hits you, they just got compromised and your social was potentially part of some theft along with your CC number if you had an account with them.

    We are surely putting a lot more blind trust into companies than we used to. Cloud platforms are not immune to this either. But, at what point do you start being similar to the person who never goes outside their home because they fear the world? When is the risk necessary in order to push forward? You may find that you are always stuck in that house while the world (i.e.: technology) passes you by.

    I guess my take on it is, and it's not a question on my part... it's a statement... Why does there have to be a risk to push forward.

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

  • I'm not sure my data is being held hostage moving to Azure. It's not onsite now, and hasn't been for well over a decade. Plenty of service providers could have held something hostage, and still could. I'd argue it's less likely Microsoft would/could cut off access than some small provider. We would still do backups to remote places.

    Could they change the cost? Sure. Same as any other contract provider we use. However, we can contract as well, and plan for rates.

    Security is always an issue, but that's mostly our issue for now. We run on VMs and we're responsible. Azure or AWS provides some more protection from DDOS and other attacks because they scan traffic. We didn't do that in our own cage, and not sure what Redgate would do, but not sure Rackspace does anything here. They might.

    These days, many, perhaps most, companies use some sort of "cloud" vendor. They use a hosting provider. I'd guess that many companies don't host all their own systems, perhaps just the public ones. They negotiate contracts for their hosting, just as they would for the lines that provide service to the office, to the owners of space, etc. The cloud can be month to month, but it can also be year to year. Most people that use the cloud go month to month because prices keep falling.

    In the mainframe days, plenty of people were at the mercy of chargers from vendors as well. however, vendors need to do business, not squeeze as much out of their customers as possible. They value stability as much as the customers. I would say the idea that some cloud provider might hold a small company (like Redgate) hostage from their data is a bit over the top.

    Is there risk? Sure. Moving anywhere involves risk. Rackspace is a safe choice, as I'd say AWS is as well. However, there's a cost there. Could we move to some other hoster? Sure. Risk there. Move back to the Redgate office? more risk, given the fluctuating Internet speeds I see over there. There's always some level of risk, but I think Azure/AWS is less risk than most.

  • I'm not worried about being held hostage by big cloud vendors such as AWS, Microsoft et al.  I think it much more likely that vendor lock in the on-premise world occurs due to the choice of corporate applications and the difficulty in shifting off them.
    Security is a bit of a strange beast.  If you build your own infrastructure in AWS then you can build it insecurely.  If you work for an organisation of a size to have access to AWS personnel then they can advise on security design.  It is certainly possible to design infrastructure and processes to be secure.  The skills that will build a really secure AWS infrastructure are equally applicable to on-premise scenarios.

    The ability to deliver an entire project to production faster than the time it takes to procure hardware on-premise is a huge bonus.

    The use of cloud facilities does require a change in mindset.  You have to shift from the stance of "we are not doing this because of security concerns" to "We will proceed when these specific security concerns have been mitigated and fully understood".

    One of the benefits of the cloud is NOT its ability to scale up, but its ability to scale DOWN.  On premise I would have to buy hardware capable of handling 3x peak load to last for 5 years.  I had to pay up-front regardless of whether the  load materialised or not.  With the cloud I can buy for the traffic I actually have.  If it's greater than whoopee doo, if not then I'm not paying for capacity I'm not using.

  • Still keeping an open mind about it all (you have to, in this business), does anyone know of a publically available "Before'n'After" cost analysis of "On Premise" vs "Cloud" that hasn't been written by either a heavy metal vendor or a cloud vendor?  And, by "Cost Analysis", I also include the people necessary to make "On Premise" successful.

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

  • Jeff Moden - Thursday, November 9, 2017 8:26 AM

    Still keeping an open mind about it all (you have to, in this business), does anyone know of a publically available "Before'n'After" cost analysis of "On Premise" vs "Cloud" that hasn't been written by either a heavy metal vendor or a cloud vendor?  And, by "Cost Analysis", I also include the people necessary to make "On Premise" successful.

    Not much public. Part of why I'm interested in trying this.

    I know of a private one. They estimated 2 less FTEs and tax savings from movement, plus much less capital investment (they needed to replace hardware). I think they ended up somewhat meeting their goal here, though the FTEs moved to other work, so hard to compare. The feedback I got about 14 months in was that they were happy with the way the $$ worked out. I'm curious how they'll feel at 3 years.

  • Jeff Moden - Thursday, November 9, 2017 8:26 AM

    Still keeping an open mind about it all (you have to, in this business), does anyone know of a publically available "Before'n'After" cost analysis of "On Premise" vs "Cloud" that hasn't been written by either a heavy metal vendor or a cloud vendor?  And, by "Cost Analysis", I also include the people necessary to make "On Premise" successful.

    There are some out there, but at the end of the day, you may just be moving from one VM hosted on your hardware in your data center to someone elses hardware in their data center. So, you still may see the need to hire the sys admins, the network admins, and the DBA's to maintain that infrastructure in your virtualized env or theirs.

    The cost savings for me is going to be through the semi and fully managed services these cloud platforms offer. The other is going to be the turnkey feel you get with having complete ease and power to quickly spin up and spin down your infrastructure. You may find that you can get more scale out of your IT resources because the tools are easier for them to manage more resources than before. Therefore, you can save on costs from a operations standpoint there too.

  • xsevensinzx - Thursday, November 9, 2017 3:31 PM

    Jeff Moden - Thursday, November 9, 2017 8:26 AM

    Still keeping an open mind about it all (you have to, in this business), does anyone know of a publically available "Before'n'After" cost analysis of "On Premise" vs "Cloud" that hasn't been written by either a heavy metal vendor or a cloud vendor?  And, by "Cost Analysis", I also include the people necessary to make "On Premise" successful.

    There are some out there, but at the end of the day, you may just be moving from one VM hosted on your hardware in your data center to someone elses hardware in their data center. So, you still may see the need to hire the sys admins, the network admins, and the DBA's to maintain that infrastructure in your virtualized env or theirs.

    The cost savings for me is going to be through the semi and fully managed services these cloud platforms offer. The other is going to be the turnkey feel you get with having complete ease and power to quickly spin up and spin down your infrastructure. You may find that you can get more scale out of your IT resources because the tools are easier for them to manage more resources than before. Therefore, you can save on costs from a operations standpoint there too.

    Thank you and Steve both for the feedback,

    Have you checked on what they offer for RPO and RTO?  I've got a friend that looked into it for his company and he said the values for those are ridiculous unless you want to pay out the nose for their premium packages.

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

Viewing 15 posts - 46 through 60 (of 70 total)

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