How Docker Containers Helps SQL Server 2017 Shift Deployment to the Developer – InApps 2022

With SQL Server 2017, Microsoft doesn’t just want to bring its heavyweight RDBMS to Linux; it wants to make it more accessible to developers so it can take advantage part of the trend to DevOps and continuous integration through containers.

That’s something SQL Server has been excluded from in the past; not just because it was running on Windows Server but because the way it’s been deployed and managed is so different from the other components developers work with, SQL program manager Tony Petrossian told InApps.

“People have been doing CI/CD and DevOps for building database applications for some time but SQL Server itself has never participated in that ecosystem as a component of the application because SQL Server was always a server managed somewhere else. As a developer, what you get is a connection string to a database somewhere in the IT world; the database binary itself was always disassociated from the app development process.”

Moving SQL Server into containers doesn’t just mean a much faster deployment; it means you can deploy it as part of development rather than operations — and test your database code like any other code. You can even put a sanitized subset of your data in the container for devtest and have the pipeline automatically test code with the full dataset in a secure environment.

“What we really wanted to do was allow the developer to pull the actual binary of SQL Server as a component of their application in their CI/CD or whatever other development processes they use, no differently from any other library they might have as part of their application,” Petrossian explained. “So the application and the database are tested together at the same time through all the app changes the developer makes, and all of the automation of the testing includes the database itself.”

That stops developers who want to use features in new releases of SQL Server which aren’t gated by operations and IT processes designed for the slower release cadences of enterprise software. “Ultimately we’re hoping this will simplify upgrades because if the developer decides they want a newer version of SQL Server because it has a particular feature then they can just pull it in and change their app to use the feature. Then all their automation and testing kick in and they validate the newer version of the database along with their app, as opposed to developers writing their new code and asking IT to go upgrade some server some place — which might take some time or not happen at all.”

“That distance is always very cumbersome and being able to do it all in one place will simplify the process for everyone,” he suggested. Even the IT teams who’ve helped create this divide aren’t happy with the outcome because developers tend to just work around them.

“What customers are telling us is ‘If I can’t upgrade and I can’t have the developers do what they need to do, they just pick up some other product off the internet and throw it in and pretend it’s just a library in their app and now we have to support this other thing’. They wanted us to make it as simple to throw SQL Server in there as it is to pick up any open source library that a developer may choose to include in their app.”

Containerizing SQL Server also improves the collaboration experience for developers who work on different platforms. “Because it’s running in a Docker container, you could run on it any versions of Linux, any distro,” he pointed out. “If I’m working on Ubuntu and my app eventually runs in Red Hat, or I pass my app on to my peers to add something to it and they’re on a different version of Ubuntu, it doesn’t matter because it’s all self-contained. All the dependencies are baked in, including the version of SQL Server. Having the exact environment in your development environment matching your staging path and production is no longer that critical.”

And when development is finished, deployment isn’t a different process. “You just publish the production version and these production versions of the containers can deploy into production.”

Developers on the SQL Server team who build tools are finding this improves their own productivity and changes their workflow in ways that will sound familiar to anyone used to DevOps. “Instead of pointing other developers to stuff they have to pick up and install, they say ‘go get this container that has the particular build of SQL Server and the version of the tool you need to get your stuff done’,” explained Petrossian.

“Pretty much nobody installs anything anymore; they tend to keep their machines clean and pure. It’s a lot easier to spin up a container, do your work and chuck it away than to pollute your machine installing stuff on it that you might not ever be able to delete. It’s another simplification and — now SQL Server is part of that.”

In particular, he noted, it gives developers more choice over their development environment.

“On the SQL team, we have a mix of people who prefer to run on Macs — people who work on cross-platform tools tend to run on Macs — and some who’ve been on Windows for a long time. This containerized environment means you can have SQL Server running either way and it’s just easy to pass things around now. Even in Windows, you can run Linux images in containers, so it’s becoming easy to maintain a unified code base with the same version of everything running on a different platform. We’ve been very careful about full compatibility across Windows and Linux, so customers can move a database between Windows and Linux whenever they want. You basically copy the files, mount them and SQL Server comes up. It’s not a migration or a port or anything; it’s like moving a database from machine A to machine B and they just have a different OS. And with all the Linux tooling in Windows now, it’s really easy to copy stuff around.”

If all of this sounds just like the usual DevOps advantage, it is, says Petrossian. “This is very much In line with what other people are doing in building applications, but it happens, in this case, to include a database.”

Feature image from Microsoft.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.