Best Practices for Moving your Government Databases to the Cloud

Are you thinking of moving your databases to the cloud? Perhaps, you’re thinking about transitioning to database-as-a-service (DBaaS)? But what’s involved? What hurdles must be overcome and how do you chart a path to cloud migration of your most sensitive workloads?

Why Move Databases to the Cloud?

Migrating to the cloud offers several benefits to public sector database administrators (DBAs).

Lower maintenance costs are usually the priority in adopting cloud computing. Doing away with a big chunk of Capex for hardware and software installations, maintenance, updates, patches, and end-of-life-in is very appealing. But it’s important to keep track of the expenses that that take their place. Besides licenses and subscriptions, agencies also encounter indirect costs such as steep charges for network usage during migration, loss of information during outages and loss of productivity from unexpected application downtimes during database migration.

Other important considerations for cloud adoption are reliability and redundancy. Cloud providers tout high reliability and put in place strict procedures to ensure there is no single point of failure. Flexibility, is another priority. The cloud offers the ability to scale up and back down quickly keeping needs and resources closely matched. When managers want to stand up a development environment with a database, they can create it immediately, get their developers working on it in no time and scale it up and down. Agencies can take advantage of this feature during busy times, such as tax season on healthcare enrolment periods.

Security in the cloud is now stronger in the cloud than on-premises. Few agencies have the resources to match the armies of people hired by cloud providers to test and track security assurance.

What Should We Move to the Cloud?

In principle, moving every one of your 1,000-plus databases to the cloud is a fine idea, if you realize all the promised benefits without any downside. As mentioned above, however, unexpected costs arise.

Suppose you’re moving from Oracle multicore processor licensing (MPL) on-premises, where you’re accustomed to a 50-percent Oracle Core Factor. You figure you have eight physical cores in your on-premises server, so to license eight cores from Oracle, you’ve been paying for only four cores. If you move to an Amazon Relational Database Service (RDS) environment with the same eight physical cores, Oracle has said that the Core Factor doesn’t apply in the cloud, so you’ll have to pay for licensing on eight cores instead of the four you were accustomed to in your on-premises Oracle implementation.

Development and quality assurance are good candidates for the cloud, which scales up and down easily with individual projects. It’s a big advan­tage to quickly spin up multiple instances for writing and testing apps, if you remember to remove them when they’re no longer needed. Cloud infrastructure costs money whenever it’s running, even when it’s not in use. For instance, if you have a cloud database for development and your developers use it only a few months out of the year, the meter is still running. The absolute costs are low, but they add up over time.

How Do We Move to the Cloud?

Moving to the cloud is an ongoing journey. Most agencies will spend the foreseeable future gradually moving on-premises to the cloud. That’s the argument for starting small, moving the development environment to the cloud or moving discrete applications with few hooks into other systems. The biggest problem in moving a database is maintaining and protecting it as it goes from source to target.

You have four options when moving to a cloud-based database:

Start with tables and schemas that support applications that are not critical to the business (low-risk, but slow).

Develop brand-new applications using databases in the cloud without migrating old databases at all (clean, but hard on history).

Take the big-bang approach by backing up and restoring before users are affected (comprehensive, but requires protracted downtime).

A safer, less-drastic way to ease migration to the cloud is to replicate data from a source database on premises to a target data­base in the cloud (smart and innovative).

Planning your Migration to the Cloud

Moving databases to the cloud and making the transition to DBaaS can be like having one foot on the boat and the other on the dock.

Having some help from smart technologies is a great place to start. Database repli­cation solutions can track and preserve database updates to keep your source and target instances synchronized. The result is reduced downtime for migrations, patches and upgrades, at less than half the cost of native replication products. Users can continue accessing up-to-the-second data without affecting database uptime. System admins can go form working on the old database to working on the new on in less than an hour.

There are some fantastic technologies that can help your agency get where it needs to go. Learn more about database replication for on-premises, cloud, or hybrid environments from our partner, Quest Software.

 

bradley.gernat@dlt.com'
Bradley Gernat