Database Deployability – #6 Value more highly the need for change

This post was written by Matthew Skelton co-author of Team Guide to Software Operability.

Deployability is now a first-class concern for databases, and there are several technical choices (conscious and accidental) which band together to block the deployability of databases. Can we improve database deployability and enable true Continuous Delivery for our software systems? Of course we can, but first we have to see the problems.

Until recently, the way in which software components (including databases) were deployed was not a primary consideration for most teams, but the rise of automated, programmable infrastructure, and powerful practices such as Continuous Delivery, has changed that. The ability to deploy rapidly, reliably, regularly, and repeatedly is now crucial for every aspect of our software.

This is part 6 of a 7-part series on removing blockers to Database Lifecycle Management that was initially published as an article on Simple Talk (and appearing here with permission):

  1. Minimize changes in Production
  2. Reduce accidental complexity
  3. Archive, distinguish, and split data
  4. Name things transparently
  5. Source Business Intelligence from a data warehouse
  6. Value more highly the need for change
  7. Avoid Production-only tooling and config where possible

The original article is Common database deployment blockers and Continuous Delivery headaches

Optimisation for data administration

Another force working against database deployability (and related to the BI problem above) can be the desire of the DBA team to make the database as easy as possible to administer, especially if the database also has significant accidental complexity! For instance, the need to keep track of data for audit purposes is very real, and data protection and privacy regulation is increasing year by year. However, optimizing for the ease of audit at the database level by, for example, aggregating data in the same transactional database is an example of a local optimization that works against deployability. If you’re serious about making the deployability of your database a first-class concern, you might have to make some compromises.

picture3
Diagram 6.1 – All data is kept in one transitional database for easier administration

Remedy: Value more highly the need for change

To avoid optimizing for data administration within a single database or database technology, we need to move to a more distributed view of authoritative/definitive data. By that I mean that we need never lose the sense of a ‘single source of truth’ for data, but the existence of read-only copies in multiple locations isn’t seen as a problem, and we might source different kinds of data from different locations and database technologies. These changes help to reduce the size and complexity of individual databases, and reduce the perceived risk of changes in each specific case, leading to easier database deployments. Yes, there is an increased overhead in management and administration, but with careful planning on good team communications, that increase can be minimised.

picture4
Diagram 6.2 – Data is separated into different databases, there can be multiple read-only copies

 

<< 6 >>

 

Database Lifecycle ManagementRead more about Database Lifecycle Management in this eBook co-authored by Grant Fritchey and Matthew Skelton.

 

 

 

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: