As the CTO and Co-Founder of DBmaestro, I have spent the last few years raising awareness about how to achieve agile development, continuous delivery and integration for the database, also known as DevOps for the database.
After countless conversations with thought leaders, CIOs and CTOs, I have concluded that preserving database security is the primary reason organizations do not adopt DevOps for the database. If database security played a more prominent role in DevOps, larger organizations, especially those who handle sensitive data, would be more open to adopting agile and continuous practices for the database.
So, I set out to help organizations achieve their goal of speedy releases while managing risk. I found that DevSecOps solves this problem. DevSecOps allows for application development processes to be sped up, tested, and released in a controlled and organized manner.
The Need For Speed
The challenge of DevSecOps for the database is increasing speed and efficiency without losing control. How can organizations move fast and stay safe at the same time? As an avid mountain biker, I understand that challenge. I like going fast. But risk needs to be taken into account.
There is an obvious reason for this need for speed. Customers have no patience. In the old days of waterfall methodology, thoroughly tested enterprise solutions would be rolled out once or twice a year. But now, with the adoption of agile and continuous processes, everybody is running. Expectations are high. Attentions spans are short.
The enterprises that continue to succeed in the age of DevSecOps have learned to successfully release glitch free applications quickly and efficiently. This is done with automation. However, the database was being left behind, as most work still needed to be done manually. Database administrators found themselves with the impossible task of keeping up with continuous processes using manual implementation.
Is Database Automation Safe?
The problem they faced was that that automating database processes was not like automating code. The database is not a collection of files on a file system. Unlike code, the database cannot be copied. This is what contributes to inconsistencies between environments such as configuration drifts and out of process changes. Code developers are encouraged to fail fast and fail often. If database developers adopt that philosophy for the database, organizations will pay a hefty price.
Because of these risks, the DBA team has become a bottleneck. Before DevSecOps for the database, development teams became frustrated, as they wanted to be more agile and self-sufficient. DBAs, responsible for the health and continuous operation of the database, needed to be careful when evaluating and managing the risks of changes, which takes time.
When an organization applies DevSecOps for the database, both the development teams and the DBAs share the responsibility of safekeeping the precious data in database. By working together, they can set ground rules, process controls and even create repeatable processes. The teamwork demanded by DevSecOps helps organizations safely overcome the challenges of automating database development and deployment to keep up with the increasingly fast application release times.
DevSecOps In Action
DevSecOps for the database creates conditions for database scripts to safely be released. This means preparing for configuration drifts, out of process changes, and adhering to regulation compliance and auditing demands. This will allow for safe and rapid releases in a structured environment.
First, the teams need to comply with policy rules and understand the roles of each member. Second, setting rules to prevent changes not in accordance with organizational policy is paramount. Then, auditing allowed changes during the execution of the upgrade will add another line of defense to prevent code errors and database downtime. In other words, the focus here is on impact analysis and not damage control.
Enabling rollback during this stage is imperative for safe database changes. To achieve a safe, fast, and reliable process, these steps need to be executed to perfection. After this process, understanding who did what change when, where, and why, is crucial to examining if this process is worth repeating (or automating), or if the DevSecOps teams need to return to the planning stage.
Don’t Leave The Database Behind
It is not just about dealing with the database, but dealing with the entire applications. The same safety net that is built for code releases can be applied to the database with the right continuous delivery pipeline in place. One of the biggest concerns for organizations dealing with sensitive information – especially in the finance sector – is costly downtime. It can cost both millions of dollars and take years to rebuild a reputation.
Organizations that understandably want to stay away from automation to avoid these risks will fall by the wayside because they do not meet customer demands. Financial organizations need to understand that there is a viable and safe solution to automate their database releases, and the ROI will be well worth their efforts.
