Databases Running in the Cloud

cloudI’ve been playing around with running databases in the cloud recently. It’s quite simplistic stuff, just to get a feel for it and investigate the possibilities of using it for some projects at work. Here’s what I’ve got so far.

Overview:

Oracle:

MySQL:

SQL Server:

It’s hard to differentiate between the cloud providers if you are just using them to provide a VM and self managing a system on it. It’s just another box provider.

In contrast the DBaaS offerings are much more interesting. I really like what Amazon are doing with RDS for Oracle/MySQL/SQL Server. I think these would work very well for *our* MySQL and SQL Server installations, which tend to be quite simple. I’m not sure I can live with some of the restrictions for RDS for Oracle, but that’s probably because I’m a snobby DBA type, who thinks he knows best. 🙂 The DBaaS for SQL Server on Azure is also really nice. You get less control than the RDS version, but maybe that’s a good thing.

You might have noticed I’ve not written much about Oracle Cloud yet. I should be getting a trial of the platform this month, so I will be able to fill in those gaps then.

Cheers

Tim…

Author: Tim...

DBA, Developer, Author, Trainer.

15 thoughts on “Databases Running in the Cloud”

  1. Funny enough, we’ve been looking at dbs in the cloud – IaaS, DBaaS, etcetc, for quite a few years.

    And I have yet to see one case where the total cost (TCO?) is less than simply running the show in a private in-house cloud.

    Of course in TCO I include what you so well point out: the cost of the traffic between the db and its clients, the application server(s) and in many cases other dbs. Plus backups, copies to development/uat, etcetc. And licensing, and so on.

    It may come as a surprise to the cloud peddlers but NO user in their right mind needs to create dbs on the fly as a major portion of their work – that is what cloud providers need to do, but not the end clients!
    As such, the often argued “ease of creation” of dbs in the cloud is a completely useless point for the actual users of those dbs.

    You see, the purpose of a db is to be USED.
    NOT created or destroyed!
    And guess what costs a LOT in the cloud?
    The actual use traffic!

    We’ve priced it many, many times. And not once has it been cheaper to run dbs in the cloud when all needed traffic is included in the cost. A traffic that is NOT charged for, in-house!

    But I don’t hold any hopes the peddlers will stop and think: not good marketing, apparently…

  2. Noons: I agree with what you are saying, but there are some other factors.

    Skills: Lots of Oracle, MySQL and SQL Server databases are being managed by people who don’t have the skills to manage them properly, which is putting companies at risk. Most of the DBaaS offerings allow less skilled people to manage them.

    Patching and Upgrades: The DBaaS offerings usually include some sort of automated patching. Ignoring the fact you can opt out, this is a really valuable thing for many companies and trying to get permission to patch can be a nightmare. Saying it is part of the service simplifies the process somewhat.

    If you have a skilled team with a good management structure, I don’t think cloud is likely to be the right move in she short term. For some of the smaller players, I think cloud might make sense today.

    Cheers

    Tim…

  3. Disagree completely on the skills portion.
    Having a db in the cloud doesn’t make it easier to manage by any stretch of the imagination or require less skills.
    Yes, of course: one can use OEM/Grid Control/whatever.
    But last time I looked those tools can be used equally simply outside the cloud, in-house.

    As such, that is not an argument in favour of dbs in the cloud. Or else we stopped speaking the Queen’s language and are now in marketspeak land. In which case, 100% agreed: the skills won’t be needed and the coffee will be great… 😉

    Of course it’s not just the db that needs to be managed. It’s also the OS, storage, etcetc. And in the cloud offerings those are supposed to be implicit. Keyword here is “supposed”.

    Actually in practice and from what I have seen, if you want to deviate one half-byte from the initial spec – including release, patch levels, hardware capacity, etc – you will be paying through your nose to get those changed. A LOT more than it’d cost to do in-house!

    There is a reason why service bureaus stopped being used in the late 70s. It was the same problem back then, except no one dared call it “the cloud”. No difference whatsoever in pricing either: carbon copy of what was done back then. I know because I cut my teeth in IT in service bureaus and what is being done now is simply same old, same old.

  4. Noons: I think we are talking about separate things here.

    If we are talking about VMs on the cloud, then you are responsible for OS, DB, patching, backups, everything. In this case the cloud is just a box provider and skill set is no different to any in-house DBA and sys admin.

    If we are talking about DBaaS, then that is not the case. No OS. No DB installation. No patching. No backup/recovery. No HA config. That is a *very* different proposition. Of course, it comes with some constraints.

    Note. DBaaS offerings vary. AWS RDS is a lot tighter than Oracle Cloud. On Oracle CLoud you get full root access to box and SYS/SYSTEM access to database. On RDS you get none of this and you can’t use Cloud Control.

    Obviously, DBaaS is still in it’s infancy as far as uptake is concerned, but I can see how this will affect the need for DBAs over time, unless you work for a cloud provider. 🙂

    Cheers

    Tim…

  5. I agree. However, the “no need for DBAs ” scare tactic quite frankly is getting old – I wish I had a dollar for every time I’ve heard that chestnut in the last 20 years! 🙂
    FWIW, I think Oracle has a much better offer for DBaaS than Amazon. Unless we are talking dev/uat or very small dbs indeed where performance, maintenance and tuning are immaterial, the Amazon offering is ridiculous.
    And expensive as anything, when one takes into account what they charge for traffic!
    We priced them before our last hw upgrade cycle and quite frankly, the cost of moving our daily volume of data into and out of it would be a small fortune. Let alone the fact that we would have no control whatsoever for the levels of performance required.
    Haven’t yet done the same exercise for Oracle’s offering – they were not available last time we looked – but I don’t expect it to be any much different.
    All these cloud offerings ignore one fundamental aspect of databases: they do not exist of themselves.
    They exist to store data and to process and deliver it when asked for.
    Moving large amounts of data in and out of remote sites somewhere in the world is completely out of the question in sheer cost terms.
    Data needs to be processed. NOT moved around!
    To put it into perspective: in one (1 only, there are many more!) of our prod dbs, we do 10TB of I/O per day, with around 1TB in Net traffic alone. The redo logs top at 400GB in one day. And it MUST do those volumes, non-stop, AND be able to grow to twice that if/when needed, short notice.
    No cloud provider has been able so far to even remotely guarantee a match to those at the cost we produce them in-house.
    Not by a country mile! They’d be mad to even attempt to.
    Note: I’m not claiming they can’t do it. I’m saying they can’t match the cost. It’s that simple.
    Add to that the additonal costs of maintenance and management of these sort of dbs – backups, patching, upgrading, test/dev, etcetc – and the cost equation shows a complete fail for cloud solutions.
    There is no way “getting rid of dbas” would reduce that cost by any appreciable margin: they are not the main component of the current costs, by any stretch of the imagination. To claim they are is just pure marketing-speak.
    Besides, I seriously doubt that any cloud DBaaS solution can completely eliminate the need for DBAs/sysadmins/storage admins and other such support folks, not even counting how much it’d cost to do that.

  6. Noons: I did not say “no need for DBA”. I said reduced need. We already see DBAs handling much bigger real estates than in the past. When they no longer have to deal with installations, configuration, backup, recovery, HA, they will be able to handle even bigger real estates. You will still need DBAs, but for many companies, they will be able to get away with “less” of them, or have less technically skilled people.

    The last point may sound contentious, but I already see this happening. I’m always getting questions from people saying, “I’m and SQL Server DBA and I’ve been put in charge of Oracle, how do I … ?”. For these types of companies, that let this happen, the cloud can bring some real benefits. Is it better than hiring competent staff? No! Will they hire competent staff? No!

    I think the issue here is you are talking about an edge case. Every company will have one, where cloud is not appropriate, but many companies will have loads of systems that fall right in the centre of the bell curve, which is likely to be suitable for cloud. Am I saying one size fits all? No. What I’m saying is it can play a role for every company in future, even if it doesn’t satisfy all their needs. 🙂

    I think a blog post on this subject is in order… 🙂

    Cheers

    Tim…

Comments are closed.