Voice of the DBA

Category: Editorial

  • Republish: Aging Software

    I’m up in the mountains today, spending some time with family. You get to re-read Aging Software.

  • Giving Computers Ethics

    I was reading a fascinating paper recently about autonomous cars. I’m actually excited about having a car that can drive itself, though I think this is likely quite a few years away, despite the hype. Ever since I read Red Thunder, I’ve thought that we would first get full time autonomous cars that would either be limited in where they were in use, or part-time autonomous cars that could only be self-driving in certain places. Dense inner cities, or maybe isolated highways might be good places to try this, in my mind.

    While we want to do some programming of these cars, we also have a lot of AI/ML systems in place that run models trained to react in certain ways. They identify things that are moving and stationary, trying to determine how the car should navigate and react. The systems aren’t quite as tightly programmed as many of us expect, with if this then that logic. Instead they have guidelines that are decided upon by the designers and then reactions to data inputs and analysis are a little more fuzzy.

    What are the goals? Well, in most cases they are just moving the car safely down a road. In crisis situations, it’s a little more murky. What happens when collisions are unavoidable? How should the car react? Humans often panic and do strange things, but we don’t want erratic behavior from automated systems, so what should we set as goals? There’s a bit of research that was done to ask humans what they would do when they can consider the situation a little more slowly.

    In short, humans make different decisions in different cultures. There are clusters and tendencies in different parts of the world, which is interesting. While people are people and behave similarly in many cases, we tend to value different things, depending on our views of the world. That can be problematic when we start to expect computer systems to be more consistent or predictable. After all, we should decide how computers react and be able to trust our decisions are followed. It is up to humans to imprint our ethical desires as a society on computer systems.

    This is an area where I feel AI and ML systems are moving faster than our ability to comprehend the implications. I would want to have a framework built for automated systems, certainly cars, and then expect all vendors of systems would implement that framework in their vehicles. However, this goes beyond cars, and in any places where we are using software, AI/ML based or not, we ought to publish a comprehensive outline of the way in which our system works.

    Computers have the capability to improve our world and reduce chaos, but only if we agree on the way in which these systems work, and disclose in a transparent way what data they handle and what decisions they make based on that data. I hope that we start to get better about informing the world the goals and operation of our systems. I’m not sure that will happen anytime soon.

    Steve Jones

    The Voice of the DBA Podcast

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

  • No More SQL Server Installs

    This occurred to me recently, and I’m wondering what some of you think of as the answer to this question: when will you expect to no longer install SQL Server?

    It’s not that I think many of you are retiring from SQL Server work. It’s not that your organization won’t use SQL Server. It’s that I wonder if we’ll stop installing SQL Server on the host OS. We’ll make use of SQL Server in new ways, which won’t require an installation.

    Lately I’ve seen a lot of tweets, post, and more about SQL Server in containers or Kubernetes. Anthony Nocentino and Andrew Pruski are doing lots of work here, and I’m moving my work to containers for demos. With a container, you don’t really install SQL Server. Instead you install the Docker engine and then “start” a pre-installed SQL Server image inside a container. You might modify this before starting it, but you aren’t installing a version and upgrades are pulling a new image and then restarting the new image. With the better support for containers on Linux, this means I’m also starting to think Linux first.

    Plenty of you are also looking to do more work in Azure, AWS, or some other cloud service where you likewise don’t need to install SQL Server. In those cases, you’re really working with a service that implements a database, not an instance. There are some variations, such as the Azure Managed Instance, but you still don’t need to install SQL Server. You apply your database code, point your application, and off you go.

    SQL Server 2019 is starting to feel like the first version where I’ll be looking to ignore the SQL Server instance and think in terms of containers most of the time. I’ll probably still install it, as I need to test and check things, plus, I’m still learning how to work containers into my workload, but I’m guessing that with SQL Server 2020, or 2021, I’ll just stop installing SQL Server.

    Unless I need to document the installation for some of you, but in that case, I’ll try to get you to stop installing the binaries and just use a container.

    Steve Jones

    The Voice of the DBA Podcast

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

  • What’s Worse than Announcing a Data Breach?

    What’s Worse than Announcing a Data Breach? You might think that’s the worst thing that you could tell your boss these days. Imagine discovering that sensitive data has been exposed and you need to go inform an executive. Hopefully no one is looking to punish the messenger, but it will still be a very uncomfortable conversation.

    Now imagine that you need to go back and have a second discussion a day or two later. Why? More data was exposed, and potentially lost. I’m not sure which conversation is worse, though if you don’t have a list of things you’ve checked, changed, or fixed between the two meetings, I would argue the second one is worse.

    That happened to a mortgage loan company. The data breach was already bad, with an Elastisearch server out there without any security. Data had been converted from paper documents through an OCR process, which resulted in no shortage of mistakes, but there was still plenty of sensitive information out there. Things got worse when security researchers discovered the source of the OCR process was an Amazon S3 bucket that container the original images, also without a password.

    Before I comment on anything else, there should be NO shares, buckets, containers, databases, or any sort of server without a password. None, nada, zip, zilch, no excuses. At least protect everything with a password that meets your organizations password requirements. No “12345” or “asdf” or default passwords. Before you do anything else, go set passwords. If you have S3 buckets or Azure storage, write a script to check them all. Set. A. Password. On. Everything.

    We will all make mistakes in configuration, and there might be security issues at times. These ought to be rare, with today’s vulnerabilities scanners, static code analysis, configuration as code, global policies, etc. There really isn’t any excuse why we don’t set things up at the beginning, but if things change and mistakes are made, we ought to detect them quickly. And then fix them. That’s why we should use automation, configuration as code, and regular evaluation of our systems.

    One of the greatest strengths of the DevOps philosophies is that we can deploy changes quickly to fix things. We’ll make mistakes, we’ll have issues, but when we find them, there is no long waiting period to get the fix into our client’s hands. That ought to be true for both software and infrastructure.

    Steve Jones

    The Voice of the DBA Podcast

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