Tony Bain

Sun, Clouds and now Drizzle

We have been discussing Sun’s acquisition of MySQL recently and common consensus was that we saw the key opportunity for MySQL was in the cloud, and hence an expectation that Sun would be announcing a Cloud MySQL offering sometime soon to start to justify their $1 billion investment.  That seems a somewhat more likely now that Suns director of architecture has gone public with his MySQL cloud project, codenamed Drizzle.

Essentially they are following the same starting strategy as the other early entries into this space (such as Microsofts SSDS).  Strip out all the stuff a relational database has that isn’t 100% necessary for basic CRUD operations (features that all carry some level of performance overhead) then focus on making the simplistic  shell that is left scale to address key cloud issues (very large data volumes, multi node partitioning, online provisioning, fault tolerance and redundancy etc).

While he has been clear in stating that this is not a “Sun/MySQL” product, I think this is just the unusual path that open source software follows and if it is successful eventually Sun will pick it up and start to offer a Cloud SaS offering (this project has apparently beenencouraged by Sun’s “upper management”). 

SQL Server – The Low Cost Alternative to Open Source

An interesting situation that I have noticed quite in recent times is that enterprise organisations looking to save on their database costs have been changing their preferred platform from Oracle, Sybase and DB2 not to Open Source but to SQL Server.  There are a number of reasons for this, but predominately:

• SQL Server has shown to require a significantly lower TCO than Oracle.
• Almost all vendors that create databases applications have an Oracle or SQL Server option. Application compatibility / availability will be one of the key criteria’s behind such a decision.
• The enterprise still has a large vendor behind the offering with account management and support escalation processes that can be engaged when really necessary.

At the moment, Microsoft has been providing a “best of both worlds” alternative to Open Source, which the enterprise has made the move to.  For example, most of the major banks in Australia have SQL Server as their preferred platform and only implement Oracle if there is no application compatibility with SQL Server.  If “SQL Server” wasn’t filling in this gap, it would be easy to see that MySQL or PostgreSQL in such a position.

But as we know, people are always looking for ways to save money.  So what will be interesting is what happens in 3 to 5 years when these enterprise sites look to reduce the TCO of their SQL Server database infrastructure.

Database Management System Vendor Share

I have just finished reviewing IDCs Database Management Vendor Share results for 2007 and thought I would highlight some of the interesting results:

Microsoft’s SQL Server growth rate dropped from 25% in 2006 to 14% in 2007.  That has got to be a big concern over at Microsoft.  This basically shows they are not gaining market share from IBM and Oracle, just maintaining their current position and growing pretty consistent with market growth.  This puts a lot of expectations on the shoulders of SQL Server 2008.

Oracle’s 11G release nothing in terms of Oracle gaining any market share from Microsoft or IBM.  Oracles share relative to its 2 main competitors stayed constant during 2006 and 2007 at 112%.  Again introducing major releases to maintain the status quo instead of gaining new ground has to be a concern for everyone.

MySQL continues to have very low revenues and the lowest growth rate of any of the niche products, with revenues growing at a mere 10%.  This is below market growth, but significantly below that of a niche product finding its feet.  This is one to watch for next year to start to assess Sun’s impact.

Despite Oracle and Microsoft holding much of the media limelight, DB2 keeps trucking along giving up no market share to any competitor in over 3 years.  DB2 has maintained a consistent market share of 21% during this time.

The top 90% of the database market seems to be pretty well sewn up and locked in with the 5 top vendors for the near future.  However the remaining 10% (a $1.9b market) is highly flexible and offers significant opportunity to niche vendors with niche products.  Of course the top 5 will also be looking to this area to gain market share as it currently appears fruitless in trying to gain this off the other 4 key vendors, so expect more focus, acquisitions and innovation in the areas outside core RDBMS services.

Enterprise benefits following SSDS?

While SSDS doesn’t appear to have an immediate significant impact for the enterprise, the key thing to keep in mind is underneath the SSDS offering Microsoft is running SQL Server in a “grid” style architecture.  One would assume that the learning’s and technology Microsoft has developed in putting together the SSDS platform will flow through to the wider SQL Server product on a future release.  While there are no specific Grid capabilities in the upcoming SQL Server 2008 release, let’s hope that the long overdue, game leveling cloud enabling feature becomes a reality in the next release of SQL Server due 2010/2011.

RockSolid Eventing

Eventing is one of those killer features in RockSolid that everyone who has been involved in managing a production SQL Server environment instantly sees the benefit of.

RockSolid monitors SQL Server instances and picks up on everything that occurs from a performance, security, recoverability, maintenance or configuration aspect.  Obviously everything that is detected as an “issue” of some kind raises a service request and these service requests go through the resolution processes (including automated resolution).  However everything that occurs that is not necessarily a problem at that point in time (such as a backup completing, a new user being created, a stored procedure being altered) etc is logged in RockSolid as an event.

Eventing is very useful therefore for inspecting an audit trail of routine and ad-hoc events that have occurred in a SQL Server environment.  Reviewing change history, security audits, recovery audits etc all have very useful roles in system management, but one of the most interesting roles of eventing relates to its application in performance management.

Now to put some context around this, many SQL Server performance tools will show you data around system performance and most good ones will be useful for displaying when negative situations have occurred, for example by graphing data.

This is an example graph, maybe it is slow the response time of a particular query, maybe it is showing your average CPU utilization, or your log growth rate.  Doesn’t matter, the point is the graph shows you that there has been a significant change from whatever the norm was to what the norm is currently.  Now this is typically the point where the tool stops providing information, and the DBA now goes off to perform manual investigation to try and unearth the cause of the change in performance levels.

RockSolid on the other hand, makes available its event analysis capabilities.  Events are categorized based on area of impact (performance, security, recoverability, availability) and the level of impact in those areas.  Events also have content, for example an event may have a performance impact on a specific stored procedure, table, database or an entire instance.

As a DBA investigating a performance issue, you can start with the analysis graphs in RockSolid which shows you a change in some performance aspect has occurred.  But then you can request event analysis  and RockSolid will present to you the most relevant events that occurred in the lead up to the change observed, explaining factors that could be responsible for such a situation. 

For example, you may review the performance of a given stored procedure and notice that it is running 20% slower than it did last week.  Requesting event analysis shows that a few days ago that particular stored procedure was altered and a query within that stored procedure had some additional predicates added.  Clicking on that query would show that the indexing that was in place prior to the change is no longer relevant to this query following the change, so currently a number of scans are being used when previously seeks were in use.  As a DBA you may choose to alter or add indexing to mitigate this impact.

Another example may be that on reviewing a monthly performance summary report, you notice that mid month the daily I/O levels increased for a given instance significantly.  Requesting an event analysis from RockSolid could show up that at this time a new reoccurring query was executed for the first time.  Drilling into this query you see that it has been run on a frequent basis since its first execution mid month.  This was due to a new application report being deployed at this time, and as a DBA you can now take steps to optimize that report query if necessary, or speak with the application manager about the impact of the new report.

In summary, the purpose of RockSolid eventing is to provide explanation around why changes in system dynamics have occurred.  The examples I have spoken about in this post refer to performance, but event analysis covers all key areas of database management including security, recoverability and availability.

Does Performance Trump Everything?

In our recent discussions around the Cloud Database offerings, we have mentioned that many of these services have deprecated many of the traditional RDBMS functions such as user defined transactions and referential integrity.  Over several decades these have been considered critical, non debatable database features.  I can’t imagine someone implementing a database application in an enterprise 10 years ago that wasn’t ACID compliant, you would have been nailed by the DBA and laughed out of the client as being non-enterprise ready.

What is interesting about this is though is more recently, over the last 3-5 years I have noticed a strong shift in application development away from many of the core RDBMS principals.  More and more applications, while using a RDBMS platform that supports ACID fully, are using uncommitted isolation levels, not running statements in user defined transactions and not implementing DRI.

The key reason?  Performance (including scalability and concurrency).  The most visible issue with an application is one that performs poorly, and with modern day scalability requirements in terms of concurrent users and data volumes application developers are avoiding as many of the ACID requirements that impact performance as possible.  How many 300GB databases did we see 5 years ago?  Now 100GB is an average size departmental database. 

Justification is that system failures are relatively rare, application code is heavily tested (as to avoid data inconsistencies) and some small level of data loss or “corruption” is justifiable in wider scheme of increasing numbers of transactions processed.  Some applications even run batch jobs to “patch up” inconsistent data periodically.  And so, as I put my question to you, performance trumps everything?

Lucy in the Sky with Data – Part 1

The objective of this article is to help describe and then position “Databases in the Cloud” as a solution to issues being faced today, or as a method of driving new value that currently isn’t happening today.  I try to avoid specific technological or implementational discussions and focus on the bigger picture.  My background is in Database Management, Enterprise Software Development, SaaS and Web 2.0. application development.

Overview

A good place to start is with some definitions.  These may or may not be considered industry standard as a lot of these concepts are still under debate, however these are the definitions I will use throughout this article.

• Hosted Database Service – An industry standard database server that is made available as a hosted service by a service provider. You connect to a server using a proprietary protocol and control the data and schema contained within a database, however the operational management are is performed by the service provider.
• Database as a Service (DBaaS) – An evolution of the above with a key difference, the interface to the database is using a standard SOA protocol (SOAP, REST). Rather than connecting to the database using a proprietary client library directly over TCP, the application connects to the DBaaS using a standard protocol web services protocol and consumes the methods and properties exposed by the service, which are used to issues commands to access and modify the data contained within.
• Grid Computing – Grids refer to the infrastructure that can scale out on demand, distributes load between nodes, has inbuilt fault tolerance, and high levels of scalability through scale out. Grid nodes can often be easily provisioned without downtime and are commonly constructed from industry standard hardware. Clouds are typically built on Grids.
• Cloud Databases – DBaaS, combined with Grid Computing, combined with utility computing i.e. all physical infrastructure details abstracted, accessed using standard web service protocols. Typically Cloud Database services providers provide an abstracted (you access the address of the cloud, rather than a specific server), highly available service, with an unlimited scalability potential. Internally the cloud is built on a grid with fault tolerance, load balancing and data partitioning capabilities. The utility component allows each user to “pay” for the service based on utilization of the service.
• Data as a Service (DaaS) – A further evolution of the DBaaS with a different focus. DBaaS is focused on making the “repository” of data a service which is accessed by various applications. DaaS is implemented overtop of DBaaS to expose the data itself as a service. This is an important future concept which physically will be implemented in Cloud services.

Clouds vs Hosted RDBMS

For all the major Cloud Database services right now, there are significantly more differences than just the interface.  Most major Cloud Databases have a simple, discreet subset of standard RDBMS functionality.  Common RDBMS functions such as stored procedures, triggers, transactional consistency across tables, DRI, object level permissions are typically not available.  In addition, accessing the data using the standard SQL is not supported.  Instead a simplistic Create, Retrieve, Update and Delete (CRUD) query syntax is provided for accessing individual records and basic RDBMS SQL functions such as joins are typically not available.

In many cases a defined schema is not available instead an individual record or “entity” can take on its own schema, at this point in time most Cloud Databases are not RDBM’s.  They are much more closely aligned with Object databases.

Why Is This?

The focus of current cloud implementations has been on achieving the scalability and performance goals of the cloud, and to do this it has been necessary to deprecate features and functionality to ensure the scalability of the platform.

One of the main issues with providing a full relational implementation in a service model is that in a RDBM’s it is largely the responsibility of the developer/dba/architect to manage the resource impact of various commands and the follow on impact that occurs, such as concurrency, resource bottlenecking, etc.  If not managed properly it is possible for a certain queries on large data sets to impact all queries occurring on a server though high levels of resource contention.  Complex queries doing large sorts, aggregations, multi table joins can require large amounts of memory CPU and I/O to serve.  To manage performance in these scenarios DBAs have the power to index, optimize memory allocations, optimize data placements, profile and tune queries using indexing and so one (note this has nothing to do with the relational SQL model itself, just the practicalities of physically implementing it).

This doesn’t play out well in a model where for all intensive purposes, the infrastructure and physical location and layout of a database is invisible to the developer of the application.  The possibility of causing high levels of impact to other users of a shared platform is very undesirable to the service provider, as is the requirement to have the customer review and make decisions on the physical layout of the data on the physical infrastructure.

Instead the current approach of the Cloud Database services is to move to the “client side” much of the processing overhead of intensive operations such as joins, sorts, aggregations etc and only allow the issuing of discreet and much more predictable (from an impact perspective) row focused CRUD operations reducing the possibility that a single query can cause massive levels of impact to the shared platform.  Because of the scale of the Cloud Databases being offered (TB, PB, billions of rows etc) the impact of unpredictable processing would be a massive problem.

The reduced functionality is a key difference that allows Cloud databases to provide near linear, unrestricted scalability growth in a uniform manner.  How this plays out into the future remains to be seen.  There will be improvements made in this area as vendors find means to address such issues.  For example, it is not only conceivable that you will pay for usage, but you will also pay for the size of your database processing pipeline.  If you issue a query that causes a high level of impact but only have a small pipeline, they your query will take much longer to process than if you had purchased a much larger pipeline option.

Doesn’t this Limit Cloud Databases?

Yes.  Right now you cannot simply decide to unplug an existing application from an onsite RDBMS and plug it back into a cloud database.  Existing RDBMS applications will currently be incompatible with most Cloud Database offerings.  Use of current Cloud Database offerings must have the application code changed to utilize a cloud database.

What Other Issues Limit Cloud Databases?

There are a number of other reasons that use of Cloud Databases is going to be limited currently, and limited for some time to come.  These reasons include:

Latency

The response time between an application and a database server is key for application performance, and directly impacts productivity in a lot of industries.  Current day database applications typically measure response time is in ms, many of applications process hundreds or thousands of application requests a second.  For a database on a LAN near an application latency is less of an issue, but for a Database Cloud hosted remotely, latency is a key problem that will mandate application architecture and limit Cloud usage. 
In such a situation, regardless of how good your ISP is, you are not going to have the same bandwidth available to you as you currently do on a 1GB switched backend server network.  Once you go out to the web your request is passing through firewalls, routers, multiple providers, then to the Cloud Database provide itself and back again.  This will be hundreds if not thousands of times slower than what is possible having your database server sitting next to your application server.

Security

Putting your data out there in a Cloud somewhere obviously has many security concerns that goes with it.  Security concerns around who in the service provider has access to the data, concerns around the robustness of the service providers security model, concerns around the transportation security model.

Availability

The availability of the Cloud will typically be very good, however if the Cloud is external the availability of the network and all the components between you and the Cloud provider must be considered.  You will likely pass through a bunch of ISPs, dozens of routers, firewalls, switches etc.  While your Cloud provider will likely provide you a service level commitment, you may not be getting the same level of commitment from your ISP.

So why use Cloud Databases Then?

If the major draw card for Cloud Databases was simply the ability for organisations to outsource their infrastructure requirements, then you would be quite right in concluding that hosted infrastructure services have been around for many years and have only made a minor impact, mostly in the SME market.  So what is it with Cloud Databases that is making them an area of great interest? 

Clouds for Web 2.0.

Clouds for Web 2.0. applications fit well for a couple of reasons.  Firstly, scale.  Clouds provide the promise or near unlimited scalability, so as a creator of such a service, if your service takes off then your Cloud Database service should be able to cope for your application to grow to hundreds, then millions of users.
Implementing such scalability internally is now much harder than it used to be because of the speed of internet growth, your application can literally go ballistic overnight.  Implementing increased infrastructure in response to customer demand in near real time, is a difficult and costly and worrisome area for most start ups.  We all know what can happen if you get it wrong, such as the recent very public issues that Twitter has been having.

Secondly cost to entry.  To implement a large scale robust “Cloud style” infrastructure in house is going to require some very high levels of expertise and a lot of capital.  For a start up on a shoe string, investing in database infrastructure to support 1 million concurrent users when you currently have 5 concurrent users is very difficult to justify.  Using a Cloud Database service allows you to pay for what you are using and then scale up your service quickly as your business takes off.

Of course a Database Cloud is only one layer in the application architecture so scalability issues surrounding other layers also need to be addressed in your architecture.

Don’t Cloud yourself Into a Corner

My biggest concern around Cloud offerings for Web 2.0. at present is ensuring you don’t cloud yourself into a corner.  What I mean by this is while Cloud offerings may meet your immediate application requirements, try and have some forward thinking about ways in which you will derive value from your data once you have amassed lots of it.  Aggregating data, analyzing data, doing things like data mining (to provide recommendations, up-sell etc) will later on become areas that you will be wanting to explore to provide more smart functionality back to your users.  Make sure the Cloud Database service you go with has the ability to allow you to leverage your data appropriate in the future else you will find yourself running into a brick wall in terms of your value cycle.

Clouds for the Enterprises

Clouds for the Enterprise are interesting as there is no specific reason why a Cloud cannot exist within the walls of the enterprise, a sort of corporate Database Cloud for internal use.  From an enterprise perspective, this is really combining Grid computing with DBaaS to provide a platform which enterprise applications can hook into and be free on any specific scalability concerns. 

External Clouds

External Clouds is what most people are referring to when the discuss Cloud Databases in an enterprise context.  Obviously Cloud Databases right now are not a replacement for business critical databases servers in such an environment.  The latency, security and network availability issues ensure that is not practical.  So why then would a corporate consider a Cloud Database offering?
Many enterprises have requirements to interact with external users and systems through applications and integration processes (edge computing).  Whether it be a web site, web store or b2b integration process, some level of data often needs to stray outside of a enterprise walls.  In these scenarios hooking into a robust cloud service may be preferable to placing corporate assets outside the firewall.

Summary

On reviewing this article I have found the following points that require further thought, investigation and elaboration:

• Cloud Databases for Web 2.0. / web based start ups are an attractive option as they allow for rapid growth and low cost to entry. However what are the barriers if you go down this path in terms of ability to derive value from your data assets.
• The Cloud Database scalability requirements are met by deprecating most core RDBMS functionality, functionality which has been seen as critical in terms of a RDBMS and built up over the last 30 years. So what is the true impact of this?
• Cloud Databases for Enterprise are interesting when you bring the Cloud internal, but have a weak positioning when talking about external Clouds. Most of the talk about Clouds for enterprise refers to external services, so their attraction seems understandably low. Edge computing and b2b use generates little excitement in me, so really I want to investigate this area further to see if there is a stronger potential here.
• The benefit of adding the SOAP/REST interface isn’t really explained in any detail in this article. Yeah it is a generic protocol that allows varied platforms to interact with the Cloud service, but there hasn’t really been an issue with all major application platforms having access to SQL Server, Oracle, DB2 or MySQL servers in the past. So what else is the value that this is providing?

So it is clear there is a need to delve into a lot of these areas in much more detail.  Many of the benefits of this model will become more solid as we start to describe more of the concepts surrounding DaaS, Data as a Service and start to position real solutions in response to real problems being faced today.

follow up: should oracle have bought mysql?

I am not against Open Source at all so I don’t want this to become a debate about that.  But a commenter saying that Open Source business models are well understood is not correct on this scale in the RDBMS market.  In large multi national RDBMS players such as IBM, Oracle, Microsoft we have seen free/Open Source software offered as teasers that lead into purchase software.  We have not seen an Open Source offering as a primary offering.

The economics of what Sun has done is interesting.  It has paid $1 billion for MySQL.  But remember, MySQL’s revenue is largely services* based, not intellectual property based, which means each and every sale they make they have all their standard delivery overheads.  In all service based organisations I have been involved, a 20-30% profit margin is considered normal.  So if everything stayed the same, it could take Sun an estimated 41 years to get their money back based on MySQL’s current revenue.

But this doesn’t take into account reinvestment into R&D.  For MySQL to not only grow, but simply maintain its market share they are going to have to invest heavily into expanding MySQL's capabilities.  So assuming they are making standard returns on their services, this doesn’t leave a very large bucket to pipe back into R&D at the current time.  So when does Sun start getting payback on their $1b?

One would expected then that Sun believe they can increase MySQL revenues significantly.  Very significantly.  How they plan to do this is the unanswered question at the moment.  Obviously the cross sell opportunities will add a lot to the bottom line, but with the numbers we are talking one would hope they had a revelation, if not a revolution, up their sleeve.
 
* I think MySQL does sell some management products for MySQL that are not services based

should oracle have bought mysql?

This is my response to Billy Bosworth's question "should oracle have bought mysql?"

I don’t think Oracle is going to be kicking themselves too hard here.  From memory in October 2005 Oracle announced it had acquired InnoDB (the most popular transaction storage engine for MySQL).  In late January 2006 Marten Mickos confirmed that Oracle had made a bid for MySQL which was not accepted, although didn’t state exactly when this occurred.  And a few weeks later in Feb 2006 Oracle announced it had acquired BerkleyDB, the other popular transactional storage engine for MySQL.

One view could be that Oracle tried to acquire MySQL, and when it failed it picked up the key dependencies of MySQL that MySQL itself didn’t control.  Another view might be that Oracle had a strategy to acquire all the pieces of the MySQL stack and failed to acquire the central piece, MySQL itself.

So for suspected pocket change compared with the $1 billion that Sun paid, Oracle still very much has a significant hand in the MySQL pie.  While InnoDB is GPL, so in theory it can be forked and developed outside of Oracle’s control, Oracle owns the innovation centre for InnoDB so this is unlikely to happen unless Oracle dumps it (which itself is unlikely, more probable Oracle will continue to develop it to maintain it’s position but I wouldn’t expect major new features to appear in InnoDB ahead of Oracle’s own products though).

Ultimately I don’t think Oracle believes in the MySQL business model enough to pay the price they were asking (I think they saw MySQL as a trajectory offering rather than a direct source of strong revenue growth).  Clearly Jonathan Schwartz has different ideas, but with MySQL revenues of only $70-80 million (0.4% of the $18.8 billion RDBMS market) that also remains to be seen.

What also remains to be seen is how MySQL’s business model flies in a Sun, a public company that has to be concerned about things like revenue, targets, profits etc.  If I make one of my products better (fix bugs, easy usability, ease integration) that means I will sell more and increase revenue. How will enterprise view building a dependency on a product whose revenue stream is fully tied to a paid support?  Dismiss the concerns as much as you like; it just seems like common sense that making such a product more robust, more usable, more reliable has to be somewhat counterproductive to the vendor.  I don’t want to start a whole debate around Open Source business models, but there is no one else doing this today in any sort of scale in the RDBMS market (IBM, Oracle and Microsoft’s free offerings are more entry point teasers) so it is another area of wait and see.

Anyway it is all very incestuous.  Sun owes a lot to Oracle, but in their apparent move to gain some independence from Oracle (Schwartz had reportedly stated for a while that they wanted to fill their gap in the database market) they have acquired a product which currently has a dependency on Oracle.  Stay tuned because who can predict how all of this will pan out!