DevOps – What to do about this Data Stuff?

Self-Aware Disclaimer

As it turns out, this blog ended up sounding like a bit of a commercial for Datavail, but please read on. It’s not my intent to blatantly cheerleader for my firm, BUT, at the recent DevOps Summit in Santa Clara that I attended with our head of Solution architecture, Scott Frock, we noted that in all the variety of viewpoints about DevOps (Continuous Development) there was a “giant sucking sound” whenever we (well Scott actually asked the questions) asked about the database team’s role in it. The typical answer from the 160+ IQ crowd was, “Yeah somebody needs to deal with that.” That lead to my recognition that our fractional DBA managed service was a perfect fit for those trailblazers adopting DevOps. But more on that later.

In a previous blog I mentioned the 30 year trend to abstract all things infrastructure (including information infrastructure, a.k.a. the database) from modern developers. This undeniable reality has enabled awesome feature function development speed, but has also insulated Dev teams, and led to a lack of pragmatic understanding about how and where Apps are deployed, and more to the point, performance optimized. So, it’s not at all surprising that at a conference dominated by folks to whom the web has always been a reality, that “data stuff” was a bit of a black box.

DevOps – The Challenge for Application Project Teams with Data

The lack of discussion about data at the DevOps Summit is nothing surprising to us at Datavail, nor most DBAs in attendance. DBAs since the dawn of the Relational Database Management System (RDBMS) have served as the hated “data cops” for most organizations. While Developers and Infrastructure managers (I speak as a former network engineer) love to hate the DBA function, organizations have come to rely on the fact that DBAs deal with all the nasty details around data structure, cross functional access, performance tuning, security, replication, availability, RPO/RTO, and many other very necessary but incredibly un-sexy aspects of data management. Cloud based infrastructure has only exacerbated this dependency as dynamic compute and storage capacity can gobble up large chunks of infrastructure at speeds never before imagined. So, how is this connected to DevOps?

DevOps is inherently an “agile-ish” concept, and requires the key parties to be focused together in concentrated efforts for relatively short periods of time. Continuity of knowledge is a challenge anytime a team is not “dedicated,” and agile intensifies that. While a development team may stay together for extended periods, DBAs are typically called in only when needed, effectively, Just in Time (JIT.) Typically that is during design phases, integration points, and as go-live looms. Unless a project is very large, it’s rare for a DBA to be dedicated solely to a development project. This is made worse when you consider many projects are comprised of multiple database technologies, demanding skills that are rarely able to be fulfilled buy a single human.

So here’s the challenge: Dedicated teams of developers require JIT RDBMS expertise, across a variety of data technologies, and the DBA needs to be context aware and “up to speed” on the current state of the code. Hard to fulfill? You bet.

DevOps and DBA Managed Service

To be what I would call a “Tier 3” DBA today and be application ignorant, is to be unemployed. Top notch DBAs all have a capacity for application tuning, and many DBAs came up as developers. So there is an inherent ability to work with Dev teams. But how do you tap into that expertise?

There are 4 basic challenges that come to mind:

Availability – DBAs tend to be highly leveraged in any enterprise, and interrupt driven. Expecting JIT or short notice scrum like availability is unrealistic, short of a dedicated person.

Technical skillset (Oracle, MS-SQL, MySQL, etc.) – Many projects involve multiple databases and/or add-on products such as Hyperion, which require specific skills.

Continuity of knowledge with App team – No agile team can withstand a key contributor who has to be “brought up to speed” every time they are needed. Besides, it’s highly unlikely that person will be contributing at the level required.

Cost – Cost for a full time, onshore DBAs is typically $70-100/hour, factor in non-working and administrative time, and that cost can easily get to $150+/actual DBA hour.

Achieving this internally in any enterprise, even large ones, is difficult operationally, and dedicated DBA cost are typically prohibitive. All of these factors argue for a service model that combines diverse skill sets, short notice availability, and intimacy with the given project team.

Answer: A true managed service, with a few requirements:

1. High-level technical skill sets – low-level operational resources are probably not applicable
2. Thorough “on-boarding” to get the DBA intimate with the project and application team
3. Continuous involvement to assure continuity of knowledge
4. Short term access to skills and “burst-ability” for intense periods of activity

All of the characteristics described, with slight modifications, are precisely what Datavail’s delivery model was built to solve. I invite you to go to www.datavail.com where we have a complete description of our delivery model and other content specific to DevOps.

Fractional cost, highly skilled, 24×7 availability, sophisticated knowledgebase, rapid knowledge transfer capability, focused on YOUR project – are all characteristics we built Datavail to embody.

Any organization looking to adopt DevOps principles, needing to solve for, or save cost on the DBA function will benefit from a consultation with Datavail.

And so ends the commercial bit.