DBaaS Explained, or Miracles in Minutes

Bill Cole – Competitive Sales Specialist,Information Management, IBM

Don’t you love installing databases?  I man the whole stack from the database software through the tools and applications.  Lots of real innovation there, eh?  How many times have you done this sort of thing?  My friend Don was sent to install some very complex software for a client.  The scope was one (count ‘em, one) environment.  So Don calls me the first day he’s there and says the project wants – and this is absolutely true – seventeen copies of the environment.  As an MIS guy, he was offended.  What in the world did they need with so many copies of the environment?  Turns out that every developer wanted his/her own copy.  Given that the install process for any single environment was two weeks and Don had three weeks, all those copies weren’t happening.  Don politely explained the situation, including the fact that the disk space available would barely accommodate a single installation.  Disappointment and relief.  Guess who experienced which emotion.

I’ve written on this topic before in relationship to patterns.  This time I’d like to talk about an old or new concept depending on who you ask: Database as a Service.  Frankly, the naming is unfortunate since the concept is about providing a complete environment for an application, not just the database.  Being a DBA, the database is the most important part, of course.  LOL.

During my tenure as a data center director, I thought of my infrastructure team as providing a service not only to the IT department but to the rest of the company as well.  The real trick there was getting my team – and the CIO – to understand that.  We’re IT after all.  Miracles are our stock in trade.  It’s what we did every day.  The application folks came to rely on our miracles, too.

As we built the data center – I had the luxury of starting from scratch – we agreed on the number of environments and their specific uses, etc..  This lasted for almost two weeks once we actually got started.  From the target of the three we had agreed to, my team was challenged to create and manage seven, each with their own rules, users, priorities, sources and schedules.  The application team didn’t think we could do it.  I created the processes and procedures.  And I participated in them, too.  Shared misery.  LOL.  The apps folks would challenge us to do something in a hurry and I’d quote a short turn-around and then beat it by 50% most of the time.  It both annoyed and amazed.

This was our own DBaaS but we should first define the term.  DBaaS is initiated by a user asking for an application environment to be provisioned.  Note it’s the full application environment including the database, application code, any web- or form-based pieces, plus the ancillary tools.  Crucially, the request includes three other critical pieces of information.  First is the sizing.  Is this a small, medium, large or massive environment?  We need to understand how the environment will be used.  Is this a sandbox or training or development or Production implementation?  Some other bits of information need to be collected as well.  Which department is getting billed for this?  After all, IT didn’t just collective decide to create this environment.  Perhaps we should add something about managing this collection.  Are we applying patches or updates?  What’s the life-span?  A few days or weeks or years?  SLA?  It’s not simply gimme a copy of Prod.  We need a complete description.

Note the assumptions we make in DBaaS.  First, we assume there’s a “golden” or benchmark source from which to create the environment.  If not, it’s a whole new installation and the price just went up.  Second, that we have server resources available, probably virtualized servers, too!  And that provisioning this new environment won’t step on any existing environments.  Third, that there’s disk space available.  Again, this is space that won’t step on performance of any other environment.  I add this caveat because I once had a CIO call me out of the blue and ask me about the rules for putting data on his expensive SAN.  It’s seems all those CYA documents and spreadsheets were killing the performance of critical production database.  I know of a clearly enunciated set of rules, please share them with me.  Finally, we need to ensure network connectivity and bandwidth.  Don’t forget this critical piece of the pie.  We can’t assume that there’s room in the pipe for an added load.

The pledge we in IT make is both timescale and accuracy.  We give the requestor a time for completion that may be tomorrow or, at worst, the following day.  I know that sounds wildly aggressive for some types of provisioning but we have to build our sources and processes so we can install them quickly on a variety of operating environments.

All of the above is where DB2, SoftLayer and PureSystems shine brightly.  DB2 can be provisioned quickly from copies in a number of ways from cold or warm backups.  PureSystems implements all the advantages of DB2 plus PureApps includes DBaaS tools.  And SoftLayer is really the gold standard for DBaaS.  Just take a look.

Finally, my wife works for a large application development organization masquerading as a bank.  She gets very frustrated with environment management and provisioning.  Fortunately, I understand both sides of that story so I sit and listen patiently while she tells me what the bloody minded idiots who manage their various dev/test/prod environments have done to make her life difficult today.  The thing that gets her maddest is that no one seems to know how to provision any new environments.  With dozens of infrastructure staff, they can’t because no one has really haven’t thought through the process.  So the dev teams just sit around waiting.  Losing precious time.  It’s really not a full service bank, I guess.  Don’t expect a miracle.

Follow Bill Cole on Twitter : @billcole_ibm