Voice of the DBA

Category: Editorial

  • Do What Hurts

    A long time ago I heard a manager at a company say that if something is hard, we ought to practice it more and find ways to make it easy. Barring that, we ought to at least be comfortable with the task. I’m not sure if this manager made this up or read it somewhere, but it’s the same thought expressed by Martin Fowler in this post: “if it hurts, do it more often.”

    I’m not sure that’s the advice I want to use with everything. When my shins hurt from running, or my shoulder aches after hitting a number of volleyballs, often I want to take a break. At the same time, I know that stopping isn’t always the productive thing. I can slow down and build up some strength and things will get better. My long running streak started with slow jogs for short distances, slowly building up the strength in my muscles and joints. Regularly hitting volleyballs and slowly increasing the number I hit allows me to get more done without hurting myself.

    At the same time, putting a hand on a hot stove doesn’t get better, no matter how slowly I increase the heat over time. There are some things that aren’t worth doing more often to get better, but building software is one where we can get better. Our practice does improve skill, quality, and ability if you practice well. We can decompose our problems easily, we can work in steps, and we can (relatively) easily alter our course of work if we need to do so. In fact, quite a few of the software methodologies adopted in the last 20 years are designed to improve the entire process be ensuring we adapt our work to the customer with regular pauses to evaluate our progress.

    When the pain of delays (procrastination) grows, we should find ways to reduce the hassles. Often the pain comes from difficulties, and when that is the case, we might do what Martin Fowler suggests: do it more frequently.

    It works well for databases, as he points out in his post, though I’d caution the data professionals to consider the details in his post. Decompose the problems and make the changes across multiple steps, not all at once. When you do that, make sure you plan for pauses in the various stages, not just stringing together multiple scripts into one transaction. That will help you evolve the database along with the application while ensuring your customers can continue working as you make changes.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Losing The Security Game

    It’s sad some weeks to see reports of security issues at large companies. It’s also discouraging some times when clients or friends will talk about security issues they’ve had in their organization. What’s mostly disappointing is how easy many of these issues would have been to prevent with a little effort.

    Joey D’Antoni made some fun of this with his Data Breach Game. It’s a bingo card you can print out and use the next time you hear about an issue. My guess is most of us could win this in about a week with the general state of security in most places. Some of you might win this in a day with inside knowledge.

    This is poking a little fun at the poor security practices of many places. There’s a wider article about 9 poor security practices you can read, with some notes about what you should be doing instead. When you read it, you’ll wonder why hasn’t someone just made these simple changes and dramatically improved security? I have asked myself that many times when I’ve seen some environments.

    Ultimately, no one wants bad security, but we (as a group) often make poor choices because we’re in a hurry. We can, and should to better. All of the items on this list can be avoided, and should be. Even the complexities of SQL Injection can be fixed with a little code refactoring. No time or that’s too hard? You should be building software in a Compliant Database DevOps manner.

    I like the list, though I wish ElasticSearch where on there in number 6 with MongoDB. Too many breaches this year from people dropping that server on their network without a password because they need full text searching of data. Don’t make that mistake. Always, always, always set a password on data resources. Developer or partner complaints aren’t worth the risk of losing data from an unsecured server.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Laptop Recommendations for 2019

    Every few years I upgrade my laptop. I try to get through three years with them, and I’ve had some good success. At the same time, I’ve also had some wear out sooner, especially with the amount of travel that I do some years. I had one laptop last just a year before it started to constantly crash on me. That one was just out of warranty, which was a shame. Since then I’ve usually paid extra for a warranty to get a couple years of service out of each machine.

    It’s not quite that time for me, but it’s getting close. My laptop is about 2 1/2 years old and I’m starting to have some thermal issues. Changes in temperature often cause a crash when I come out of hibernation, which isn’t what a traveling presenter likes to see. I’m also starting to have poor battery performance. A full charge recently netted me only about 3.5 hours before the battery warning came on at 20% left.

    I have been pleased with my HP Spectre x360 model right now. It’s held up well and I’ve enjoyed using it. The arrow keys are a little oddly placed for me, but overall, everything else has worked well. There’s a new model, which is one of those I’m considering, but I am keeping an open mind.

    This week, I’m asking you what models you might recommend that you’ve used. One you’ve owned or had a friend own that seems to perform well. Keep in mind that I travel quite a bit, so durability and weight matter.

    I used to want a 32+GB RAM machine, but these days I do more in the cloud or with smaller demos, so I think 16GB is really the sweet spot for me. A fast CPU and 512GB-1TB storage is nice. I’ve done well with 512 across the last two years, but you never know how things will change, so a 1TB is something I’m considering. As much as I’ve enjoyed USB-C, I still sometimes like the convenience of USB-A, especially when on the go and not wanting to pull out some sort of adapter (like on a plane).

    Let me and others know this week which models have worked well for you. While many of us don’t necessarily get the choice of brand, some do, and many might be able to influence the model that they receive. Most of us want a laptop we enjoy using, and having a few recommendations gives us confidence that we’ll choose one that works well for the next few years.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • More Network Restrictions

    This past year has seen quite a rise in ransomware attacks. Certainly some big ones (Baltimore, Florida) are reported in the media, but there are lots of smaller ones that don’t make the news. As I’ve been attending some events in the last couple months, I’ve talked to various people that disclose they’ve had ransomware issues. Most of those didn’t make the news, but the events did cause IT staffs to scramble, work long hours, and forgo other tasks that might be improving the organization or helping customers.

    We know that there will be attacks on our organizations in the future, and some of them may be successful. Almost everyone is regularly attacked, though most are repelled with simple firewalls and better coding to prevent SQL injection. There are other things we can do, and certainly other groups in IT that need to worry about systems, but I suspect we’ll start to see one more change in how we work.

    Recently I was accepted to speak at SQL Saturday Memphis and really enjoyed the trip. However, when practicing one of my demos early in the am, I had trouble connecting to some remote resources. It wasn’t obvious what the issue was, and since I wasn’t in control of the endpoint for demos, I worried that the instratructure had an issue. Not what you want to see on a Saturday before a demo.

    Eventually I narrowed this down to port 1433 being blocked. Not a big deal as I had a VPN, but certainly something to be concerned about for a database professional. However, then I thought about the ransomeware and other security issues many organizations have had. Maybe some restrictions are a good thing.

    I wrote about networking segmentation, as did Joey D’Antoni, and I think this is where we will move in the future. After the SQL Slammer worm, plenty of organizations changed networking policy to hide port UDP 1434, which was good. I think some have gotten lazy, and the security issues we are seeing today might change things.

    That’s going to mean less access for people to connect to machines. That also means we need to think about DevOps style automation pipelines for code. We need to learn more about how to let machines run scripts for us and limit access. That way if our machine is attacked, we won’t necessarily be able to spread the issues to servers. We’ll still have plenty of other machines that might get hacked, but hopefully we can protect our servers.

    Security has become a bigger part of the job for all IT pros, and certainly critical for database pros. I hope that most of you embrace more stringent security and not try to circumvent it. Use automation, proxies, and more to keep your systems secure. And if they don’t quite work as you’d want them to, learn how to adjust them and work with the system, not against it.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.