The Cloud is Better In At Least One Way

  • Comments posted to this topic are about the item The Cloud is Better In At Least One Way

  • I read the article about Azure that you provided the link for.  Other than having someone else do the dirty work, I'm not really seeing any advantages there.  For example, in the section titled "Addressing Customer Data Integrity Issues", I see absolutely nothing there that a good DBA wouldn't do.

    What I do see is uninitiated people getting even more of a perception that you don't need a DBA at all.  Even with Azure, I'm still not seeing that to be true.

    Also, I can't speak of the engineers and other people that support Azure and the boxes it lives on.  I have seen other "equipment providers" and a good deal of them actually suck wind for either operating system or SQL Server backups and restores.  Heh... I actually had to train one that weekly backups follow by once-a-day log backups was simply not acceptable and why.  They retorted with the idea that a log file backup every half hour would take too long and would also take too much disk space.  Obviously, they didn't have a bloody clue and I had to get them to "do the experiment" to prove to them that wasn't the case.  I also had to train them that 8 parallel backup streams to the same disk(s) was actually going to be slower than a single serial backup stream.

    I recently had a conversation with Ed Wagner about a "cloud" provider (I don't know if it was Azure or not.  I'll have to ask) and they wanted nearly a quarter million dollars a month and had a miserable RTO and RPO.  Here I am thinking that I've not done my job if I can't recover up to the minute (personal RPO near zero loss) with an RTO of an hour or less and these other folks are saying RTO is something like 48 hours with and RPO of at least 24 hours.  That's simply not acceptable.  Unless corruption is a problem, an RPO > 30 minutes is unacceptable to me and I'm setting up to take that down to 10 minutes.

    We also have some offsite hardware mirroring going on and the folks in OPS have made it nasty fast as well as clustered systems.  Restores and the RPO there are just the last resort because these other methods have been tested out to usually less than 60 seconds of potential data loss and that's without having to do a Tail-Log Backup. 😉

    Anyone know what the RPO/RTO for Azure systems is?

    --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 - Saturday, October 14, 2017 9:07 PM

    Anyone know what the RPO/RTO for Azure systems is?


    Azure RPO

  • Sorry, double post. Please ignore.

  • xsevensinzx - Sunday, October 15, 2017 5:46 AM

    Jeff Moden - Saturday, October 14, 2017 9:07 PM

    Anyone know what the RPO/RTO for Azure systems is?


    Azure RPO

    That's pretty damned good, especially the Active geo-replication.  I wonder what the difference in cost between that and the "Geo-replicated backups" are?  Guess I'll try my skills at Yabingooglehoo to find out, unless you happen to just have one.

    --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 didn't find the specific pricing I was looking for but I did click on the pricing link in the menu at the top of the page... not bad if you consider the human costs associated with local data centers.  At 250MB/Sec, their SSDs are about half as fast as what we have setup.  We're crankin' at 500MB/Sec.

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

  • Any particular person can out optimize the cloud, especially for value costs.

    Jeff, if you want to compare yourself to Azure, I'm sure you'd win. However, for many businesses, that's not the case. Look back at your interview notes and then convince me the cloud doesn't work better. Most companies don't have anyone dealing with corruption, and certainly not senior engineers responding to every alert to dig. Most couldn't immediately move to new storage if there are issues.

    The cloud works well for lots of people and really well for some problem domains. Triple redundancy of storage and geo replication are nice features. I'm not sure most of us could implement that well. That being said, it can be pricey, which is something to be aware of. Certainly some cloud vendors don't do as good a job as others.

  • Steve Jones - SSC Editor - Monday, October 16, 2017 7:44 AM

    Any particular person can out optimize the cloud, especially for value costs.

    Jeff, if you want to compare yourself to Azure, I'm sure you'd win. However, for many businesses, that's not the case. Look back at your interview notes and then convince me the cloud doesn't work better. Most companies don't have anyone dealing with corruption, and certainly not senior engineers responding to every alert to dig. Most couldn't immediately move to new storage if there are issues.

    The cloud works well for lots of people and really well for some problem domains. Triple redundancy of storage and geo replication are nice features. I'm not sure most of us could implement that well. That being said, it can be pricey, which is something to be aware of. Certainly some cloud vendors don't do as good a job as others.

    Heh... even the Cloud won't help some of the folks I've interviewed.  😉  One mistake on their part and they'll be paying through the nose.

    With regard to being pricey, after looking at some of the pricing, I'll admit that, done correctly, it does seem that it could be less expensive than hiring the group of people we employ to handle the onsite hardware/upgrades/etc although I don't believe it would be less expensive for us (would need to do a full blown analysis to say so one way or the other, to be fair to both sides).

    --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 would say that pricing is very workload dependent. If you're often a steady state, then it's really hard to make the cloud cheaper, assuming you aren't trying for 2-3 copies of all data at two (or more) locations. The cloud gets expensive. If you're growing (or shrinking) the workload, the cloud makes more sense.

    One more thing, it seems that if you are looking at a workload that is skewed heavily towards CPU or Memory, without the other factor growing, then the cloud doesn't seem to fit as well. Most of the IaaS stuff scales fairly linearly. Some exceptions, but mostly more RAM = more cores, which might not be a cost effective use for you.

Viewing 9 posts - 1 through 8 (of 8 total)

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