Voice of the DBA

Category: Editorial

  • We Manage Algorithms

    “Every business is an algorithmic business.”

    That was a phrase that Microsoft’s Joseph Sirosh used in a keynote at SQL Nexus, talking about the future of software and data. Rather than managing data, many of us will move to manage algorithms, which will determine how data is interpreted, used, processed, and potentially returned to users as information. There are starting to be too many sources of data, too much data itself, being generated at too quick a rate, to the point where algorithms become more important than the actual data in examining, grading, interpreting, filtering, and more.

    This is exciting on one hand, with new opportunities for those that can develop, choose, write, tune, or enhance algorithms. I can easily see greater influence from both developers and DBAs as we work to better manage the floods of data. Especially with 50 billion sensors, IoT devices, and more that are predicted to be online in the 5 years. That’s potentially a tremendous amount of data being generated.

    On the other hand, this is a bit scary as separating good data from bad in the ocean of bits, and choosing helpful rather than hurtful algorithms might create lots of stress, and perhaps even fewer opportunities if few algortihms are reused. This also means we will need algorithms that can help us determine if data is actually good enough to use. After all, in the deluge, there will be bad data, that potentially needs to be excluded from queries. Will software developers become more important than DBAs as we end up with more unstructured data stores, data lakes, or other constructs that might require less administration?

    I’m not sure how things will change, but it will be an interesting world the next few years as we work with larger and larger, more diverse sets of data in our organizations.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Penalty for a Data Breach

    Many of us that work with data are somewhat insulated from the effects of a data breach. Each of us is responsible for writing software, managing the database platform, perhaps even in charge of configuring security. However, in the event of an attack or loss of data, many of us would likely be responsible for the technical aspects of analyzing the weakness or cause of the incident, determining what data might be lost, or perhaps helping to change systems to prevent future incidents.

    Would many of us deal with the penalties or financial liabilities of data loss? Perhaps indirectly, but not much. However our employers (or more likely, their insurance companies) will deal with penalties. Right now there isn’t a lot of liability for companies that lose data. Minor penalties and credit monitoring, but many people are getting upset, which might result in changes.

    What does a company owe you if your information is lost? It’s debatable, and this is likely to become a bigger issue over time as more and more people are affected by this issue. I expect that penalties will increase over time, this will also mean that the requirements and work each of us as data professionals need to do will grow.

    While encryption and other measures can help, they don’t completely protect data. Good security comes about from a number of layers, each of which is designed to thwart, or limit the success of, certain attacks. Those of us that work with data, whether in development or administrative roles, need to educate ourselves and continue to improve our ability to implement secure applications.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Paying for Data

    Would you recommend your organization pay a ransom to get the key to decrypt data that’s become encrypted on your database systems? What if the data were encrypted in backups going back two weeks?

    It’s an interesting question, and one I might expect we will have to deal with at some point. This week I saw an announcement that another organization, this time a university, paid a ransom to recover data. Before you react with “of course, not,” think about this quote from the University Vice-President:

    “We are a research institution,” she was quoted as saying. “We are conducting world class research daily and we don’t know what we don’t know in terms of who’s been impacted and the last thing we want to do is lose someone’s life’s work.”

    That’s a powerful statement, and certainly one that I could see salespeople, accountants, and more making as an appeal to upper management. What’s interesting in the piece is that the university acknowledges that using the decryption keys is a complex endeavor, requiring IT to get systems operational again. I hope that at the least they also made new backups of the encrypted data before using the keys. Who knows what sort of results come about from criminals that have encrypted, and the offered to provide reversal instructions and keys.

    I expect the ransomware efforts to become more prevalent across the next few years, especially as people have success. Even if fewer people pay ransoms, I bet plenty of people will look to disrupt organizations with these actions. Perhaps even a competitor will look to introduce ransomware into your company? Maybe by offering a job to an individual that leaves such a surprise behind as they get ready to move to a new employer.

    There are all sorts of issues here, and potential attack vectors. The fact that ransomware (or other malicious software) could be introduced to remain idle, or even transparently encrypt and decrypt systems until a date passes and the keys delete themselves, is horrifying. At the very least, I think this brings to mind the idea that we need multiple versions of backups, so mirroring a file system to another location, or some cloud service like Azure, Dropbox, etc., isn’t enough. Perhaps we should also have checks in place that look for changes. After all, can you imagine a rouge process implementing TDE and letting it run for a month before deleting the certificates from your system and truncating all the tables a week later?

    Steve Jones

  • Good Stories

    The IT horror stories. Many of us have them. The mistakes, the trials, and frustrations, these seem to be the stories we collect. Many of us have a story of deleting data, forgetting a backup, making a security mistake or some other item that perhaps should have terminated our employment. Or maybe it did. In any case, I’m sure most of you have a tale about some mistake.

    However, I think we don’t talk enough about the wins we have. The good things we do that actually help people, they appreciate, that get us kudos or even rewards. Maybe there’s something that garnered some unsolicited praise for your efforts. I’m wondering this week, what are your good stories in IT. ?

    I hear about good stories all the time from my wife. Her horse training efforts produce immediate effects, some of which are very powerful and moving for her clients. I hear about great things my brother does in medicine. Certainly I also get many very kind words from plenty of you about the help SQLServerCentral provides. But I haven’t had a lot of stories as a developer or DBA. Many of substantial upgrades or improvements I’ve made to applications were tempered with complaints about us “changing something.” At times, it’s felt like a no win situation.

    Perhaps my best story is from my time with a large sales organization. We had a demo system that provisioned a set of virtual machines to showcase our products. The complexity came from the fact that each demo environment was 6-8 machines, networked together in a VLAN that allowed them to be identical for each salesperson, yet isolated to prevent network issues. This was in 2001, when tools for managing virtual machines were rudimentary, and things like runbooks didn’t exist.

    I helped our administration team go from an Excel spreadsheet, with incredibly complex (and unreliable) macros to an web application. The application allowed them to easily track which environments were provisioned for which salesman, making the entire process much simpler, and more importantly, a multi-user system any administrator could access to provision or teardown demo environments. This wasn’t a large piece of software, and not widely used, but it made work much easier for a few people that were struggling with the constant and ever changing demands of busy salespeople.

    What’s your best story? Let us know today.

    Steve Jones

    The Voice of the DBA Podcast

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