Skip to main content
Top

2016 | Book

DevOps, DBAs, and DBaaS

Managing Data Platforms to Support Continuous Integration

insite
SEARCH

About this book

Learn how DBAs in a DevOps environment manage data platforms and change requests to support and optimize continuous integration, delivery, testing, and deployment in the application development life cycle. On the Dev side, DBAs evaluate change requests to ensure compliance with organizational best practices and guard against degradation of database performance and the validity of dependent objects. On the Ops side, DBAs perform release and troubleshooting activities in support of the application, manage the data platform’s access and security, and monitor and maintain performance of the databases that they have designed and provisioned.

DevOps, DBAs, and DBaaS investigates the complex intersection between DBA functions and DevOps processes. DevOps teams traditionally viewed DBAs as process outliers who disrupt and retard SDLC timelines. At each touch point, veteran DBA Mike Cuppett shows how DBAs can most effectively contribute to decreasing release cycle times and improving product resiliency by applying automation, orchestration, and DBaaS solutions to database administration in ways that dovetail with DevOps requirements and metrics.

At a high level, Cuppett demonstrates the importance of leveling silo walls in the IT supply chain and of measuring application performance holistically by reference to satisfaction of customer requirements and end-user experience. At a technical level, he drills into topics and case studies on diagnosing and resolving problems commonly encountered by DBAs and DevOps teams when meshing database management with application delivery.

What You Will LearnTechniques and best practices at all points of collaboration between DBAs and DevOps teams in product development

Tools for measuring DBA inputs to DevOps processes by holistic criteria of end-user experience and business requirement

How to integrate open source database technologies with DevOps

When to decouple application and database layers and move to DBaaS models

How to overcome language and mindset barriers between DBAs and DevOps teams

Who This Book Is For

DBAs who are leaning toward or already involved with DevOps and DevOps engineers, team leaders, developers and product managers who are already working with DBAs or planning to integrate DBAs in DevOps teams. The secondary readership is executives and managers in companies that practice DevOps.

Table of Contents

Frontmatter
Chapter 1. DevOps for DBAs
Abstract
Organizational demand for agility—adapting the business to meet customer demands and speed—and fulfilling customer demands expediently with an earlier return on investment (ROI) realization continually drive the expanding and maturing cultural paradigm of DevOps. These business-mandated edicts have forced information technology teams, including database administrators (DBAs), to incorporate rapid development, continuous integration, automated testing, and release management. Combined with immediate feedback loops, the result is a shift from monolithic applications to object- or services-defined applications.
Michael S. Cuppett
Chapter 2. DBAs for DevOps
Abstract
Experienced DevOps professionals have the responsibility to assimilate new people into the movement. DBAs coming on board need to understand (and possibly be convinced) that DevOps is about improving and quickening a continuous flow of software or web service improvements designed to provide a richer customer experience, abounding with excellent performance and extreme availability. DBAs need to change many habits to blend traditional work into the DevOps model.
Michael S. Cuppett
Chapter 3. Integrating DBA and DevOps Processes
Abstract
Shifting the culture and aligning team members mark progress toward shortening the virtual to-do list for bringing DBAs into the DevOps fold. Early stage buy-in for DBAs and existing DevOps staff may not be a full commitment, and constructing the process integration methodology becomes key to completing the transformation to the desired future state. Months, even years, of planning, investing, growing, battling, losing, and winning committed to Agile development now comes face to face with the biggest threat: more people and more work. Expanding to include the delivery of database changes into and through the pipeline introduces risk, risk creates anxiety, and anxiety causes apprehensiveness, which may lead to aloofness. However, seasoned Agile developers have learned from an agile prime directive—change is welcomed.
Michael S. Cuppett
Chapter 4. Integrating Database Technologies and DevOps Tools
Abstract
Database technology integration simply involves injecting database automation and database infrastructure as code into the continuous delivery pipeline. The challenge is “where,” “when,” and “how.” Database tool selection criteria must balance database change capability and integration ease with tools already used in pipeline management.
Michael S. Cuppett
Chapter 5. Stateful Data, Stateless Database Schema, and Code
Abstract
Stateful and stateless programming can be defined as software code that maintains a state or data element, or sees each interaction without previous context. Stateful programming is the dominate sibling because any time a variable is set (i=1), a data element is captured (for example, capturing customer order information on an e-commerce site), a variable in a loop is incremented, or an array is used, a state is present. In and of itself, stateful is not a problem because state is needed for many transactional interactions. DevOps does not mandate that all code must become stateless, but there are times when stateless brings opportunity.
Michael S. Cuppett
Chapter 6. Optimizing Application Performance with Change Management Improvements
Abstract
Yes, the chapter title sounds intriguing—incomprehensible, but intriguing just the same. Application performance and change management seem to fit together like oil and water. For IT folks, the first thing that comes to mind when hearing change management is the ITIL ITSM process designed to minimize risks when changes are made to the production application environment. (Actually, what comes to mind before rational thought kicks in cannot be included here.) The change management process involves designing the change, testing the change, determining what impacts could occur, determining how the change can be backed out if it fails, testing the back-out, and then explaining the change and getting approval from the CAB to execute the change. A week has likely passed at this point, only to arrive at the place where the change is scheduled to occur. Change management must be accelerated to fit the DevOps methodology while keeping risk minimized. The DevOps approach requires extensive testing and the mandate to stop defects from progressing; the process is similar to workers on the manufacturing floor having the power to stop the line when problems occur that could impact safety or quality.
Michael S. Cuppett
Chapter 7. Measuring DBA Inputs to End-User Experience and Business Value
Abstract
People want to be recognized for work well done; it is just human nature. The challenge for IT folks is being able to quantify how application, infrastructure, and operational changes improve the business by making customers happier, leaning processes, or contributing to revenue increases or cost decreases. Cumulative degradation mathematically reveals what IT leaders have struggled against when defining metrics to prove IT’s value to the business (refer to Table 1-1 in Chapter 1). Imagine the CIO sharing uptime metrics with other CXOs, knowing that the CXOs are hearing daily from their teams that the application systems are unstable and slow. A CIO stating 99.9% uptime undoubtedly receives flak from the other chiefs. Uptime, which means that the computer is running and the application works, is much different from a measure showing productive use of the application to meet business and consumer demands.
Michael S. Cuppett
Chapter 8. Automation and Code Control
Abstract
DevOps is drawing a line in the sand: it is taking a stand for software product delivery excellence. As agile teams produce less-defective code more quickly, DevOps teams need to solidify the infrastructure foundation supporting the application. Both pieces are required to deliver software superbly and (more importantly) gain customer confidence in an organization's capability to operate well.
Michael S. Cuppett
Chapter 9. DBaaS, IaaS, and PaaS
Abstract
Proper orientation, or level-setting ourselves, allows us to leverage the knowledge foundation we already have to gain additional knowledge. Software as a Service (SaaS) is an acknowledged winner in the “as a Service” product realm, so let’s start there before engaging with our chapter title offerings.
Michael S. Cuppett
Chapter 10. Overcoming Language and Cultural Barriers Between DBAs and DevOps
Abstract
The collaborative foundation of DevOps decrees positive and well-intentioned communications. Defining rules of engagement that satisfy this expectation equips each team member for success. Knowing that communication underlies and perpetuates all aspects of DevOps encourages team members toward effective communications.
Michael S. Cuppett
Backmatter
Metadata
Title
DevOps, DBAs, and DBaaS
Author
Michael S. Cuppett
Copyright Year
2016
Publisher
Apress
Electronic ISBN
978-1-4842-2208-9
Print ISBN
978-1-4842-2207-2
DOI
https://doi.org/10.1007/978-1-4842-2208-9

Premium Partner