Should We Move to Azure?

  • David.Poole - Thursday, November 9, 2017 7:41 AM

    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.

    You realise, that your software moved "to cloud" is not actually running on a cloud, right?
    It still runs on some hardware.
    And you expect that hardware to be capable of handling your 3x peak loads.
    Regardless of what kind of peak loads other clients' sotware is experiencing at the moment (for some mysterious reason, all billing systems experience peak loads at the same time).

    So, someone still had to pay up-front for that hardware "regardless of whether the  load materialised or not".
    And that someone is a business, with profit being only purpose of its existence.
    So, whatever they paid for the hardware , they pass to you - as a client using that hardware.
    Full amount + profit.

    You're not saving on cost of hardware when using cloud.
    You're saving on costs of experienced specialists managing the hardware.
    Because all the routines are pretty much the same for all servers.

    _____________
    Code for TallyGenerator

  • Sergiy - Thursday, November 9, 2017 9:14 PM

    David.Poole - Thursday, November 9, 2017 7:41 AM

    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.

    You realise, that your software moved "to cloud" is not actually running on a cloud, right?
    It still runs on some hardware.
    And you expect that hardware to be capable of handling your 3x peak loads.
    Regardless of what kind of peak loads other clients' sotware is experiencing at the moment (for some mysterious reason, all billing systems experience peak loads at the same time).

    So, someone still had to pay up-front for that hardware "regardless of whether the  load materialised or not".
    And that someone is a business, with profit being only purpose of its existence.
    So, whatever they paid for the hardware , they pass to you - as a client using that hardware.
    Full amount + profit.

    You're not saving on cost of hardware when using cloud.
    You're saving on costs of experienced specialists managing the hardware.
    Because all the routines are pretty much the same for all servers.

    But that's the point. That someone who has to make that hardware and software purchase is NOT YOU. Therefore, when you shrink, you don't have that huge sunk cost or dept looming over your business that you STILL have to pay for when technically, you only need to utilize half of that cost when your business shrinks. The AWS/Azure/Rackspace business can find SOMEONE ELSE to fill that cost if you decide to leave the table. There not going to say, "Well, umm, we already bought this hardware for you and therefore, you still owe us money until it's paid for." Thus, you can still show a very positive books when you shrink or god forbid, if you go out of business because these platforms will find someone else to pay for the hardware when you leave.

    The trick is, these platforms are not going to stop charging you when you pay enough to cover the costs of the hardware are software. This is how they are able to offer you more flexibility. Their business is going to make 3x or more the amount of return per hardware and so forth for all the businesses that use it. This is where the benefit of reducing your operations comes more critical to doing cloud versus on-prem. The amount of money you save from your business by reducing the costs of operations is supposed to make the continuation of paying something even after the hardware and software is paid for still the better option long-term. At least, that is my understanding.

  • Jeff Moden - Thursday, November 9, 2017 6:30 PM

    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.

    I think we talked about this in another thread. Here is an example with Azure SQL:

    Cloud Business Continuity

  • Sergiy - Thursday, November 9, 2017 9:14 PM

    David.Poole - Thursday, November 9, 2017 7:41 AM

    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.

    You're not saving on cost of hardware when using cloud.
    You're saving on costs of experienced specialists managing the hardware.
    Because all the routines are pretty much the same for all servers.

    We host a website in azure. 95% of the time it runs happily on 1 core and 1.75gb of ram. 5% of the month it needs to scale in performance - the most we have scaled up to is 5 instances of1 core and 1.75gb ram. Note the scaling up and down is handled automatically.
    If i was hosting on-premise or in a VM in a datacentre or even a VM in azure then I would need to spec the VM to cope with the max load which only happens 5% of the month.
    Therefore I don't understand how you are making a blanket statement that using the cloud is not saving on the cost of hardware.

  • The RPO and RTO is sufficient for this site. Not perfect, but in my experience, regardless of what is noted, there may be a time the company cannot meet the values, and they'll just refund the money, which is a slight fraction of what you pay.

    Note that when the on premise, FTEs can't meet the RPO and RTO, typically about the same thing happens, though there's no savings in hosting cost.

  • FridayNightGiant

    When you scale up - those extra 4 instances aren't materialised from a thin air, right?

    They must be there, and they must be vacant.

    So, someone must have purchased them earlier, and someone had paid for it.

    And it must be sitting there idle, otherwise you won't be able to scale up automatically.

    I wonder - who covered the cost of that idle hardware for the provider?

    _____________
    Code for TallyGenerator

  • that cost is spread among lots of customers, at least, that's how things are priced. 

    Don't forget that you scaling up could mean that someone else scales down? Or they leave Azure. Or something else. The economics and structure of the investment v cost is complex, and not as simple as we'd like it to be.

    Microsoft tries to price where they think attract people and get a return on investment, but they don't buy 100 cores expecting that gets parceled out to 10 customers and they have to live with it. They can account for customers coming and going, buying more at some point, or less (which is often a trend) and still make money while we save.

  • Sergiy - Friday, November 10, 2017 12:48 PM

    FridayNightGiantWhen you scale up - those extra 4 instances aren't materialised from a thin air, right?They must be there, and they must be vacant.So, someone must have purchased them earlier, and someone had paid for it.And it must be sitting there idle, otherwise you won't be able to scale up automatically.I wonder - who covered the cost of that idle hardware for the provider?

    I'm really not sure what your point is. I don't expect what I pay for azure is at cost. There are obviously margins built in and Microsoft use the money from those margins and I'm sure some advanced capacity planning to design and monitor their resources.
    Much like the banks assume every customer won't ask to withdraw all their money at once Microsoft are assuming that every customer won't scale up at once. 

  • Although you have to look at costs you also have to consider what you could do that you can't do now.  Particularly if that something is delivering something revenue generating.

  • Sergiy - Friday, November 10, 2017 12:48 PM

    FridayNightGiantWhen you scale up - those extra 4 instances aren't materialised from a thin air, right?They must be there, and they must be vacant.So, someone must have purchased them earlier, and someone had paid for it.And it must be sitting there idle, otherwise you won't be able to scale up automatically.I wonder - who covered the cost of that idle hardware for the provider?

    Yep, you are right. The hardware already exists, but it's not his company that purchased it ahead of time, it's Microsoft. They pay up front for it until you use it. If he is on-prem, his company would have to pay for that hardware up front or make the purchase after. The hardware he may purchase after if it didn't exist, may be more than what he needs and therefore, the business may have to pay more than what they need to fulfill this request. Once he does not need it anymore, the business still have to recoup that cost before it becomes a sunk cost. 

    Huge difference.

  • xsevensinzx - Thursday, November 9, 2017 11:11 PM

    Jeff Moden - Thursday, November 9, 2017 6:30 PM

    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.

    I think we talked about this in another thread. Here is an example with Azure SQL:

    Cloud Business Continuity

    Now that you mention it, I believe that you're correct about that other thread.  Like Yogi Berra is attributed to saying, "It's déjà vu all over again."  😉

    Thanks for posting the link, again.

    --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)
    Intro to Tally Tables and Functions

Viewing 11 posts - 61 through 71 (of 71 total)

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