The Myth of the Full-stack DBA

Andy Shora recently published a great article about "The Myth of the Full-stack Developer." From his posts and tweets, I peg Andy as a front-end developer specializing in CSS and Javascript frameworks.

Andy's comment about the 30-point spider diagram really resonated with me.

Where do your web development skills lie?

The term Full-Stack applies to knowing different layers of architecture, of which the database (SQL/NoSQL/SomeSQL) can sit as one of those layers. However, if you were consider yourself a "Full-Stack" SQL Server DBA, you might know the details of some or more of the following components of SQL:

SQL Server

Transact-SQL
Backup/Restore
Replication
Log Shipping
Query Tuning and Indexing
Policies and Resource Governor
High availability
In Memory Querying

SQL Agent

Jobs
Alerts

Reporting Services

Sharepoint Integrated Mode
Native Mode

Integration Services

Importing/Exporting/Transforming Various Data Sources
Connection Types
Toolbox Components
Project /Package Deployment Methods

Analysis Services

MDX/DMX/DAX
Tabular
Multidimensional
Sharepoint

Powershell Scripting
TFS Integration

And of course the various ways to setup, configure, debug, maintain, monitor, license, upgrade and secure above tools along with the associated hardware and software. Perhaps your job description may even include mentoring developers on best practices on interfacing with the layer that is the "database".

By no means an exhaustive list and depending on your environment your role as a DBA could include Active Directory maintenance and Voicemail support.

If you're a Microsoft consultant or a partner of Microsoft, you're probably intimately familiar with the old Microsoft Hamburger and its associated toppings.

(RIP standalone PerformancePoint Server)

If you have expertise in one or more of the grills at the bottom of the stack, (SAP, Oracle, etc) your job just got a bit more important.

For some of those components in the stack, hopefully you're using best-of-breed third party tools from companies like Apex, Idera and Red-Gate to improve your experience. The ecosystem of helper apps is vast and wide. Many feature limitations of products are considered "partner opportunities" by software companies. If you want to be a Full-Stack DBA, you'll want to know what tools keep your stack upright.

If you were to consider yourself an expert on the internals of SQL, you might know about all of the components of this diagram, and take great pleasure in using tools like Internals Viewer to see how SQL arranges its storage and understanding the details of how GAM, SGAM & PFS Pages work.

Or you may have had a "crash" course on above internals while troubleshooting why a DBCC CheckDB job failed and your customers can't access their data. It's best to be proactive about these things, start studying the diagram!

The ScaryDBA's recent post about The Curse Of Relational Databases also comments about The Stack of Information Technology in general, and how deep, wide, and unfathomable it is. The comments provide insight into the mindset of the community, and one comment mentions the idea of "Technical Debt". A topic perhaps worth exploring into detail about in a future post, since this one is getting a tad rambling and epic.

Yesterday I attended a Toronto Hadoop User Group Meetup, with a discussion from the co-author of a book on YARN. The topic was a deep-dive into the internals and features of the resource scheduler and application manager that is YARN. Fascinating stuff (I'm not kidding!) that shows how much effort goes into the foundation of a scalable distributed data solution.

Speaking of deep, wide, and unfathomable....

The Big Data Developer Toolkit

http://blog.andreamostosi.name/big-data/

The Apache Open-Source Developer Toolkit

https://projects.apache.org/indexes/quick.html

Hopefully your DBA stack expertise includes some Linux knowledge.