I read an article by David Linthicum back in December 2014 that laid out the following scenario:
“It’s 1:00 am. You get an email from an “application migration manager” (automation tool) that says your inventory-control application containers successfully migrated from your AWS instances to your new Google instances. What’s more, the connection to the on-premises database has been reestablished and all containers are up and running with all security and governance services reestablished.
This happened without any prompting from you—it is an automatic process that compares the cost of running the application containers on AWS versus the cost of running them on Google. The latter proved more cost-effective at that time, so the auto-migration occurred based on predefined policies and moved the containers from one public cloud to another. Of course, the same concept also works with private-to-public or private-to-private clouds, too.”
Linthicum suggested that “while these scenarios might sound like science fiction today, the associated capabilities are coming, and fast”—in the form of containers. As I thought about the above scenario and its implications for container usage to SQL Server users in the future, a couple of additional scenarios came to mind:
Scenario 1: DevOps testing during business hours
It’s 10:00 am and the DevOps team wants to test the new containerized e-commerce application instances on the production test servers. Using the “application container manager,” it takes just a minute for DevOps to drag-n-drop the new containerized e-commerce instances onto the test servers, while maintaining a consistent connection string to the user application. The new application is stress-tested for 12 hours under a “Black Friday” simulation. After the test is completed, DevOps drags-n-drops the instances back onto development servers for additional development.
Scenario 2: Patch Tuesday with no headaches
Its “patch Tuesday” and there’s a new SQL Server patch to install. While containerized SQL Server instances run undisturbed on production servers, the DBA team patches the n+1 server, carefully documenting every step. At 1:00 am using the “application container manager,” the DBA team moves the containerized SQL Server instances onto the patched n+1 server for testing. Having passed the test, the DBA team patches the rest of the n servers the next morning and—in minutes—drags-n-drops the containerized instances across the production servers when it’s convenient to the business.
Containers reduce time to move workflows—and provide additional benefits
These scenarios represent some of the most common workflows for SQL Server users. The biggest implication of containers for these workflows is the reduction in the amount of time required to move the containerized instances seamlessly between hosts.
Linthicum went on to state what he thought were the few basic features and advantages, of using containers including:
• “The ability to reduce complexity by leveraging container abstractions.” For the SQL Server user, this means containerized instances would remove the dependencies on the underlying infrastructure services including OS. This would make it easier to deal with and leverage different platforms.
• “The ability to leverage automation with containers to maximize their portability, and with it, their value.” For the SQL Server user, this means making containerized instances highly portable and being able to use policy-based automation to move SQL containers from any host, to any host without breaking external dependencies.
• “The ability to provide better-distributed computing capabilities, considering that an application can be divided into many different domains, all residing within containers.” For a containerized multi-instance SQL Server application, the various instance containers could be run on different platforms. This lets the instance containers be distributed to the optimal platform according to their workload profile. Bare metal could be used for I/O-intensive instances, while VMs could be used for presentation-layer instances.
• “The ability to provide automation services with policy-based optimization and self-configuration.” With this capability, policies could be set that move containerized instances from a VM host to a bare-metal host depending on the time of day or month. For example, during a month-end process request, containerized instances would be moved to a more compute-intensive platform. The automation services would be smart enough to make sure the target compute platform has the bandwidth to make the service request before initiating the move.
The future is here. Containers are real, they’re coming to SQL Server fast, and they will transform the way SQL Server is deployed and managed.
Until next time…
