These days, it seems everything is offered “as-a-service.” Applications are moving to the cloud, and every one of those apps is delivered faster due to Agile and DevOps. Everything except the database.
Our customers, specifically DBAs, know the database will move to the public cloud soon and they also know that the migration will be fraught with all sorts of problems along the way. Though the database’s move to the public cloud seems inevitable, DBAs are frankly dreading it.
The hand-wringing around this shift is absolutely justified, as there hasn’t been a faster, smarter and safer way to get the right database changes deployed reliably and accurately across all environments after a move to the cloud. It is practically impossible to manage database schema changes while making certain that no database change violates compliance and governance rules. Even worse, those changes can cause downtime for critical applications. Our best and brightest DBAs are overwhelmed by this manual burden, and the move to database-as-a-service will only exacerbate the problem. Given those concerns, it should come as no surprise that DBAs are worried. We should listen.
But there is hope in automation. Once database deployment automation is in place, the only action DBAs have to take to migrate to the cloud is to change the target. That’s right…once on-premise database changes have been automated, the move to the cloud is academic. Maybe we shouldn’t even refer to automation as a “hope” – it has actually become more of a basic necessity than a dreamy luxury. If automation isn’t infused into every step of application release TODAY, the move to the cloud will be a downright failure.
With that in mind, here’s a quick list of “must do’s” to ensure that a long-term strategic shift to DBaaS or cloud DB is successful:
Decide on your timeline for the shift and stick to it. There will always be a reason to maintain status quo – development schedules, politics, sun spots, you name it. Select a mantra and use it every time you get pushback on the schedule. Something like, “We are moving to the public cloud to save money, enable agility and deliver better service to our customers. You want those things, right?” Remind people why the shift is happening and hold the line.
Perform your due diligence on automation solutions and avoid those that ignore the database. The statement, “Just insert your SQL script here,” should be your number one red flag. Requiring people to perform work manually (and executing a SQL script is definitely manual effort!) is not true automation.
Have an expert come onsite to be there side-by-side with you throughout the automation software integration process. Stand on the shoulders of giants and use their experience to supercharge your move to the public cloud. After all, there’s no shame in asking for help, but there is shame in trying to solve a problem on your own that others have already found a solution for.
Pick one application and drive it to success. You eat an elephant just like anything else: one bite at a time. As your company begins shifting to the cloud, there will be a number of learnings and mistakes. Isolate those to one application, learn quickly and then properly apply them to the other applications. Nothing breeds success like success.
Test early and often. Create and run as many tests as possible to ensure everything is in working order pre-shift and post-shift. Make certain those tests continue to run regularly to identify later outages. You will want to know quickly if some change has broken previous work, rather than having your customers identify the issue for you.