The DBA and DevOps - Orchestration and Monitoring

Orchestration may include a single or number of tools to assist in automating, coordinating and scheduling the DevOps “symphony.”

Ever attend a symphony and be amazed at the sheer glory of the collaboration between string, woodwinds, brass, and percussion? The way each of the instruments are individually identifiable, yet work seamlessly together and come into the piece at the appropriate times? This is orchestration and the pivotal goal of any orchestra.

Orchestration in DevOps is essentially the same concept. Although often confused with automation, orchestration should be treated separately from automation because it encompasses not just simple or lower-level tasks, but with control of single or multi-step component automation tasks.

As an orchestra carefully coordinates and schedules each group to perform their part optimally, in DevOps we do the same by streamlining processes between groups, tiers, and environments.

Orchestration may include a single or number of tools to assist in automating, coordinating and scheduling the DevOps “symphony”. Where Chef, Puppet and Ansible are recognized names to automate processes, the orchestration of the releases between different groups may also include tools like Automic or builds may be created with Maven or Packer.

Understanding that orchestration is a sum of many parts is essential to knowing how important the DBA is to process, build and automation. We’ve done so much manually and have been the gatekeeper for so long for the business’ valuable data. Now we can ensure that our experience is utilized in creating an agile environment that is robust, secure and encompasses everything that touches the database because so often, the database is central to everything.

Once orchestration has been decided on and begins to take shape, you need a process to monitor what is happening when and to alert when a step fails. Monitoring can be a suite of scripts that report the health and status of processes and orchestration, notifying if there is any failure. This choice normally has a scaling limit and at some point, a more robust solution is required or gaps are felt in the monitoring process or failure at certain tiers. More enterprise solutions, such as operational intelligence, such as logging suites like Splunk and Sumo Logic.

DBAs understand the power of monitoring and depend on their own suite of monitoring scripts and infrastructure monitoring tools like Enterprise Manager, Solarwinds or SelectStar. This is just taking monitoring a step forward and incorporating the full development to deployment cycle into monitoring. The production DBA was often responsible for failures in releases and if this care of release management is broadened to DevOps, these failures are lessened. This goal should resonate in value with any database administrator.

The DBA, finding their bearings and realizing their value, should also be willing to set boundaries to secure, reliable release mechanisms without impacting the ability for DevOps groups to be productive. Operations will be readily available to offer support for security and uptime initiatives while realizing that the business deadlines for shorter development cycles have precedence. With this shift from finding our place to maturation, the DBA takes on the next level of DevOps - security and efficiency.