Datical Revs its Database Release Automation To Further Help Accelerate DevOps Results

Many diligent DevOps adopters still openly wonder why they aren’t yet seeing the lightening-fast results they expected. One answer may rest in the fact that their app code pipeline is just way faster than their database code pipeline. IDN looks at Datical’s updated database release automation software with company execs.

by Vance McCarthy

Tags: Tags: agile, appdev, database release automation, Datical, DevOps, source code control,

Robert Reeves, Datical
Robert Reeves
co-founder and CTO
Datical


"The application isn't ready to ship until the 'lowercase' application code is production-ready, and then the database code is production-ready."

Application Architecture Summit
Modern Application Development for Digital Business Success
Online Conference

For all the focus enterprises are placing on accelerating app releases with DevOps, many openly wonder why they still aren’t seeing the lightening-fast results they expected. 

One answer might be simply that while their app pipeline is speedier, their ability to accelerate database schema just hasn’t keep pace.  

This problem is the focus of Datical and its database release automation software. The latest version, Datical 5, looks to tackle head-on this ability to accelerate and automate database releases, and thereby speed up the whole app delivery process, according to Robert Reeves, Datical co-founder and CTO.

 

“Tell me how fast you're getting your database code production ready and I’ll tell you when your app really goes live. It’s not just when the app code is ready,” Reeves told IDN. “The application isn't ready to ship until the 'lowercase' application code is production-ready, and then the database code is production-ready.”

 

Bringing more attention to the database release process, Reeves added, will remove one of the last, nagging roadblocks to achieving faster app delivery using DevOps and agile practices.

 

Datical calls the mis-matched pacing between app and the database releases the ‘Velocity Gap.’  A look at the issues reveals some hard truths about how well – or not – app and data professionals are on the same page.

 

To explore this ‘Velocity Gap’ Datical asked questions such as:

  • How long does it take to release a new or updated app?
  • How fast are you getting your database code out?
  • How many times do you have to rework a database change in order to get it production-ready?

“When we talk about the ‘Velocity Gap’ in this way with customers, they realize they essentially have two very disparate disconnected pipelines for each one of those code types,” Datical vice president of marketing Ben Geller told IDN.  He explained it this way:

The application code pipeline is automated and goes really fast, and they can measure how long it takes to deploy new code– usually hours or a day or two. And the database code pipeline isn’t as fast – deployments can several days or even weeks. This is because the DBA needs to review the change script and it’s likely going to need re-work because there’s something wrong. And this can happen two or three times.

It's (Really) Different This Time – Managing Databases in the DevOps Era

Database Release Velocity - Datical

While it’s true that managing database changes have been going on for decades, in today’s world of speed and speed and more speed -- it’s just different now for several reasons, Reeves said. 

 

“We no longer live in a world where you're doing one, maybe two, releases a year. You're releasing weekly, daily even multiple times a day. So, one big difference is that there's just there's more [database schema] updates. And they’re happening more often,” he added.

 

A case in point, Reeves shared this experience from a DBA who was dealing with huge database schema update headaches. 

 

A major console game manufacturer was facing app updates that were happening way too slow.  Upon working with Datical, it was uncovered that much of the delay could be traced to the huge Oracle RAC installation (with terabytes of data) it was running. It was just taking far too long to update the database schema every time they updated an application.

 

“This customer told us, ‘We have got a real problem here. We cannot rely on our DBAs to vet every single change to this database schema. We're moving too slow. We got to speed this up. We got to automate this whole thing - if we don't, we’re going to go out of business.’”

 

Looking deeper, Datical found the customer’s database schema issue actually triggered two problems:

 

First, the customer had such a huge database, it often would take days for DBA teams to verify database changes had authored correctly. “The problem is time. It’s not the size of the database, per se. It's about the time to update that schema. It just takes too long to request a DBA to review, verify and deploy a change,” Reeves explained.  

 

Second, the company was enjoying such massive growth it had outgrown its on-prem infrastructure and operations, and so needed to move to the cloud. Unfortunately, the cloud provider the company chose was not able to handle the size of their databases. That meant they’d need to shard them – which in turn meant even more databases, Reeves added.  

 

“We often find customers are doing all the DevOps step right for application code. They just need a way to bring DevOps speed to the database and automate database schema updates,” Geller noted. 

 

In fact, having both pieces of acceleration in place—one for the app, the other for the database schema -- has been a best practice for some of today’s most innovative and disruptive companies for years.

 

Agile Apps with DevOps Also Need Data Automation – Ask Amazon

“For the biggest companies, moving fast [with their apps] isn’t a problem. This is mostly because they have adopted [database schema] automation and de-centralized data management” to go right alongside agile and DevOps practices for apps, Reeves said. “You think an Amazon developer has to fill out a ticket to get a database schema updated? No they’re able to do it themselves.”   

 

True, but not every company is Amazon. And that’s exactly the point at Datical – how to bundle up tools, technologies and best practices to make it easier to adopt Amazon-caliber results.

 

“How can big companies in banking and health care do this? With all their regulatory constraints and all their legacy data, they're having a tough time getting their head wrapped around [how best to move faster with their data]. That’s where we focus,” Reeves  said.

 

Datical 5 speeds software deployment by providing a central command center that works with other developer tools to unify pipeline automation for application and database changes, freeing up time for development, test and database administration teams to create and deliver better application experiences — faster. For the first time ever, developers are now empowered to continuously manage and rework database code changes, allowing for seamless and efficient collaboration across the DevOps pipeline.

 

A Deeper Look at Datical 5 – Filling the Velocity Gap between App, Data Pipelines

In its latest release, Datical (with its database release automation software and best practices) continues to focus on filling in this Velocity Gap – and help companies better align their app and data pipelines. In specific, Datical 5 adds several key features to bring automation and visibility to the task of database schema updates.

 

Among them are two “killer features” which Reeves said are laser-focused on helping DBAs get comfortable with automation:

Datical forecast functionality, which shows users what Datical is about to change, but doesn’t enact the changes until they work as intended and comply with a company’s governance standards. In specific, it assesses the impact of proposed database changes with an in-memory model before the changes are actually deployed to any target database. The key is to provide visibility to teams and eliminates risk and ensure consistently successful, safe database deployments.

 

Datical rules engine, which automatically enforces DBS rules across all proposed database changes and provides application developers with instant feedback on their database code.

Among other notable updates in Datical 5 are:

  • Ways to rollout database schema updates throughout an entire organization, not simply within a local department. 
  • Introduction of a microservices based architecture, so Datical can run anywhere, and not be required to run on a local workstation or node. “We’re also using containers and  Kubernetes, so it can go wherever you want it to go – bare metal, VM, private cloud, public cloud.
  • Easier UI access. Users now only need a web browser to interact with Datical and check SQL scripts into source code control.
  • Added support for Microsoft’s SSIS ETL solution. It can version SSIS packages and orchestrate when SSIS jobs are performed alongside schema changes. This lets organizations better manage database releases and simultaneously coordinate ETL workloads to ensure that no data is lost.
  • Updated plug-ins for XebiaLabs’s XL Deploy and IBM’s UrbanCode Deploy to let teams immediately bring their database into view as they orchestrate software releases.

Beyond all the technology and best practices, Datical also knows that DBA habits are hard to break – especially when it comes to the painstaking tasks of updating business-critical databases.

 

So, Reeves accepts that education is also part of Datical’s approach to problem-solving. 

 

“We’ve had DBAs that are really skeptical,” he said, and shared another example.

 

In one case, Datical worked with a DBA team at a major bank. This group had for years held multiple 8-hour calls with remote team members when it came time to deploy changes to databases across their 3 data centers. They had to manually execute scripts and each data center had to be done in series, one at a time. “That is a real pain. I know, I used to be part of those calls,” before starting Datical, Reeves said.

The first time this team used Datical was a surprise. After they hit the deploy button, Datical indicated the job was done. Rather than be happy, their response was more troubled, Reeves recalled “Oh God,” they said. “It didn’t work. It was too fast.”  

 

So, to be sure the job was done, the team spent an hour dissecting what Datical did -- verifying that Datical actually completed each operation.  “They found out we actually had made all the changes,” Reeves said.

 

The team worked this way three or four more times – each with perfect results – until  the DBA team agreed Datical could be relied upon without so much handholding or checking.

 

In fact, the bank implemented a new policy. DBAs would no longer have to be on all night calls.  In fact, first tier support was no longer up to the DBAs, but moved to the release managers. DBAs would now be third tier, and on standby in case something went wrong.

 

Explaining this new tiering structure for business-critical data, Reeves told IDN it was simple.  “The DBA just said that the team using Datical just didn’t need us there every time any more.”

 




back