Voice of the DBA

Category: Editorial

  • Cloud Transformation

    In the last few months, I’ve been traveling around at a few of the Redgate Summits (one more in NYC coming) running panels on cloud journeys. I’ve had industry experts, both technical and managerial, discussing their approaches and journeys with advice and caveats for others. It can often be more than just migrating systems, so a lot of people have started to talk about cloud transformation.

    However, in some cases, this is just a migration. A lot of companies just lift-and-shift their databases into the cloud, along with various other services. While this is a quick way to get into the cloud, it isn’t much of a transformation. If you review and right-size the resources you’ve provisioned, maybe there is a bit of a transformation, but not a lot.

    Instead, the idea recommended by most vendors and consultants is to transform your software to work in the cloud. This might be moving to containers, to using more cloud-native services, or re-architecting your software to embrace to way cloud vendors provide services. Often this is a major project, though it can provide advantages over time with cost savings, more efficient code, and better-trained developers.

    That last one is key, as a lot of the advantages of the cloud require your developers to write better code and re-think how they interact with data services. Code costs money, and poor code costs more money. This is also true on-premises, but it’s more true (and more visible) in the cloud.

    I was surprised at how many companies had embraced the cloud and how many had seen savings. I met quite a few companies that had moved their databases (including large enterprises) 100% into the cloud. They’ve seen savings, but they also rigorously audit resources and the provisioned sizes.

    The cloud isn’t for every organization, and not for all workloads. There are more than a few companies that have struggled to achieve the results they want in the cloud, be these performance or cost measures. I suspect some organizations will never move fully to the cloud, and may never move databases. However, it is a tool that we technical people ought to understand and learn why we recommend for or against a move.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • SQL Injection Is Not Acceptable

    SQL Injection has been a problem for my entire career. Thirty years ago I could have easily just blamed this on ignorance, as most of our developers didn’t think about the nefarious ways that hackers enter data in our applications. These days, there isn’t a good reason for this to keep happening, and the problem is us. I think that we don’t provide good examples or training on secure coding or secure architecture as a normal part of teaching programming. In many organizations, we don’t check for issues and prevent their release. Some do, but many don’t. On top of this, the existing code is usually a poor template for writing future code. I do think Microsoft aims for secure coding in SQL Server but in Windows, there is work to be done there.

    A few months ago, I saw an article that noted the US CISA organization and the FBI issued a secure-by-design alert (PDF) that noted there is no excuse for SQL Injection vulnerabilities (SQLi) in modern software. This alert notes that SQLi has been an “unforgivable vulnerability” since at least 2007. Inside the document on vulnerabilities, it notes that a single quote can’t be used in certain fields: username, password, ID field, or numeric field. They also note that co-mingling user data and query data, like constructing queries on demand, is a poor practice.

    The alert even emphasizes that developers are engaging in poor practices when they “fail to treat user-supplied content as potentially malicious.”

    I agree, and their recommendations are worth reading and implementing. If your boss doesn’t want to spend time on these, point out the bulletin and note that since this is a published advisory, I wouldn’t be surprised to start seeing lawsuits in the US or even insurance claim denials if your software team doesn’t follow these practices. Note that the list includes leadership support of secure coding and secure design principles.

    I doubt this has changed a lot, but I think some managers likely see this as a) a good idea, and b) a way to mitigate potential issues down the road. Changing the habits of software developers, updating code snippets or patterns, and even adding linting/static-code-analysis to CI pipelines take time, as does the training for developers. However, it’s something that has to start changing over time to get better at building higher quality, more secure software.

    I’d like to see insurance companies refuse to indemnify or cover losses or problems from software that is written from this point forward and is vulnerable to SQL Injection. There are far too many tools out, and software is too critical to allow these types of simple coding errors to proliferate. I’d also be pressuring companies to ensure older code is being actively refactored to reduce the number of vulnerabilities over time for all software they still support.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Five Years and Counting

    I almost called this “chasing a new laptop” since that’s what I’m doing, but I decided to add the date because the current laptop I’ve using was built in March 2019 and got to me in May 2019. I’ve had an HP Spectre x360, my second HP Spectre, and I’ve really enjoyed it. I’m also amazed it still runs. On the last few trips, the two rubber strips that run along the bottom (acting as feet) started to peel away. I’ve never seen that before and I tried to re-attach them a few times, but that didn’t work well.

    Not a big deal, and I can live with that, but then during my Australian tour, the laptop started pausing and freezing a few times. It might be that there is too much software on there and needs a pave-and-reinstall, but I decided to check the age on the machine. That was when I realized it was five years old. It’s been a great machine, but I don’t think I’ve ever had a work laptop last that long with daily use. Of course, there was about a year during the pandemic when it was rarely used, so maybe its life lengthened during COVID.

    In any case, I started looking around for a new one. My initial glance at smaller laptops has me considering these: another HP Spectre x360, the ASUS 14, the Lenovo Thinkpad X1 Carbon, and the DELL XPS 14. That’s the short list, since I really want a Windows PC that can run SQL Server and tools locally. I’ve had a Macbook before, and in the past I could run a VM with Windows tools. I can run SQL Server now, but not SSMS, and I like running SSMS.

    I’m just starting to look at some reviews, and think about what I need. I’ve had a i7 CPU, 16GB RAM, and a 1TB SSD, which have served me well for the last 5 years. I don’t think I need more, though 32GB is tempting for a memory upgrade. I don’t do a lot of heavy development, so it’s more about having the things I run be snappy in presentations with customers and at conferences.

    What machines do you use and like? I’ve appreciated the durability of the last two HPs, so I’m leaning towards another. I do like the pointer on the Lenovo, so that’s tempting. I’d like a touch screen as I use it regularly, though I don’t need a folding 2-in-1 machine. A normal clamshell is fine.

    If you have a recommendation, let me know. If you have a dream machine, make me drool over it.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Poor Database Design Realities

    One of the interesting things that I see at Redgate Software is how idealistic our developers and engineers can be. They often build our database DevOps products with the idea that customers will use well-designed databases. The systems will have primary keys, foreign keys, defaults, constraints, indexes, and more. Developers will use coding standards, and naming conventions, and will understand what data is stored in tables. Not in every case, but often.

    After all, that’s how we build software at Redgate, as teams, sharing information, publishing documentation for others, and following best practices.

    It’s cute and endearing, and unfortunately, not often true. In most cases, I find databases built by developers, accidental DBAs, or even experienced DBAs to be full of inconsistencies, lacking constraints and keys, and even duplicating some indexes and forgetting others. I often joke during one of my presentations that the main thing people should learn is to add primary keys to their tables. However, I’m not really joking.

    During a recent design session on our masking technologies, there was a discussion on masking data in tables without PKs, which is a challenge. We’re working on it, and also on being able to mask PKs themselves, as some people use the PII data as a PK. This could be a tax ID of some sort, but could also be an email address.

    When one of our account executives (Rob Boswell) heard that we were enhancing our capabilities with regards to PKs, he joked that we will soon be “primary key agnostic.”  It was a great line, and in one sense it’s true. In another, it’s sad that we need to design tooling around such poor practices.

    The reality of the world is there is a lot of bad design, bad architecture, and bad code out there. I applaud those who work to improve things in their environment, am saddened by those who don’t (either improve code or their skills), and frustrated by management not supporting efforts to be better. At the very least they should support efforts to teach your staff to code things right the first time, which helps improve future code. The next best thing is to refactor and improve older code, which can help you spend less in the cloud, or run longer with the resources you have on-premises.

    The reality is the reality we are in, but that doesn’t always need to be our future reality. We can change the future, each of us, by learning to write better code and improve how we approach our work tomorrow.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.