Voice of the DBA

Category: Editorial

  • The Great and Powerful Internet of Things

    Will we have the IoUT (Internet of Useful Things? As some have said, the IoS (Internet of Sh**e) is really what we have because of the poorly built, poorly secured hardware and software devices. It seems that almost every month I see new devices introduced in the consumer space, most of which aren’t well designed for widespread use, and certainly aren’t very durable. There are, of course, exceptions, including a few I’d like, but for the most part, the rush to market means that many of the IoT devices sold aren’t much better than most of the home built Kickstarter projects. That’s not to say Kickstarter (or Indiegogo or any other site) doesn’t produce good products, just that some aren’t.

    We’ve got an infographic from Website Guide today that you can examine. It’s an interesting item, which is why I published it. There are a lot of great possible applications for IoT style devices. Plenty of businesses and industries are seeing the benefits of using sensors and devices that are (semi-) smart and connected to a network. Using well written applications, companies can come up with new ways of gathering and using information. When these systems are well designed, this can result in lower costs, higher sales (or usage), happier customers, or all three.

    As you scroll down the infographic, you’ll see the dark side of IoT, which is getting more press all the time. Security is the number one concern, as far, far too many devices don’t include the necessary security to protect either the device or the end user. I did watch an IoT demo at Live!360 last year using the Azure IoT hub, and was glad there was some authentication and ability to shut down devices that might be compromised or misbehaving, but far too many IoT systems aren’t well secured.

    That’s disconcerting for me as a database professional. I expect that more and more companies will use IoT in some way. I’d even like to find time for some IoT sensors around the ranch, tracking horses and ensuring they’re all walking around every day. The thing that concerns me is what happens when someone finds ways to hijack or hack a device? Even sensors could be hijacked. What if you’re processing temperature information in dynamic SQL and someone decides to heat and cool the sensor to create certain values? Are you sure your database isn’t vulnerable?

    These concerns leave out the potential for the misuse of any data that’s collected about users, especially if users aren’t aware of what’s being collected and its use. With so many ways of collecting data now, I’m not even sure that anyone has a good handle on all the data collected about them, not to mention how it’s being stored, secured, and used.

    I think there’s incredible potential for some great IoT applications and data in the future. All the forecasts and spending seem to point towards the next 5-10 years being a period where there will be an explosion of the number of types devices built and deployed. Those devices will produce a tremendous amount of data for us to manage in databases. We will have big challenges in storing, indexing, managing streams, and certainly, the pruning of old data.

    Steve Jones

    The Voice of the DBA Podcast

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

  • A Wide Variation in Skill

    I was helping someone recently clear up some confusion about the encryption structure of their TDE databases. This individual wasn’t sure about how the various keys were used, which ones needed to be backed up, and which keys needed to be restored. As this was an online discussion, anyone could read the posts and add their own thoughts. There was a point where one person chimed in that the process was really easy and anyone should be able to complete it.

    I do think that working with TDE is easy, but I also think that its easy for me because I have experience and practice with the technology. There are nuances to undestanding how the piece fit together and what needs to happen in order to ensure your system operates smoothly during both deployment and in disaster recovery situations. Since mistakes can result in lost data, I understand why people might feel intimidated or nervous, but once they practice a few skills and gain knowledge, I find they get the confidence to proceed.

    Their fear is often because of ignorance, which is understandable. All of us have things to learn, especially in technology where the rate of change is quite high. Before we learn something, or even while we’re trying to understand concepts, various tasks might seem quite difficult, or even complex. These might be simple tasks, such as restoring a certificate or sending a set of objects through a Powershell pipeline or writing a unit test.

    Just because you can do something doesn’t mean everyone can. Just because one person finds a task easy doesn’t mean others won’t find it complex. The knowledge that each of us gathers over time isn’t consistent or easily mapped. We all learn different skills at different times, in varying orders and to fluctuating depths. One of the very frustrating things about technology is that there isn’t a defined path for a particular technology, or even job. Someone that begins working with SQL Server might learn T-SQL first, or backups, and not get to the user/role/GRANT security model for some time. Even then someone might easily add logins and users to roles, granting permissions, but being unaware of the difference between REVOKE and DENY, or be confused by the WITH GRANT option.

    I am not excusing the inability of someone to be competent at their job, but I do think that ignorance deserves some understanding and tolerance. While you might be annoyed that someone doesn’t know how to take a COPY_ONLY backup, I would hope you would treat them as a colleague that needs to learn a new skill and not chastise them if this isn’t something they’ve every dealth with before. If they can’t learn this skill and make mistakes over and over, then that’s a different situation and perhaps they aren’t competent. We should understand ignorance once or twice, but after that the person might need to find a new job.

    I see plenty of people that are constantly working to improve their skills and get better at their jobs. I also see plenty of people content to continue their career with the same level of knowledge they’ve had for a long time, unable or unwilling to change and produce better code or faster systems. I also see plenty of skilled individuals treat both groups of people with the same level of scorn, contempt, or shame. I saw a comment posted recently about how Linux supporters will often mock people using Windows and then deride the same people for asking questions when they switch to Linux. I would hope that our SQL community would treat others better than that.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The New DBA is a Developer

    I was reading a short piece from Mike Fal recently and it struck a chord with me. I started working with computers as a developer, really a hack programmer as a kid. Friends and I would build small games or hack existing ones to change things. Eventually I was paid to write code, and moved into data work because the pay was better. That was 25 years ago, and I haven’t regretted the change since. In fact, I’ve enjoyed working with data.

    Even as I managed data, I always ended up writing some code. Not code, code, like an application that others could use to accomplish a task (though I have often done a touch of that), but rather code to help me as a DBA. I had code to check servers and record values. I had code to move backup files around and generate restore scripts. I had code that would build reports for other DBAs. Some of this code are queries, some are more complex scripts in PoSH (or older VBScript), some could be C# or some other language, but it’s all code. Fundamentally, the code isn’t much different from the code that application developers write and deploy to clients, web servers, or mobile devices.

    There always seemed to be a separation between a DBA that could script something and a DBA limited to simple DML queries. The latter was much less efficient, less productive, less capable of managing a larger environment. As I look to the future, I’d say that that DBA or sysadmin that can’t write some code, that is mystified by the concepts of Puppet, Chef, or even unattended SQL installs, is less likely to find good paying, enjoyable, desirable employment. There will be exceptions and less capable people will find work, but given a choice, I think businesses will prefer to get the coding DBA.

    Mike brings up great points in his piece, and despite my history as a developer, I’ve build bad habits over the years. I used to carry around a CD, then a flash drive with helpful DBA scripts on it. I didn’t always have a good test process. Part of this was the lack of good modern tools, part was laziness, but just like Mike, I’ve started to think of anything I do as an effective developer would. I make sure things get done, and I don’t try for 100% solutions. I try to get something working, find the problems and fix them, adjusting as I learn and the system changes. I try to build unit tests and ensure that as I change code, I’m not introducing silly bugs because I’m focusing on today’s issue while neglecting the requirements I had to meet last week.

    Above all, I use version control. That should be a no-brainer for a DBA. We preach backups and restores all the time. Why should our code be any different? These days I’ve adopted git and I use it extensively. Whether on Github or VisualStudio.com, I’m ensure I’ve got my code backed up, and practice restoring regularly on other machines. I create repos as soon as I create a folder to work in, and commit regularly. I don’t revert often, but when I do, it’s nice to have that backup in my VCS.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The vNext Bleeding Edge

    Microsoft has had early access programs for years. I worked at a few companies that were a part of the TAP (Technology Adoption Program) program, and we would get access to code early in exchange for providing feedback and working closely with Microsoft engineers. This was interesting, as well as good and bad. We could move early to implement new features, but we also had the struggles of dealing with code that wasn’t always working as expected.

    Microsoft has stared a new program, the SQL Server Early Adoption Program (SQL EAP) to allow companies interested in moving to SQL Server v.Next as soon as possible. I suspect lots of ISVs that might want to build products for SQL Server on Linux might get involved, but there will also be some large corporations that want to influence the platform and get certain features changed or prioritized. The benefits note that participants can come to the SQL CAT team lab to test things, work with product managers, and get separate support if they go into production. For companies that might feel the next version provides some new benefits,

    Microsoft gets all sorts of feedback, but working with a small group of product managers or engineers is a good way to get your voice heard above others. I know that MVPs get the chance to exert similar influence, and at times this can be valuable. However, one has to keep in mind that this is the chance to voice opinions and thoughts, not votes. Microsoft isn’t necessarily going to implement something you want just because you convinced some engineers it’s a good idea.

    Getting into the program does mean that your are bound by an NDA, and that you may have a separate EULA for production workloads. However, if your company likes being on the bleeding edge, and wants the chance to upgrade early, perhaps you should consider applying. I would say that participation in the TAP program was a beneficial experience for my employers. Perhaps the SQL EAP will be for you as well.

    Steve Jones