Voice of the DBA

Category: Editorial

  • The Control Poll

    Source Control provides lots of benefits.
    Source Control provides lots of benefits.

    I was reading about version control systems (VCS) recently, brushing up on some skills, and saw this quote in a thread:

    “There is no excuse for not using version control, even for a small project developed by single developer. Setting up local version control is beyond trivial, benefits huge. Any developer not knowing that cannot be considered good nor experienced.”

    That’s quite a pronouncement, and one that I believe is very true. No matter what type of development you engage in, I’d expect that you’d understand the benefits of using version control, and the dangers of not using it. It’s just like never backing up your system. I’d think that any developer that cares about their craft and is a professional has used version control. The really good ones will insist upon it.

    However I know that the decision to use a VCS is not always made by a developer. The company building the software might feel differently, and while I’ve always asked for a VCS, I have ended up with a series of folders on a share, named for dates, each containing a zip file of all our code at the end of that day. It was the bare minimum of version control I could live with, and fortunately we got by with just two people coordinating work. Any more than that and I’d insist on some type of VCS.

    This week, I wanted to ask how many of you voluntarily or involuntarily might be forced to do something similar.

    How many of you skip source control for certain apps?

    Even if you have source control for those large, multi-person teams, are there apps that you avoid putting into a VCS? What about your database code? I think it’s important that you keep all your code, whether for the front end application or database objects, in some type of Version Control system. If your boss won’t buy one, then check out Git or Subversion, both of which are open source and free.

    Let us know this week how you feel about source control and whether or not you decide the effort isn’t worthwhile for your projects.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Honeywords in SQL Server

    honeypotAs we become more and more security conscious, it becomes more important not only to configure systems for better security, but also to add more monitoring and auditing to detect when problems occur. We know that at some point someone will attempt to hack our systems. Many of us have auditing set up to detect failed logins, but is that good enough?

    If a hacker manages to gain access to your password hashes, and it’s not a stretch these days to think that they might, wouldn’t you like to know if they manage to find the plain text that corresponds to the hash? There’s an idea that systems could be written to store multiple passwords for user accounts, but only one of which is valid. A separate system detects attempts to log in with the false passwords and alerts administrators to a hacking attempt.

    This is an interesting idea, and while it won’t solve all our problems, it will solve some. If a brute force attack occurs on an account, and multiple passwords are being tried, all of which are known to be false (the honeyword passwords), administrators can be notified, and warnings passed on to users. It doesn’t help if the hacker chooses the correct password to enter first, but with enough honeywords, you reduce the chances that they will.

    I don’t know that I’d like to see this for SQL Server, but I certainly would like to see additional security features. Two factor authentication would be nice, perhaps even some sort of  approval process enabled that required multiple approvals for some changes. The latter would help us prevent the cowboy DBA from making changes without anyone else being aware of them.

    Detection of breaches, using something like honeywords, provide another layer of security. They don’t prevent hacks, but they can help us deal with them.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Challenger

    Are any of the other database challengers really competitors to SQL Server?
    Are any of the other database challengers really competitors to SQL Server?

    There’s a lot of competition among database platform vendors. Once a platform is chosen, companies rarely change, and with good reason. The cost of the people building your application accounts for most of the resources you expend on a database system. Re-training, or replacing, is often cost-prohibitive. That hasn’t stopped many companies from looking to less expensive alternatives to SQL Server, like MySQL, but I’m not sure the license savings offset all the other costs, including potential performance declines from mis-configured systems.

    SQL Server has had a few competitors over the years that tried to provide compatibility and enable easy or seemless migration from SQL Server to a new database engine, but none of them seem to have been very popular.

    NuoDB is the latest, providing a NewSQL, distributed cloud database that has many of the features that developers look for, but is built to integrate easily with .NET technologies, including Visual Studio, has LINQ and Entity Framwork compatibility, and runs on the Azure and AWS platforms. The company hopes it will replace SQL Server as the preferred database in the Azure IaaS cloud.

    I don’t know that many companies want to migrate their applications to a new platform, but I do know that there might be situations and problem domains where platforms other than SQL Server make sense. If the compatibility is close enough to limit the amount of code that has to change, it’s worth looking at. The problem for this challenger, and many others, is that SQL Server has grown to include many other features, like SSIS, that companies find compelling.

    Ultimately I think it’s easier to stick to as few platforms as possible to allow your staff to build expertise in optimizing their code and configurations for a platform. Developers and administrators don’t often become experts, but I’m not sure the situation is any better if you give them an additional platform to work with.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Platform Problem

    A fantastic platform. If I had a choice of where to run it.
    A fantastic platform. If I had a choice of where to run it.

    I really like the idea of Azure providing a Platform-as-a-Service (PaaS) for applications to be built on. As I’ve evolved in my career, I’ve learned I prefer not to manage individual machines or deal with the complexities of configuring anything outside of SSMS for SQL Server. Working with Hyper-V recently has cemented the idea that I don’t become more productive by dealing with the complexity of the Windows host.

    However I can’t see many customers migrating the majority of their applications to the PaaS Azure service for one reason: there’s no competition.

    Moving to Azure means placing a big bet that Microsoft will continue to offer the same or more features, more powerful machines, and stability at a reasonable price. Moving to Azure also assumes that you are comfortable working with only Microsoft for the foreseeable future, using their data centers, staff, and products. Any code you write will be specific to Azure.

    If you were to use the IaaS services from another vendor, like AWS and their virtual machines, a migration might still require some code changes. However, I’m sure if I contracted for virtual machines from Rackspace or some other provider, I could easily redeploy my application elsewhere. Well, perhaps not easily, but certainly easier than if all my code depended on a platform I can’t run inside my own data center. A platform nobody outside of Microsoft can run.

    My view is that Azure is a great platform, and one that could explode in usage. If we have choice.

    Microsoft should sell us the code to run inside our own data centers, or at least license it for a number of large providers that might want to offer Azure services. Ultimately the success of the platform depends on people choosing Microsoft because it’s the best choice, not because it’s the only one.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.