Tag Archives: support

Oracle Blamed for Laws of Nature

A catchy headline, and I believe more accurate than Oracle Puts the Squeeze on SMBs with MySQL Price Hike (Network World) and MySQL price hikes reveal depth of Oracle’s wallet love [MySQL Jacking up MySQL Prices] (The Register). Slightly more realistic is Oracle kills low-priced MySQL support (again The Register).

First, let’s review what Oracle has actually done: they ditched the MySQL enterprise Basic and Silver offerings. For Oracle, that makes sense. Their intended client base is “enterprise” (high end, think big corporates) and their MySQL sales and cost structure reflects this. It’s not a new thing that came with MySQL at Oracle, because MySQL at Sun Microsystems and MySQL AB before it had the same approach.

A company simply cannot operate below its market – that is not simply a matter of choice, instead it is dictated by their processes and cost structure. Smart people like Clayton Christensen at Harvard Business School have done ample research on this, here I’ll just give one simple example:

If you hire a sales person on commission and their quarterly quota is $100k, then they have to talk with clients that have at least a $10k-$20k potential (qualified leads), and they need to close (sign contract) with at least 10 within the period. They simply cannot spend any time on talking with potential $1k customers.

We may lament this state of affairs, but you can see how, given the choices made (sales person hired, commission system, quota), it’s as inevitable as an apple falling when you drop it. The way I describe this at Upstarta: if a company wants different results, they need to make sure that their business processes and cost structure lead them in that direction. But the simple fact is that most companies don’t have an internal feedback cycle that keeps an eye on these things, so they just go with the flow of consequences of common choices: aim for large(r) clients, grow turnover, get higher operational costs along the way – that in itself is a cycle and the only direction this particular one can go is up. As a natural consequence, over time old low-end offerings and clients need to be jettisoned – one way or another.

I say horay for Oracle to finally acknowledge this, since Sun Microsystems and MySQL AB before it did not (for whatever reason). This is years overdue. Whether the original MySQL company should have aimed to also serve smaller clients also is an entirely separate topic – and one which I covered at length previously (including internally in my time at MySQL AB), but it’s very much a station long passed. Once you float upward in the market, you can’t operate or move downward.

Now, are SMBs using MySQL actually getting squeezed by Oracle? They are not. There is no lock-in. This is about service contracts, not licensing. As we all know, MySQL is GPL licensed and internal use (even on a website or SaaS offering) is well within GPL parameters. There are a number of different companies offering service for MySQL, different types of service and delivery models and a corresponding wide range of pricing. So SMBs and anyone else has a choice, each can pick the type of service most suited to their needs. Let us celebrate and promote that freedom within the MySQL ecosystem, rather than being outraged about dropped apples falling!

Today’s up-time requirements

When asking about up-time requirements set down in SLAs (Service Level Agreements) with our clients’ clients, we’d hear anything ranging from hours to the familiar five nines, but these days also simply 100% and otherwise penalties apply. From my perspective, there’s not much difference between five nines and 100%, 99.999% uptime over a year amounts to a maximum of little over 5 minutes outage. In many cases, this includes scheduled outages!

So, we can just not have any outages, scheduled or otherwise. Emergency support is not going to help here, because however fast and good they are, you’re already in serious penalty time or well on your way to not having a business any more. Most will respond within say 30 minutes but then need up to a few hours to resolve the issue. That won’t help you, really, will it? And in any case, how are you going to do your maintenance? The answer is, you need to architect things differently.

I do appreciate the issue of transitioning from the corporate tradition of outsourcing the liability along with emergency support, e.g. someone to call and if need be sue… it takes time both in business processes as well as in actual architecture to make things resilient. But really, if those are the SLAs you agree on with your clients, that’s what has to be done.

Anyway, aiming for resilience (expecting things to break but building infra so that it can cope with it) rather than purchasing many-9s is I think a better focus. This because making an individual component even more reliable becomes prohibitively expensive, whereas having more servers is relatively cheap. That’s simple economics.

Business insight from the MySQL Conference 2010

At this year’s conference, I was pleasantly surprised with the high level of interest in Open Query’s proactive services for MySQL and MariaDB, and specifically our focus on preventing problems, while explicitly not offering emergency services.

I’ll describe what this is about first, and why I reckon it’s interesting. When you think about it, most IT related support that includes emergency (24×7) operates similar to this:

You have a house that has the front and back doors wide open with no locks, and you take out an insurance policy for the house contents. After a short time you call the insurance company “guess what, the most terrible thing happened, my TV got stolen.” Insurance company responds “that’s dreadful, you poor soul, let us fix it all up for you with getting a new TV and installing it. It’ll be our pleasure to serve you.” A few weeks later you call the insurance company again “guess what …” and they help you in the same fabulous way.

You get the idea, it’s rather silly because it’s very predictable. If you leave your doors open, you’re very close to actually being the cause of the problem yourself and insurance companies tend to not cover you under such circumstances – yet most IT support arrangements do. If IT support were actually run like insurance, premiums would be based on a risk assessment, and consequentially most companies would have to pay much higher premiums.

Much of this is actually about company processes as much as the technical setup. Depending on how you arrange things in your business, you can actually be very “emergency prone”. Since company processes are notoriously hard to change, many businesses operate in a way that is fundamentally not suitable for Open Query to do business with. That’s a fact and we’re fine with it, the market is big enough. We have clients all around the world, but so far very few from Silicon Valley. My presumption was that this was due to the way those businesses are often set up, making them simply incompatible for our services. But a significant number of companies we spoke with at and around the conference were very interested in our services exactly because of the way we work, and so that to me was interesting news. A good lesson, making attending the conference extra worthwhile. It’s also a good vote of confidence in the way we’ve set up our service offering.

100% subscription renewal

I’m happy to note (this is internal Open Query happiness but I’m pleased to share) that so far we have a 100% renewal rate for our Proactive Services for MySQL subscriptions. Some of the early clients have grown in the initial period and are have now moved to a higher # of hours (this can also be changed upward during a term), which is of course excellent both for the clients and for us.

I was in eager anticipation of this time since the introduction of the concept late last year, as it is of course the essential proof of whether a subscription service actually works over time. Ideally, you’d want renewal to be a simple straightforward process, with the client having experienced the value of the service. This is relatively straightforward in this case, since it’s not an insurance, emergency or retainer type arrangement – the client actually gets benefits each and every month, so there’s both technical progression as well as ongoing human contact. Seems like a winner!

Along the way we also see a steady influx of new clients. I haven’t been specifically chasing this, as all new concepts take a while to mature, and we also had new people internally. The really cool thing is that our business structure for this service is scalable – I won’t say linearly because at some point the # of internal people involved would require adapting some processes, but it’ll scale a fair way still from where we are now.

Elspeth, ourĀ Special Projects Operative, who apart from an ace coder&geek is also organisationally organised, has been a great help with some of the admin aspects of the company. We’re paper-less, but that doesn’t mean there’s no paper. We tend to not produce more, but we do get it from others ;-)