The Managed Cloud Database Options

  • Comments posted to this topic are about the item The Managed Cloud Database Options

  • ".. There are pros and cons for all of them, but to me, the Google option is interesting. It gives you an instance (with SSIS/SSRS) and a proxy, but it does have limit you to instance restores. Same for RDS, which is a limitation I'd be worried about. Often I have an issue with a database, really often with just a table. Restoring a whole instance instead of a db might be a delay I wouldn't want to deal with. I hope this changes over time, as not recovering a database from an instance is a big hole to me. .."

    It sounds like Google and Amazon are just leveraging VM or container backups, which is a lot simpler to manage on their end. It covers the disaster recovery use case, but still would not be desirable, unless there is a significant trade-off in terms of price point relative to Azure hosting.

    If we need to restore one specific table, then I'm guessing we could spin up a point in time backup to another temporary VM and import the data from there.

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

  • You might be right. I hadn't thought about how, but I assumed they just set something basic and simple up, good for them, not for me.

  • I think of Cloud DBs as being somewhat like hire cars.  What you get is road worthy but more likely to be a Dacia Duster rather than a Golf GTI.

    In the days where our stuff was in our own data centre we sized our DB servers for 3x peak load to allow for traffic growth.  The hardware refresh cycle was between 7 and 10 years so we tended to over egg the pudding knowing that the rigmarole of getting approval for and going through the process of acquiring new hardware was painful.

    On the data centre DB server(s) we would add DBs for new apps as the spare capacity was more than adequate.  The result was DB servers that were massively over-provisioned and that 3x peak load never occurred.  In fact, even peak load was a worst case scenario.

    In the cloud you size for what you need.  You may also work out which DBs need a larger instance and which DBs can co-exist on a small instance.

    I've found that if someone is given immensely powerful IT resource at someone else's expense then they are none too careful about how it gets used.  In a data centre that translates to being careless with that 3x peak load headroom.  In the cloud that translates as spinning up more instances than are necessary.

    The longer you spend in your career the more you realise everything comes and goes in cycles.  All data projects come under one of three headings

    • Revenue generation
    • Process control
    • Cost management

    I think cloud data projects this year will be in the cost management camp.

Viewing 4 posts - 1 through 3 (of 3 total)

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