Is SQL Server the push you need to move to the cloud? Last July, Microsoft put a stake in the heart of SQL Server 2008, ending even extended support. SQL Server 2012 and 2014 are in extended support now, and SQL Server 2016 is less than 18 months from the same status.
IT and network managers with applications dependent on SQL Server have an uphill climb to keep their database infrastructures up to date, even in a mature product like this one. The concern isn’t limited to the software; server OSs, CPUs, memory and disk are all part of the biannual SQL upgrades I’ve been seeing.
There is an alternative: cloud-based Platform as a Service database services. This isn’t just the cloud version of the Infrastructure as a Service approach that IT managers in all sectors are embracing. Database as a Service is an opportunity to eliminate an entire layer of management and responsibility by moving from IaaS to PaaS.
SQL Server’s End of Life Puts the Spotlight on Database as a Service
Many IT managers are already looking at the possibility of shifting workloads to cloud service providers. Although larger institutions are accustomed to running in-house data centers, that’s beginning to change. Many administrative and collaboration applications can be outsourced, which frees IT staff to focus on strategic applications on the academic and research sides of the house. In higher education, the huge shift to Microsoft Office 365 is testament to how much IT groups want to get someone else to do the hard work of providing email and collaboration services to students and faculty.
Unfortunately, many administrative applications have complex infrastructures, including multiple tiers of servers and callouts to local application programming interfaces. The task of shifting an entire application, especially a homegrown one, can seem insurmountable. This is why IT managers are running into end-of-service limits on SQL Server to begin with: Touching and updating the application has turned into an unpleasant and dangerous task to be avoided until absolutely necessary.
The obvious solution to these woes is either to pick up the entire application, doing a “lift and shift” to a cloud service provider, or to switch to a new version or even a new application that’s more cloud-friendly from the start. That’s the best practice, the way to optimize price and performance, and the approach that will achieve the biggest gains from a cloud shift. But what can you do when that’s not possible and you have to get onto a supported database version?
Shifting to PaaS database services could, in theory, be as simple as signing up for a database service, changing the address of the SQL server and forcing Transport Layer Security encryption on the connection. Your existing applications could run and, aside from a much longer (and perhaps slower) pipe between the application server and the database server, everything would be just the same as it was the day before.
To evaluate whether this will work for you, consider three factors.
Performance, Security and Cost Are Factors in Database as a Service
Performance will always be the biggest issue. If the database server shows thousands of queries per second (check the SQLServer:Databases object in perfmon as a starting point), lots of logins and logouts, and extremely large transaction sizes, the latency (and possible bandwidth limits) between your data center and the cloud may be too high for good application performance.
Huge databases aren’t a problem — cloud providers have that figured out, although migration can be a pain — but inefficient use of the database will be magnified and degraded by a cloud between application server and database. The key to determining whether a cloud shift will work is to understand the overall architecture and how the application uses the database.
From a security perspective, moving data off-campus always sends up red flags. With all of the compliance requirements in higher education, the custodial requirements for even data that is not personally identifiable information are significant.
Fortunately, cloud PaaS database providers do a good job of logging and auditing, if you take the time to set things up properly in the first place. A thorough security review, especially of access controls, is an absolute necessity before moving the data. Adding TLS (for data in motion) and Transparent Data Encryption (for data at rest) are likely first steps.
Costs and licensing are also important. Inefficient databases in your data center may be slow, but inefficient databases in the cloud are slow and expensive. Shifting to PaaS saves hardware, storage, backup, licensing and management costs, but replaces them with service charges.
No matter which database you select, you need to properly size and scale it within the PaaS framework to achieve your performance goals. Fortunately, PaaS providers generally let you move up and down levels, so you can find your sweet spot for price and performance.
Performance, security and costs are key when looking at PaaS databases, but they’re not all you’ll need to consider. Other factors include data migration, database access to secondary applications, management and support, backup policies, and a new support model.
Moving a database to PaaS and leaving the application in your data center is often the least desirable option, especially when compared to shifting an entire application to the cloud. But if SQL Server retirement is forcing this on you, it’s an option — and it may be a first step toward a larger cloud migration.