Most Read This Week
The DevOps Database | Part 4
A culture of continual experimentation and learning
By: Pete Pickerill
Mar. 26, 2014 12:00 PM
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 Richness of Model Based Comparison & Remediation
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
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.
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads