|By Pete Pickerill||
|March 26, 2014 12:00 PM EDT||
In the final post in this series about bringing DevOps patterns to database change management, we’re going to discuss the Third Way. Here’s a refresher on the Third Way from the introductory post in this series:
The Third Way: Culture of Continual Experimentation & Learning – This way emphasizes the benefits that can be realized through embracing experimentation, risk-taking, and learning from failure. By adopting this kind of attitude, experimentation and risk-taking lead to innovation and improvement while embracing failure allows the organization to produce more resilient products and sharpen skills that allow teams to recover more quickly from unexpected failure when it does occur.
The Third Way is by far the most intriguing of the “The Ways” to me. I’ve spent the lion’s share of my career in early stage start-ups where cycles of experimentation, learning, and failure are the norm. When bringing a new product or service to market, your latest release is never your last. It may not even be the last release this week. You are constantly experimenting with new workflows and technology, learning about your target market, and getting more valuable information from your early failures than your early successes. The Third Way is crucial to the success of an early stage company.
While the benefits of the Third Way still apply to more established companies and product lines, practicing it becomes more difficult. The potential negatives of experimentation and risk-taking are much harder to stomach when you have a large base of paying customers with SLAs. This aversion to risk is most acute when you’re talking about your data platform where outages, performance problems and data loss are not an option. Complicating matters further is how difficult it can be to unwind the database changes that were affected to support a specific version of your app. Application code can usually be uninstalled and replaced with the previous working version fairly simply should problems arise. Reverting the database changes that support that version of the application is more akin to defusing a bomb. Database changes must be reverted delicately and meticulously to avoid errors and omissions that could negatively impact your data platform.
What DBAs and release managers need to facilitate experimentation and risk taking on the data platform is a special combination of tools and process. This combination should make it easy to identify the root cause of issues, quickly remediate problems caused by application schema structure, and revert to a previous version of the schema safely. When we started Datical, we spent several hours in conversation and at white boards exploring these unique needs and hammering out a path to usher the Third Way into regular database activity.
A Rollback Designed With Every Change
The biggest problem with experimentation in the data platform is how difficult it is to move backward and forward through your schema’s version history. We feel the best way to bring more flexibility to the process of upgrading and reverting schema is an attitude shift. Your rollback strategy for each database change must become as important as the change itself. The best time to craft your rollback strategy is when the change itself is being designed. When the motivation for the change is fresh in your mind and the dependencies of the object being created, dropped or altered are clearly mapped out, a developer or DBA can better craft a rollback strategy for which every contingency has been considered. This leads to a stronger safety net and makes your application schema as agile and easily managed as your application code. The database is no longer preventing you from being bold but quickly and safely moving between versions to accommodate experimentation.
The Richness of Model Based Comparison & Remediation
I’m a native Texan, born and raised in Austin. I know the jokes about how proud and vocal Texans can be about their home state. That being said, I spend more time telling people about the model based approach Datical has applied to Database Change Management than I do telling them how wonderful it is that I was fortunate enough to be born in the best state in the country. The advantages of the model based approach really shine through when it comes to experimentation and troubleshooting. The model allows you to annotate all objects and modifications to your application’s schema with the business reason that prompted them. This detailed history is invaluable when designing new changes or refactoring your schema as part of an experimental exercise. You immediately know what objects are most crucial, what your dependencies are, what areas you need to tread lightly in, and what areas are ripe for experimentation due to the changing needs of your business. Designing intelligently eliminates risk.
Troubleshooting with models is also dramatically faster and more reliable than other methods. Programmatically comparing models allows you to determine the differences between two databases much more quickly than manually comparing diagrams or SQL scripts. You know with certainty exactly what has changed and what is missing in a fraction of the time that human review takes.
Once you have identified the differences, remediation is as simple plugging one, some or all of the determined differences into the model and deploying those changes to the non-compliant instance.
Flexible Quick Rollback
If you’ve taken our advice to implement your rollback strategy when you implement a change, recovering from disaster becomes testable, fast, and simple. Before going to production or a sensitive environment, you should always test your rollback steps in dev, test and staging. This will allow you to make any tweaks or changes to your rollback strategy before you are in a pinch. Think of it like testing your smoke alarm. Hopefully you’ll never need it, but it’s nice to know that it’ll work if you do.
Let’s say the worst happens. You deploy a new set of database changes and the application performance degrades or errors are logged. The decision is made to revert the entire installation to the previous version. Because you have carefully designed, tested and refined your rollback strategy, rolling back the database changes becomes a push button operation or a single invocation of a command line tool. No more running disparate SQL scripts or undoing changes on the fly. You can be confident that your database has been returned to the same state it was in before the upgrade.
The database has long been handled with kid gloves and for good reason. Data is a precious resource for consumers and businesses. Consumers provide data to businesses and trust that it will be kept safe and used to offer them better products and services. Businesses rely on data to strategize, grow, and become more efficient and profitable. It is the lifeblood of our economy. As our ability to collect and process data becomes greater and greater, the rate at which an enterprise must move on what is learned from that data becomes linearly faster. Data must be kept safe, but the database must become more agile to accommodate the growing pressure for faster value realization of business intelligence initiatives. DevOps patterns hold the key to this necessary agility while maintaining or improving the security and integrity of data stores. The database and DBAs need to be brought into the application design process earlier and must be treated as the first class stakeholder and commodity that they are. Companies that acknowledge this and move to adopt DevOps patterns and include their database teams will be at a distinct competitive advantage to those that don’t. Don’t miss the boat!
May. 6, 2015 11:15 AM EDT Reads: 3,216
May. 6, 2015 11:15 AM EDT Reads: 706
May. 6, 2015 11:00 AM EDT Reads: 886
May. 6, 2015 11:00 AM EDT Reads: 1,311
May. 6, 2015 11:00 AM EDT Reads: 4,433
May. 6, 2015 11:00 AM EDT Reads: 5,846
May. 6, 2015 11:00 AM EDT Reads: 3,992
May. 6, 2015 11:00 AM EDT Reads: 2,978
May. 6, 2015 10:45 AM EDT Reads: 4,467
May. 6, 2015 10:30 AM EDT Reads: 5,473
May. 6, 2015 10:30 AM EDT Reads: 663
May. 6, 2015 10:26 AM EDT Reads: 368
May. 6, 2015 10:15 AM EDT Reads: 4,557
May. 6, 2015 10:15 AM EDT Reads: 881
May. 6, 2015 10:00 AM EDT Reads: 5,635