It’s that time of the year to make predictions for next year, so here’s mine: 2015 will be the year of containers for SQL Server. I can already feel the momentum building.
During 2014, there has been plenty of talk about containers. Most of it has been generated by the much-hyped Silicon Valley startup, Docker, which is making Linux containers easier to use. But containers aren't a new idea; a simple Google search tells us that Docker isn't remotely the only company working on containers and that containers take many different forms to solve different business problems.
In fact during 2014 Oracle also introduced a container for Oracle 12c, called Oracle Multitenant. It’s a new architecture that allows a multitenant container to hold many pluggable databases. An existing database can simply be adopted with no application changes required.
So what about the SQL Server world? In 2015, I predict that users will be able to leverage container technology for the management of SQL Server. The driving business reason is the promise of measureable results to business agility. Let’s look at a couple of agility definitions from the experts to see what that means:
"The ability of an organization to sense environmental change and respond efficiently and effectively to that change." Gartner
“The quality that allows an enterprise to embrace market and operational changes as a matter of routine.” Forrester
Ok, but what does business agility look like specifically for the SQL Server user? What part can containers play? In this regard, I have to give credit to Oracle because many of the measurable results of Oracle containers on business agility will be the same for SQL Server users, but without Oracle pricing (another prediction).
For the SQL Server user, business agility is a function of five key attributes. Let’s take a closer look at each of them:
- Rate of instance/server expansion: This is the ratio of instances to servers, regardless of type. When a new instance is deployed, a new server is required.
- Speed of service deployment: This is all about DevOps, or more specifically, measuring the speed and reliability of continuous deployment by eliminating inconsistencies between development, test and production. How long does it take to move a workload (i.e., instance) from development to test to production?
- Time to patch/upgrade: How long does it take to patch/upgrade your SQL Server environment? How much planned downtime is required to complete a patch cycle?
- Service level attainment: Are you meeting your service level agreements? How much unplanned downtime are you experiencing per year? How long does it take to restore service after an outage event?
- Technology refresh cycle-time: The question isn’t if you’ll move to a new platform, but when. The platform you’re on today isn’t the platform you were on seven years ago or the platform you’ll be on in three years. How long does it take to complete a technology refresh? How long does it take to migrate services from an exiting technology platform to a new one? How long does it take to move workloads (i.e., instances) from one server to another?
My prediction is that, like an Oracle container, a container for SQL Server will increase business agility and reduce IT costs by simplifying consolidation, service deployment, patch/upgrade management, technology refresh and increasing availability and resiliency. And those critical business results are what will make 2015 the year for SQL Server containers.
Until next time. . . Happy Holidays!
