Voice of the DBA

Category: Editorial

  • Use Tools

    Fortunately building tools for IT is easier than this.

    As someone that works with Information Technology, I usually work on applications designed to make work easier. For example, we have accounting systems that ease the handling of debits and credits, they detect mistakes in data entry, and in general require less people to handle the accounting needs of many firms. Do we have less accountants?

    I suppose we might have less, but it seems that the finance departments, handling AP and AR in many companies is as large as I remember from my younger days. Perhaps the department is smaller than it might otherwise be, but it’s usually not small.

    In IT, we have all kinds of tools available to us that can help with our jobs. What’s more, we can create new tools as needed to do our jobs. Powershell or Perl scripting, Codeplex projects, and more are available to most of us to help us better manage systems. In SQL Server, we even have a built in framework, Policy Based Management, that helps us prevent changes or problematic configurations. If you find a third party tool that can help, you can make a case for its purchase, using the time savings translated to actual costs. One of those tools might really make your job more enjoyable..

    In theory, we ought to be able to manage many more systems per person than we used to. Does that many that we need less people? Perhaps, but it seems we grow systems fast enough that we still need to hire more staff in many environments.

    I so often see people working in IT fail to take advantage of all the tools we have to automate much of their jobs. They often tell me if they automate too much of their jobs, they won’t be needed and may get let go. Personally I think that’s an excuse not to exercise your skills, challenge your mind, and get rid of tedious work There’s no shortage of work to be done in most companies. If that’s true, why not use your tools to get rid of the tedious work and spend your time on something more interesting?

    Steve Jones

    The Voice of the DBA Podcasts

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

  • The TCO of the Cloud

    Cloud computing is growing, and it makes sense for some applications.

    I know that many of you don’t want to put your databases in the cloud. There are definitely concerns for many applications that might have identity, financial, medical, or other data. However there are many other types of applications that might make sense for cloud computing, and I am sure that many of you will encounter pressure to move to the cloud at some point in the future.

    When you do, how do you determine if the cloud makes sense? Amazon has a nice whitepaper for NoSQL databases, which examines a scenario of varying traffic for a system whose usage peaks and then declines. I don’t know how many of us have applications that follow this pattern of traffic, but I think there are plenty of our systems that are over-provisioned and have hardware sitting idle over time. Virtualization helps recover some efficiency from hardware, but the study was interesting to me in showing that the majority of the costs were in administration, redundancy, and support costs (power, space, cooling).

    Whether or not you feel the assumptions made in the whitepaper are valid, there are some interesting ideas here that show where scale can be a huge benefit. Redundancy is very expensive for single systems, but when it is spread out over the large number of systems a cloud provider maintains, it’s a minor cost. The reduction in administration costs can also be a significant savings, especially when you consider how hard it can be for a company to scale up, or down, it’s staff to meet its needs.

    I still prefer the idea of a private cloud inside a company where database services are provided, not database instances. I hope that SQL Server moves in this direction, giving us the chance to choose to manage data and consume a database service, leaving the management of the underlying instances to a specialized group that prefers managing the hardware and platform.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Continuous Releases

    An actual graph of the features complete, but not released.

    One of the interesting things that I find with my iOS app is that they are updated fairly regularly. I have 20-30 apps, and I would guess that 3-4 of them are updated on any given week. Some of those are bug fixes, some of those are enhancements, but they are regularly changing. I don’t update them all every week, but I try not to wait too long between updates.

    Plenty of other software works like this. Windows Update provides fixed to various software on my desktop, I get a list of patches I can download when VideoStudio starts, and SQL Prompt lets me know about updates when I start SSMS. Those are all channels that allow a company to easily deliver patches to customers that improve the software. Usually these are patches, but sometimes there are improvements, like Experimental Features. In SQL Server, we have usually frowned on feature enhancements in patches, but is that what we really want?

    I noticed an interesting metric being tracked when I was in the UK. Development teams were looking at the time between when the completion of a feature (development and testing) and its release. It’s an interesting metric as there are substantial delays, which can be problematic. Users don’t get the chance to test the feature and give feedback. Developers move on to something new and may have trouble going back to enhance or patch the feature later. If there are helpful new features, and turn them on or off, wouldn’t you want to see them as soon as you can?

    Continuous Integration (CI) is a technique to help smooth the process of merging code from multiple developers, and the next step in smoothing the software life cycle is continuous release of software to get your changes in the hands of customers quicker. It’s not suited for everyone, testing needs to be more thorough, and there needs to be a smooth process that allows customers to pick and choose which updates they apply. However this can be a way to get feedback from customers, and even decide on future priorities as customers provide feedback.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Password Handling

    Best Buy Password form
    Bad form design or bad idea?

    I thought this article on Best Buy PC setup was amusing. Here’s a company that’s trying to provide a service. They’re offering to set up most of your new machine for you. To make sure that things work right away for you, they ask you to provide your password, so they can set a login password to your Windows/Mac. However the form has password below email, which might imply they will set up your email as well. That’s something I know many non-technical people might appreciate.

    Consumers probably think this is a good idea. Computer gets set up for them, and they pick a password. Technical people cringe. Password written down, given to stranger, stored by large company. What could go wrong? You can guess, or read the comments in the article.

    As DBAs, I am sure many of us have to deal with SQL authenticated user accounts. The recommendation is for Windows authentication, but there have been exceptions for various reasons at almost every company where I have worked. This Friday, I’m curious how you deal with a similar situation.

    How do you decide on a SQL login password for a user and get it to them?

    This is a process question, asking how you pick a password, and how you send it to the user. I assume most of you check the “user must change password” box, but if not, let us know.

    For systems where a password must be coded, I’d pick a long, hard to remember password, keep it in a safe location with other administrator passwords (something like Password Safe) and either type it in for an application or give it on paper to the developer/admin long enough to type it in before taking the paper back and destroying it. If it’s a user, I’ve often built separate passphrases for each user, customized to something I know about them, and forced them to change their password.

    Password security is hard, and complex, but so many administrators make it worse with constant, easy passwords they give to users. The password you choose sets an example, and “12345” or “asdf” are bad examples.

    Steve Jones

    The Voice of the DBA Podcasts

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