Voice of the DBA

Category: Editorial

  • The Math on Automation

    I wrote a piece on automation and time savings, and of course, Derik Hammer had to point out another post and xkcd cartoon that splashes some reality on automation. I’ve included it below, and certainly there are some good points made in the cartoon. It is incredibly easy to underestimate the amount of time it takes to complete a software project, especially when you include maintenance. Make no mistake about it, scripting little tasks and adding code into SQL Agent jobs is building software.

    The decision to undertake automation shouldn’t be strictly made on the math of time savings. There are a number of other gains to consider. The post linked above notes that the fact that interruptions can be minimized through automation can be very valuable. I know many people discount the cost of disruptions, but they can be high, especially for knowledge work. This reason alone might be worth spending time on automation.

    I feel that building some automated processes is a great way to actually practice skills you might use elsewhere. Automating tasks is practical, and even if the exact method isn’t a technology you regularly engage in, the mental practice of working through a problem and developing a solution is valuable. Just engaging your brain on a problem can be a good use of some time.

    Those people that have followed the ideas in DevOps for years know that one of the main powers of automation is consistency and repeatability. We know that humans are bad at being consistent and reliable, and those are the places we should use computers. Even if the time savings don’t directly add up, I’m sure the chance of you breaking something, forgetting a step, or even neglecting a task are likely work a little bit of automation time in your job.

    You don’t want to get caught up cerating a large side project to automate something, but little scripts to save time are definitely valuable.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8 MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • SQL Server on Linux

    Years ago I wrote an April Fools story about SQL Server running on Linux. For years, this was one of the most popular referrals at SQLServerCentral from Google as many people apparently wanted to get SQL Server on Linux. Well, my joke is now reality. On the official Microsoft blog, there was an announcement of SQL Server running on Linux in preview last week.

    Apparently substantial work has been done in this area if there’s a preview available, with an aim to release a product in mid-2017. That’s somewhat amazing, and I’m very curious about this in two different ways. One is how they technically made this work.  With different threading and schedulers, this is fascinating from a technical perspective.This makes me wonder how much porting work was done, and will continue to be, necessary. Will there be issues keeping the Linux version up to date with the Windows one?

    However I also wonder what the business model is. Are there that many people who want to, or would, run SQL Server that don’t want a Windows OS? I know that the people managing the OS might see SQL Server as just another database application, but I haven’t run into many places that would refuse to install Windows. Maybe this capitalizes on the Azure Data Lake work on Ubuntu? Or the desire to integrate SQL Server more tightly with Hadoop/HDInsight, many installs of which run on Linux? I suspect there are groups more comfortable with Linux and the LAMP stack than Windows, and this gives them the chance to use the incredible SQL Server platform on the OS they are comfortable with.

    This is exciting as a SQL Server professional, giving us more potential opportunities for employment and new challenges for the platform. I expect to see SQL Server continue to grow and prosper as one of the premier relational database platforms in the world. As we move to a more cloud based, hosted model for our software, having our platform be independent of the OS is, I think, a good thing.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.0MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Open Source SQLPS

    I first saw PowerShell in 2007 or 2008 at TechEd. I was both fascinated and excited, finding the idea of using command line tools both nostalgic as well as handy. Certainly there have been a number of file based operations I’ve wanted to do in SQL Server in the past that weren’t easy to accomplish in DOS-style programming and even less easy in T-SQL. VBScript worked, but it was a very cumbersome, error prone method of developing scripts.

    PowerShell (PoSh) seemed elegant, and I was excited to have it come to SQL Server and integrate with SMO. SQLPS was released as a first step, but it was again cumbersome and poorly integrated into SQL Server. I found it to be more of a pain than a help, and abandoned using it. Since then I’ve tended to build my own scripts using techniques from our Powershell Tool Time series to help.

    However plenty of PoSh experts I know like the SQLPS module, but they want it improved. Apart from asking for a few changes in SQL Server 2016, there is a Connect item to open source the module. It’s an interesting idea, and certainly it does appear the Microsoft is unwilling to put many resources into SQLPS. If that’s the case, why not open source the tools? Is there any revenue impact?

    I’d argue that this is one of those areas that starts to exceed the scope of what MS can accomplish when it’s not a priority. Just like the opening of Windows Live Writer, allowing the community, including MS employees, to donate their own time to fixing and expanding the tool could allow this to flourish and grow, perhaps even helping SQL Server adoption.

    I’m certainly not a PoSh expert, but I’m curious. If you use PoSh, would you want a SQLPS module maintained as an Open Source product? Whether you do or not, what do you think about opening up ideas like this for public viewing and pull requests to integrate changes back into the product?

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Building Better Software

    One of the ways in which many software development teams have tried to improve is by examining what has worked in other organizations and projects and experimenting with ideas. Across the decades that we have been using computers, there have been quite a few models, the most well known of which is the CMMI Model from Carnegie Mellon University.

    The CMMI Model contains lots of good ideas and practices, much like Six Sigma, ISO and other frameworks. However we (as a group) often don’t follow many of the ideas. It seems that so many developers (under pressure from managers) work to just complete tasks, without regards to the well known, valuable techniques of measurement, improvement, and more.

    However there isn’t much magic in using any of these frameworks. They all cover similar concepts, which are based on measuring what you do, taking that feedback to alter your process and get better, as well as then working within a structured process that is repeatable. Do more of what works, and do less of what doesn’t. Adjust your way of working regularly.

    The problem for most of us is getting a group of people to actually follow a process over and over. It seems that we continually want, at least as a large group, to cowboy code our way through development cycles, without learning from the past. Of course, I meet plenty of people that use an ALM (or DLM) process to build software, and they all espouse the benefits, but they do note that it takes a long time to adopt a new process throughout an organization. A year of investment isn’t considered uncommon.

    Perhaps that’s the problem? Can management actually make the investment time to build out better processes? The media hype says they want to, with all the DevOps hype. Plenty of companies, including Redgate Software, are selling tools that companies use to help themselves adopt a process. However I wonder how successful organizations are. Is there enough continuity in the technical staff and management to actually make a change? It took Microsoft years to change. Are you moving in that direction? Is there any chance you will?

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8MB) podcast or subscribe to the feed at iTunes and LibSyn.