Voice of the DBA

Author: way0utwest

  • Really Important Software

    I remember reading about the Boeing 787 (the Dreamliner) being designed. I was fascinated by the process and excited to fly one. I finally did and enjoyed it. Since then, I try to fly on those when I can as the spacious ceiling and other changes seem to make for a better flight. I impressed with the work they did and the scale of the changes, both in manufacturing and software. There’s a short timeline here and if you ever get the chance to take a tour of the factory, do it. It’s very cool.

    I fly a lot. Last year I took around 50 flights on airplanes, some of them Boeing, some Airbus, some 737s, 777s, 787s, A350s, and a few others. I haven’t flown on a Boeing 737-Max 8, though I did just recently fly a 737-800. When a few of those planes crashed, I somewhat chalked this up to pilot training and a lack of options on the planes. I’m not exonerating Boeing or the airlines, but I wasn’t personally concerned. I saw an interesting piece at Vox, but was still curious about the issues. After all, I’m in software, and I fly a lot.

    There’s an analysis of the crash from a software developer at the IEEE site that’s worth reading. It’s a look at the issues, the potential ways things could have been addressed and, perhaps most importantly, the idea that our software is not necessarily going to fix problems. Software is a way of reading data and then affecting changes in the hardware, but software isn’t perfect. One of the quotes in the article puts this in perspective for me: ” Every time a software update gets pushed to my Tesla, to the Garmin flight computers in my Cessna, to my Nest thermostat, and to the TVs in my house, I’m reminded that none of those things were complete when they left the factory—because their builders realized they didn’t have to be complete.”

    Data matters, but as we all know, data is sometimes incorrect, jumbled, or otherwise problematic. In this case, not only does it appear the data could be incorrect, but the plane software isn’t looking at all the data, and it certainly doesn’t take all the inputs from the pilots. While humans make plenty of mistakes, they need to have inputs and overrides in software systems.

    I don’t want to get caught up in the issue with these planes, but rather look more generally at our systems. DevOps looks at the idea that we don’t know everything about how to build our software when we start. We definitely know it is not complete and will need more work when it leaves our factory, but we also know that this is the case. We know it’s not complete. We take feedback, learn, and adjust what we do. We constantly drive quality up, or at least, that’s the goal. Money and politics can get in the way, but the more they do, the less you’re doing DevOps.

    Steve Jones

    Listen to the podcast.

  • The Minimum Upgrade Point

    These days the pace of change with SQL Server can be intimidating. Many of us work in disparate environments with multiple versions of the platform in our environment. In the distant past I’ve had people note that they often have 2 or 3 versions to support. In the last five or six years, when I’ve asked it seems that many people have 5 or 6 versions to support. That can be challenging in trying to manage your estate as a single entity and understand which scripts will run on which machines.

    Recently someone noted on twitter that they tried to convince their company to upgrade to SQL Server 2017, but apparently someone at the company wanted to stick with SQL Server 2014. I asked a question and the person responded that since Dev and QA was at the 2014 compat level, they wanted prod there.

    Pedro Lopes, from Microsoft, asked a good question: “How can I help you avert this?” I tend to agree, in that moving to 2014 now, which will fall out of mainstream support in July 2019, is silly. You’re installing a system that will be unsupported almost from the beginning. While you will get security patches for a few years, it seems short sighted to start using a version that you may want to use for 10 years.

    That got me thinking. What is the minimum upgrade point for your organization? Not the pace or the need, but if you had to pick some random instance to upgrade, where would you go? SQL Server 2017? Something sooner? Perhaps you have some requirements in your organization that limit you from moving to a very new version. I would argue that it’s important dev/test are similar to prod, but I’d also say that dev and test ought to upgrade to a recent version as well.

    I think I’d specify SQL Server 2016 SP1 as the minimum point. This changed the feature list in Standard Edition, which is what I’ve often run for systems. We run that now for SQLServerCentral, though our decision last year was a move to 2017. We probably won’t upgrade again for many years, but if we did, I think I’d be looking to get close to the most recent version.

    What would you do?

    Steve Jones
    Listen to the podcast at Libsyn.

  • SQL in the City Summit comes to Brisbane on May 31

    SQL in the City comes to Brisbane on May 31. It’s a day before SQL Saturday #838 – Brisbane. If you’re anywhere close, which likely includes Sydney, take two days and get lots of Database DevOps and SQL Server training for a very low cost. I’m hoping for a good turnout and the chance to come back again next year.

    Register today for a full day of training and talks about DevOps and Redgate products on Friday, then come back to SQL Saturday 24 hours later.

    I’m excited for the event. We completed our London Summit this week and it went very well. I’m taking over the keynote from Kendra and also doing a Monitoring session as well as covering privacy and the panel.

    It’s going to be an exciting day, so if you want to improve your Database DevOps process, in a Compliant way, sign up and come on May 31.

    2019-05-02 11_33_08-Window_thumb[2]

  • Serverless

    About a year ago I kept hearing about serverless as the way to go for all new code. It seemed every conference, every cloud vendor, even many developers were discussing serverless as a technique for running small snippets of code. This technology seemed to burn very bright, but then dropped out of the media somewhat. It’s still being adopted, but seems less popular than a year ago, with containers and Kubernetes becoming more popular this year.
    Serverless computing is kind of a backend-as-a-service (BaaS) or a function-as-a-service (FaaS) architecture where you write and deploy functions on a cloud service that are called by your application as small chunks of functionality. The pricing is by the execution, with a very low cost for resources. Azure Functions cost US$0.20/million calls and US$0.000016 / GB-s. Strange metrics, but the result is a very low cost for most clients to use a functional part of a system. The key is that there are not infrastructure worries. The serverless platform provides the CPU and RAM needed to execute a function, with storage also available on the cloud provider’s platform.
    I ran across an interesting article that talks about serverless platforms on premises don’t quite make sense. The idea with serverless is that you most closely pay for what you use, not being charged for times when your code isn’t being executed. On premises, you would need some hardware running all the time that you are paying for, which is ready for when code is called to execute.
    I’d disagree slightly, especially with architectures like Azure Stack that blur the line between private and public cloud resources. With Azure Stack, you should (at some point) be able to write applications using serverless functions that execute in your data center. If you need more resources, you scale your data center up with Azure cloud resources, and pay for your usage. When the workload shrinks, you stop using cloud resources and just use your data center.
    Most of us won’t necessarily want to run an Azure Stack, so why would be use serverless on premises? To me there is one element of a cloud service I can’t control: what other people do on the platform. Cloud services are large and distributed and in use by lots of customers at a time. If I execute things in my data center, on some serverless platform, I have better control over how things work and likely more predictable performance. If my workload is well known, I also probably have lower costs.
    In many cases, we know the workloads of our databases, and we want predictable performance (however good or bad it is). Databases are potentially a good fit in the cloud, but often in a mature application, we would be better served by keeping the database on premises, especially if we’ve already invested in the hardware and other resources.
    Serverless is a very interesting idea, as is much of the cloud. It might suit your application, or it may not, but you have to think about the requirements for your situation. Knowledge of new options and technology is important for us to intelligently debate and discuss what works best for our organizations.
    Steve Jones