Voice of the DBA

Category: Editorial

  • 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

  • Republish: Are you a Data Scientist?

    Today I’m flying back from the UK, all day. Usually this is roughly a 20+ hour day for me to return home, so I’m not likely to do much work. You get to read a republish: Are you a Data Scientist?

  • Republish: The History of the VCS

    In London today, or actually likely still at Heathrow working in an airport hotel. Tomorrow is SQL in the City, so today you get: The History of the VCS

  • Getting Close

    Last week we saw the release of SQL Server 2019 CTP 2.5, with enhancements for Big data clusterrs and a Java language SDK for SQL Server. This is the 6th public release of the next version, and one that’s coming at an increasing rate. If you look at the cadence, there was a release in September, then November, then December, about once a month. A long delay at the beginning of the year, but now 3 releases in a month and a half, which lead me to think that they’re getting close to being done with features. I have no idea when the product will release, and I do think that //build/ is a little too close, but I do think that it will release in the next few months.
    For fun, I’ll send someone this mug (or a fun one of your choice) if you can guess which day the new version will release. Drop a note in the discussion with your guess.
    For SQL Server 2017, we had seven CTPs and 2 RCs. For SQL Server 2016, we had 11 CTPs and 4 RCs. SQL Server 2014, I only had 2 CTPs tracked, though I think this was barely a major release. You can flip back through our build lists and check, but there has been both an increase in the pace of CTP/RC release as well as an increasing volume through the versions. I think this is a direct result of an better engineering process that has adopted DevOps to ensure the release of software is easier than ever.
    I have to admit I’m torn on this. There is some effort to download and update software, and at times these versions have to be uninstalled to install a new version. That makes sense, and I certainly don’t want them spending time ensuring they can upgrade between CTPs if they can fix some bugs instead. Even if i have time to install the software and check a few things, I often don’t want to then recheck a number of things that used to work, and like many people, I probably just check one or two new things. Or if I haven’t finished checking something from a previous CTP, I might stick with that version.
    This is one place that I think containers can really change the world. I can get the updated software without effort. Other than the download, starting a CTP 2.5 image is no different than starting a CTP 2.4 image. There is still a challenge with data files, but in a very rapdily changing world, we want to be able to upgrade quickly. With the changes made with CUs to allow roll forward and roll back, containers make even more sense. Stop one container, start a new one, same IP, same name, same data, new version of binaries. Upgrade or downgrade.
    I’m both excited and intimidated by the new version. There are lots of enhancements that are going to make this a new generation of the platform, but as developers and customers request the use of new features, I’m going to be scrambling to better learn and understand some of the tricks I need to get the system to run well. Of course, with Intelligent Query Processing, maybe I’ll have a bit more free time away from some of the poor code that I’m stuck running.
    Steve Jones