DZone Research: Database DevOps Needed
DZone Research: Database DevOps Needed
The methodology provides a great opportunity for companies to find value in all of the data they’ve been collecting.
Join the DZone community and get the full member experience.Join For Free
DZone: We understand the importance of data as it continues to explode and the success of DevOps, but what’s your definition of Database DevOps?
SG: It’s a lot like “motherhood and apple pie.” All things good around data and databases. It’s an aspiration to get better with databases.
It began five years ago with our customer, United Healthcare and how they were managing changes to their internal systems. They were making 50 database changes a day with their own solution — developing, building, testing, and releasing database changes through to production. They reduced the amount of blocked work in process to zero by making frequent changes to their production environment. What I realized at that point was that all customers running applications on top of an underlying database could get the benefits that United Healthcare had seen — i.e. to implement a Database DevOps process.
So products and tools are a key element of implementing Database DevOps. However, there’s far more to a successful implementation than this. We’ve also found over the years to achieve this level of automation everything else around the tools needs to change as well — your processes, your culture, your infrastructure, and the way your teams work together.
With DevOps, the development and operations parts of the business come together to be jointly responsible for the operational performance of releases. This concept of DevOps is now well understood. But we need to do the same for data.
Unlike applications, however, you cannot delete a database and start again. Data has to persist and be morphed into the new database. A huge data store is a living thing, so we help with that by putting databases into source control — a foundational element of Database DevOps. Our SQL Toolbelt suite of products then helps customers achieve an effective Database DevOps methodology.
DZone: What do you consider to be the most important elements of a successful Database DevOps implementation?
SG: Repeatable and reliable release management is a key objective. How to make releases faster. Can I make a change and get it into people’s hands five times per day? Doing so will require infrastructure and process changes, however, a month of release testing can now be automated, taking a couple of hours instead; and this makes engineering massively more effective. There is no work in process. Value can be delivered to end users far more rapidly.
DZone: How are you addressing security with your Database DevOps methodology?
SG: No one sure how to do this yet. Regulations are about rights with the data, and companies need to be clearer about permissions. Security is a huge issue. When Ashley Madison data was compromised and released, for example, a lot of people were embarrassed.
The database is the nexus for this type of stuff. The Jennifer Lawrence breach was similarly embarrassing for Apple, but it was a function of human error. Security starts with the database in production with sound firewalls to keep the data safe. The second area is how to handle data as it comes back into engineering from production, and companies need to build an automatic catalog to know what data is private and what isn’t. They then need to ensure that everyone with access is also keeping it private.
We help people to mask private data, but still, 70-80% of people moving data to development are doing so without appropriate masking measures. Engineers need to be working with realistic data sets that behave like production, but with personally identifiable data correctly masked.
DZone: What are real-world problems being solved with Database DevOps by your company or clients?
SG: SkyScanner moved to a DevOps methodology to respond faster to customer needs. In doing so, they discovered how much of their code wasn’t valuable. So, identify the minimum viable product and get it out to end users and see if they get the value to decide whether to continue developing it. This is pivotal to engineering success. Investing at lower risk. Getting apps out quicker without massive work in process. The biggest waste is engineering activity that doesn’t benefit the customer. Get a faster return on investment.
DZone: What are the most common obstacles to the success of Database DevOps initiatives?
SG: Cultural change. Things like how do we reduce as much as possible for people to succeed? Ship and learn and have robust procedures for rolling back. Use source control properly. There are upfront costs initiating DevOps and companies must also slow down in the short term to speed up in the long term.
DZone: Do you have any concerns regarding Database DevOps?
SG: Most organizations would benefit from the methodology, but they need to tread carefully. Organizations need a sound cultural starting point, with a desire to work in a better way. If you’re not ready for change, it’s not for you. Start small and see how to make it work. At Redgate, we had to increase the contact time engineers have with customers, and engineers learned how to jump on a call with customers. Make sure teams are getting feedback quickly and directly.
DZone: What’s the future of Database DevOps from your perspective, where do the greatest opportunities lie?
SG: Data is growing fast and it’s a powerful asset. All companies will become software companies. We need to get it implemented much more widely. Fewer than 2% of companies are doing Database DevOps, yet it provides a great opportunity to release the value in the data. Start with getting good enough and then iterate and learn.
DZone: What do developers need to keep in mind with regards to a Database DevOps methodology?
SG: Don’t be scared of the database and don’t ignore it. If you can write in C++ and C sharp, you can write in SQL.
Opinions expressed by DZone contributors are their own.