Voice of the DBA

Category: Editorial

  • Avoiding Development Taxes

    When I first worked in an environment where multiple developers needed to release software, I found too many rules and constraints for smooth development. The process was developed by one person, or for one application, and somehow expanded to encompass all work being done in the organization. It was if we weren’t trying to think about our creative work as developers and DBAs, and instead viewed our systems composed of widgets built in a factory, each one a copy of the others, perhaps just a bit bigger or smaller. We used the same set of rules for the mission critical finance program as we did for the department vacation scheduling application.

    While working inside an overreaching command-and-control mentality, the idea of moving faster or releasing software more often was seen as really dangerous. Two decades of Agile methodologies, and the rise of DevOps have started to change this for many companies. Each year the State of DevOps report seems to show more and more organizations finding ways to build better software, often by having their operations people embrace the concepts and processes used by software developers as a way of building and managing their environments.

    Databases still lag behind, and as Donovan Brown says in this piece, if you’re not automating the back-end work of code deployments to the database, you’re still “faking” some of your DevOps process. Databases must maintain the state of data, even as transactions take place around code changes. Ensuring that we properly handle those data changes is a challenge. However, by treating the database changes as similarly as possible to application changes, we can minimize risk and learn database development techniques that help us push forward without being reckless.

    Tools have gotten better for database development. Microsoft has some tools for SQL Server, and various other vendors such as Redgate have others. Good tools are essential, but each new one adds some complexity to the environment. That’s one reason why having a minimal number of tools and platforms reduces the friction of getting things done. I see this as a big reason SQL Server on Linux might take off. Plenty of companies don’t want Windows in their infrastructure when most of their systems are on Linux. Not that Windows is hard, but consistency makes everything easier for a staff.

    This is the same reason why I’d say that it’s worth sticking with a database platform or two and not experimenting with each new type of system that comes out. If your staff knows SQL Server, then adding in MongoDB or Cassandra means there’s a learning curve, or a “tax” as the piece notes, to getting things done. This same tax gets paid with each new vendor, platform, language, or technology you take on.

    Database work is hard, and once your staff gets good at building and deploying changes, you want to take advantage of their knowledge. For companies that have solid development and deployment practices, stick with the things that work well. However, if you have staff that turns over regularly and don’t have a mature process, you can reduce the “tax” you pay for database development. There are companies that have paid some of that integration tax, that learning effort, and they’ve got tooling to help you build code better and faster. Just as I wouldn’t want to code my own build server, I don’t want to code my own database deployment tools. I could, but I’d rather spend my time solving problems and use the tooling that someone else has built to make my job easier, and provide a consistent coding experience for my developers.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Data Bots

    One of the challenges for many databases is getting the information out to our users. Early on many of us had to write queries in a customized fashion for our users. Eventually, reporting systems, such as Reporting Services and Crystal Reports, have been used extensively in many organizations to ease the burden or getting information to users, sometimes even allowing self-service where users write reports. Those are inefficient systems, where a lot of man-hours are spent to create something for users.

    Certainly some efforts are made to allow users to query data in an easier fashion. English Query in SQL Server didn’t work well, but the version in Power BI seems to do some things well. Perhaps it’s because a user can see some of the data and the domain of data being queried is inherently limited. I expect this to improve as services such as Alexa, Siri, Cortana, and more become embedded into more applications.

    The bots are coming. I used to wonder, but the more I see the advances made in machine learning and related technologies, the more I think that we will continue to see bots used as a way to access our data. There is plenty of hype, but certainly the technologies are being used more and more, and increasingly sophisticated ways. Plenty of businesses are experimenting with them, though it seems in many cases the technology is in an early stage.

    I haven’t been sure where bots are useful, but I see them more and more in places like Slack where a workflow can be kicked off with a chat operation. This is somewhere between running a script with parameters and using a semi-intelligent agent, but certainly the ease of a bot in places like Slack is very interesting. Operations can be easily conducted, with logging and auditing, and feedback, in a way that a CLI doesn’t quite work as smoothly.

    Perhaps it’s because the domain of actions is more limited, I think that ChatOps works better than general purpose bots. I expect that that will change as we find ways to both limit the scope of interactions, perhaps by passing more information along to the bot. I’m certain the context technology for bots will improve, as well the interaction design. In some ways it’s exciting to think about bots being more focused and responsive than today’s customer service representatives. The one thing that I do worry about is the ability to get an empathetic response from a human. A person is more likely to go the extra mile or do a favor than a bot.

    Steve Jones

  • How Long Before You Upgrade?

    This editorial was originally published on Apr 11, 2014. It is being re-published as Steve is out of town, with a few minor changes to dates and values.

    It’s 2017. SQL Server 2000 is 17 years old, but there are still quite of you managing instances. SQL Server 2005 is 12 years old, and I’m sure more of you still deal with that version. I know because I work for a software vendor and I’m constantly asked if our software will run against those two versions of SQL Server. Most of our software is no longer supported on those versions, as they’re too far out of date.

    For many of you, however, if you’re managing a SQL Server 2000 instance, it might only be 10 or 12 years old. Your company might still have been installing SQL Server 2000 in the year 2005. The same is true for SQL Server 2005. I wouldn’t be surprised to find companies still installing 2005 instances in 2008 or even 2009.

    Companies don’t care much about versions. They tend to mostly care about databases getting the job done, and sometimes, support. Many organizations don’t see value in upgrading too often because of the overhead. I suspect many managers would prefer to get many years usage out of a platform before they change in order to minimize work that doesn’t add value to their business.

    The question this week asks you about the longevity of your database instances. Think about the average instance, or even the majority of your applications and how long they will remain on a particular version.

    How many years will you run a platform before you upgrade it?

    Years ago I heard someone at a large Fortune 100 company say their stated policy was to get 10 years of service out of a database server. At the time I thought that was a long time, but the more I think about it, the more I think that might be a minimum amount of time I’d want from a platform.

    Let us know this week what you experience, and perhaps what you’d prefer.

    Steve Jones

  • Should We Move to Azure?

    This editorial was originally published on May 23, 2014. It is being re-published as Steve is out of the office, with a few minor editorial changes.

    Update: We made a number of changes last year, upgraded the forums, and have continued to implement bug fixes. We are still considering this idea.

    At SQLServerCentral we have been debating some architectural changes to the site. We’d like to improve the way a few of our features work, add new ones, and replace a few items that are buggy and hard to maintain. The site has worked well over the years, but we’ve made relatively few improvements, mainly due to the fact that like many companies, this website isn’t our business, and work has a lower priority than some other areas in the company.

    Recently I had a suggestion presented to me and I wasn’t sure how I felt. There were certainly pros and cons to both taking advantage of the opportunity as well as passing it up. While we are still talking about the process, I wanted to ask the community what they might think this week.

    Should we move SQLServerCentral to Azure?

    I really like the idea of PaaS. There are issues, and certainly I think Microsoft could do a better job of creating competition as well as securing and even deploying their platform. However I think the idea of just consuming services as opposed to installing and managing pieces of software, is a great direction in which to move. SQLServerCentral would seem to be a perfect type of application that fits in the cloud.

    We run a generic ASP.NET site, using fairly common and simple database features in SQL Server. We don’t store or manage much in the way of PII, financial, or medical data outside of email addresses, and we don’t have the need to scale to high levels, either in data storage or computational resources. The one problematic area is our email requirements. I’m not sure what the cost is to send emails from Azure, but we send millions per week, and CAN-SPAM requirements can be tricky to meet in the cloud.

    However I’m just wondering what the community thinks. If we successfully moved to the cloud, and disclosed details about the process, would that give you more confidence in the cloud? Would it be interesting? Or is SQLServerCentral just a service and you don’t care how it works, as long as it does. Let us know this week.

    Steve Jones