staging-devopsy.kinsta.cloud

Tag: database administrators

The Impact of DevOps on Database Monitoring and Management

The rise of DevOps has broken down silos and brought database administrators (DBAs) and application developers closer together to deliver software faster and in a more agile manner. This near-constant change driven by DevOps is reflected in the results of the Redgate 2019 State of SQL Server Monitoring Report.

It reveals that 73% of organizations now deploy database changes multiple times per month, and 15% deploy multiple times per day, driven by DevOps. Yet, this is just one of the challenges DBAs face today. The research also identified the size of database estates is growing–45% said they will have more to manage over the next year, with 43% remaining the same.

Additionally, they are increasingly looking to migrate their databases to the cloud (cited as their biggest challenge by 22%) and are seeking to solve performance issues. Perhaps unsurprisingly, given these greater workloads and more frequent changes, human error is the largest cause of issues (22%), ahead of capacity problems and bad deployments.

Managing in a DevOps World

The database is now a core part of DevOps for many organizations and DBAs need to work more closely with their developer colleagues, adopting new technologies and tools to ensure business success.

This essentially involves DBAs focusing on the following distinct areas.

Standardizing Approaches Across DevOps Processes

The monitoring report highlighted human error as the biggest cause of problems for DBAs–and with larger DBA and developer teams now working on databases together, adopting standardized processes is vital to flagging issues early and preventing later problems. Otherwise, what starts as a minor issue can swiftly escalate to become a significant business crisis.

As well as standardizing processes, organizations should look at rolling out industry-standard coding tools across the entire team. This will ensure a consistent approach, not matter who is writing, reviewing or editing code. Introducing a team style for database code, rather than having the code written in many different ways, for example, will make the code base consistent and clear and minimize the confusion that lead to errors. At the same time, merging code early and often with version control tools will ensure you have a known, shared codebase on which to work, and provide a single source of truth that can always be relied on.

Automating for Speed and Consistency

Developers who have adopted DevOps already see the value automated processes such as continuous integration, continuous delivery and continuous deployment provide. Automation not only speeds up development, avoids manual errors and reduces laborious work, but also provides a full audit trail for regulatory compliance.

Extending this to the database can deliver major benefits for hard-pressed DBAs. Every time a change is committed to version control, for example, a continuous integration process can be triggered to test the change and flag up any errors in the database code. The errors can be fixed immediately and tested again, before the change is then passed along to a release management tool where it can be reviewed before being deployed to production.

Overall, automation dramatically brings down time to market, but organizations need to ensure they have the right tools and processes in place if it is to be truly effective.

Stepping Up Monitoring to Drive Continual Improvement

One of the mantras of DevOps is continual improvement, and that applies equally to database DevOps. Monitoring is a key part of this. On one level, monitoring tools highlight potentially disruptive performance issues (cited by DBAs in the research as a major challenge), enabling them to be fixed quickly.

Beyond this, they also deliver the insights and trends companies need to improve, helping them optimize operations moving forward. Thanks to a combination of DevOps and the growing importance of the database to business success, many organizations are already sharing this information. For example, 40% give developers access to their monitoring data, according to the research, which helps to enhance performance by highlighting opportunities for improvement.

Guarding Personal Data and Ensuring Regulatory Compliance

We’ve all seen the spread of data privacy regulations across the globe. Over 60% of the world’s population is likely to be covered by more stringent legislation in the near future, with California joining the EU in enforcing new regulations from January 2020. Organizations need to realize they are now data guardians, not data owners, when it comes to personal information.

At the same time, developers like to have realistic information in order to successfully create and test new code. That means organizations need to adopt tools for data masking and anonymization that can protect confidential and personal information, while still providing realistic and usable data for development and testing. This also gives a full audit trail for regulatory requirements, balancing speed and compliance.

DevOps has broken down the traditional silos between DBAs and developers and the importance of information has put the database center stage. As the latest Redgate research shows, DBA workloads are increasing, meaning they need to adopt new technology and collaborate more closely with developers if they are to successfully manage in a DevOps world.

— Matt Hilbert

August 16, 2019
Of DevOps, Databases and DBAs
If you’re on a DevOps team looking for additional efficiencies, you are likely to find them in the realm of database management. The arrival of DevOps did nothing to diminish the responsibilities traditionally associated with database administrators (DBAs). Rather, some of those duties have been redistributed across the team—sometimes explicitly, but more often implicitly. For example, site reliability engineers (SREs) and even full-stack engineers have taken on many of the responsibilities that once belonged to DBAs. And in these roles, DBAs often hold the keys to unlocking a new dimension of efficiency through consistency, repeatability and operational efficiency.

Enter the “DevOps DBA.” This confluence of roles makes a lot of sense. As with application DevOps, it’s logical to assume that the person who architected the platform and wrote the database code also should have a role in deploying and operating it. DBAs manage every aspect of data infrastructure, from capacity planning, installation, configuration, database design and migration to operational duties such as performance monitoring, security and troubleshooting, as well as backup and data recovery. As a result, the DBA’s responsibility for maintaining existing workloads sometimes conflicts with the need to plan and provision workloads for the next generation of applications. Reconciling these responsibilities can speed up the software development life cycle as a whole.

On the operational side, DBAs are responsible for monitoring database behavior under peak application workloads, ensuring they’re performing according to expectations, and working with Operations to resolve bottlenecks and outages. They manage data access and the overall security of the platform. They also perform release activities in support of the application and troubleshoot any errors that happen during that process or during day-to-day operation.

With all this in mind, we can propose a DevOps DBA checklist:
- Establish a microservices plan with regard to data services.
- Set up integration environments, and provision databases for new projects.
- Dynamically extract, transform and load data from one silo to others, employing TTL strategies to reduce the data or enrich some of it.
- Continuously monitor and optimize performance: Strive for low and consistent tail latency and a joint view of the app and the database.
- Expert zone: Automate scale out and automate schema changes.
- Backup and recovery: Backup to cold storage and restore.
- Plan for downtime and high availability using multiple data center disaster recovery capabilities.
Characteristics of a DevOps-friendly Database

We’ve looked at some of the DBA responsibilities as they apply to DevOps. Now we’ll discuss some of the technical aspects of database technologies that can help, or hinder, this hybrid role. To keep up with applications as they migrate through lifecycle stages, there are a number of organizational and team cultural challenges to be addressed. It’s also important to remember that not all databases are created equal—some databases lend themselves more readily to the DevOps toolchain than others.

It takes a combination of elements for a database to be DevOps-friendly. The ultimate goal is to minimize the fear of change by mitigating risk. Relational databases do not conform particularly well to modern software development practices, since changes to schemas can be time-consuming. NoSQL databases, in contrast, have proved to be more life cycle-friendly because they don’t impose rigid schema management during application development. Over time, however, this free-wheeling approach to data modeling can create headaches. The ideal database strikes a balance between strict schema enforcement and decentralized data-model changes.

A key consideration for a DevOps-friendly database is operational simplicity. Traditional SQL databases, such as Postgres and MySQL, are well-understood and have lots of support, but can be difficult and expensive to scale. The rise of NoSQL databases enabled larger datasets to be managed in a more flexible and scalable manner than relational databases. But even among NoSQL databases, there are some significant differences. The first generation of NoSQL databases—in particular the widely adopted Apache Cassandra—can impose significant operational burdens in their own way.

Additionally, modern cloud-native databases have their limits. They can be opaque to operators, and have been known to scale up and down unpredictably. Operators often lack visibility into the distribution of datasets. In many cases, cloud databases also prove to grow at a rate that’s disproportional to the workload supported by the database. Database instances can proliferate to the point where DevOps has to deal with “node sprawl.” You can think of this problem as the false promise of elastic scale, wherein the solution to increased traffic is, “Just add more nodes!” Lots of small nodes are not necessarily better than a few large ones. (For more on this, I’d encourage you to watch this talk on mythbusting the advantages of small nodes.) In any case, the biggest overall cost isn’t necessarily capacity, though that can be significant. The biggest cost, it turns out, is often administering all those nodes.

Node sprawl can result from an overabundance of caution; overprovisioning is a natural response to scaling challenges. Look for a database architecture that uses resources efficiently and autonomously, ideally one that can dynamically tune itself according to varying workloads. An autonomous database monitors operations and adjusts internal processors to achieve a balance. Not only does an autonomous database greatly reduce administrative burden, it also means DevOps can always push the database to the limits of the underlying hardware resources, ensuring availability and SLA compliance. This again reduces the need to tailor database configurations and topologies to specific applications.

Flexible deployment options are also important for DevOps. Who knows what your footprint will look like in 12 or 18 months? A database needs to be fairly agnostic as to topology on which it is deployed, whether that’s on-premises, a cloud platform or a hybrid configuration across both local and cloud environments. In some deployments, databases may be required to run across two different commercial cloud platforms—for example Azure and AWS—simultaneously. There are a couple of reasons for considering this: The first and more obvious is to maximize availability. Geographical outages are more common than you might expect. The second benefit are the financial advantages to the business using the hybrid framework, as it prevents infrastructure-as-a-service (IaaS) vendor lock-in, while also providing tax benefits for the on-premises expenses. Forward-thinking DevOps groups will keep these potential requirements in mind when designing data platforms today.

Conclusion

Trends in application development and IT infrastructure are pushing traditional DBAs into DevOps, while DevOps (including SREs and full-stack engineers) are often taking on responsibilities traditionally associated with the DBA. By adopting data infrastructure that emphasizes operational simplicity, ease of scale and deployment flexibility, IT organizations can more easily reconcile these roles while building a cloud-friendly infrastructure that extends the DevOps toolchain to the database.

— Eyal Gutkind
April 11, 2018
Datical Helps Pull DBAs into Modern DevOps Age

As organizations move to embrace DevOps, some have inadvertently left database administrators (DBAs) behind. As a result, developers increasingly find themselves managing databases, as DBAs can’t keep up with the rate of change introduced by DevOps processes. To help narrow that growing gap between developers and DBAs, Datical created a namesake platform that applies continuous deployment/continuous integration (CI/CD) processes the management of databases.

An update to the Datical platform now adds real-time views and dashboards that illustrate the status of database deployments. DevOps teams now can simulate the impact of changes before they are deployed in a production environment and enforce rules to meet audit and compliance requirements. A new management tool also makes it easy to track database changes across the pipeline as well.

Pete Pickerill, vice president of product strategy for Datical, said Datical 5 now makes it possible to automatically apply the updated changes to a database without many of the steps that slow down application development on top of databases.

Finally, with this release, Dacital also provides a mechanism for centrally managing all the credentials attached to database.

While agile development methodologies have lead to an increase in the rate at which code is being written, database management continues to act as a drag on the rate at which applications are being deployed and updated. Datical decided to address that problem by creating a platform that specifically applies DevOps processes to the management of databases, said Pickerill.

Organizations that still rely largely on manual database processes often find the level of tension between developers and database administrators to be high. Developers often will simply opt for a database they can manage themselves rather than engage a DBA. That can result in suboptimal choices being made for different classes of application workloads that become apparent once the application starts to scale. The challenge and opportunity is to put tools in the hands of DBAs that enable them to respond rapidly to changing application dynamics, said Pickerill.

Of course, in many instances developers have simply taken over the database administration task. But every minute spent on those tasks is one less minute a developer is writing code. The more efficient option is to find a way to integrate DBAs into the overall DevOps process. The effort requires both providing DBAs with access to new tools as well as changing an IT culture where many DBAs assumed the application development strategy revolved around their ability to find time to manage a database. Today, DBAs are now being asked to manage a multitude of types of databases that are being deployed in unprecedented numbers. Clearly, processes rooted in approaches to database management developed a decade ago or longer no longer suffice.

Not every DBA will make that transition. But at this juncture it’s clear that fundamental change to the way databases are managed is now a matter of when rather than if.

— Mike Vizard

March 12, 2018
Evolving Data Requirements in Multi-Cloud Environments
By design or by accident, multi-cloud is a reality that most enterprise IT teams have to cope with today. Multi-cloud (or, cross-cloud, as Dell EMC calls it) refers to an IT model where an organization uses services of one or more public cloud service providers, sometimes in addition to using its own data centers. In a multi-cloud model, different clouds may be used in different stages of the application life cycle such as test/dev and production, and for different types of applications such as traditional structured applications and next-gen cloud applications. Nonetheless, IT leaders face challenges in identifying data management tools they need to embrace the multi-cloud environment to improve application agility, reduce operational hassles and enhance application resilience. In this blog, I will discuss how enterprises are using a multi-cloud model and the requirements it places on next-generation data protection products.

One common reason for multi-cloud is to support geo-replicated applications to enable global reach of e-commerce organizations. In such a scenario, a production database may reside on a private cloud behind an enterprise firewall and replicated to multiple regions in a public cloud to service reads (i.e. consumers are shopping on these e-commerce sites) from different regions at low latency. Such a configuration also protects against disasters at the data center level because the database and application are replicated to public cloud (with multiple availability zones).

Another use case is to service the requirements of production environment versus test and development environments using different clouds. While security, control and performance optimization may mandate a production environment to stay within a private data center, agility, access to new capabilities such as Google BigQuery and developer preferences may drive application development teams to use a public cloud service providers.

Finally, using a multi-cloud model could also be driven by the IT strategy of an enterprise to prevent overdependence (or, vendor lock-in) on any one public cloud service provider. To hedge the risks and get leverage, an enterprise may balance its application workloads across multiple cloud providers—for example, deploy Tier-1 applications on one cloud and Tier-2 applications on another. It is a real phenomenon we are seeing with enterprise customers! However, a multi-cloud model presents the following unique challenges to enterprises.
- Data protection in multi-cloud environment: Legacy data protection (backup and recovery, archiving, replication) products were architected for on-premises environments and optimized to work with legacy applications. Using legacy backup and recovery tools for next-generation applications in a public cloud environment is equivalent to fitting a round peg in a square hole. For one, legacy products don’t leverage the elastic and scalable compute and storage that is available in public cloud. True infrastructure-independent (software-only and elastic compute-based) data protection products that may be deployed in heterogenous environments are required as enterprises look to migrate applications to the cloud.
- DevOps agility: Moving data across clouds for disaster recovery or to refresh test & development environments with production data is another key requirement for enterprises. Doing so in a multi-cloud environment is not an easy task given the challenges in moving data over the WAN. There are also differences in configuration between test/dev and production environments. Further, the test/dev environments may not be as large as production environment so sub-sampling is required. Finally, personally identifiable data needs to be masked before it leaves the production firewall.
- Ease of management and governance: Finally, federated management is required for applications and workloads running across multiple clouds. It is extremely inefficient to get familiar with different management tools and their intricacies.
This is by no means a complete list. There are several other requirements, such as support for cloud storage with consistent performance, handling of identity access and management processes and so on. The point is that data protection needs to be re-thought in the context of multi-cloud environments.

— Shalabh Goyal
December 19, 2016
Shouldn’t DBAs Be Part of the DevOps Inner Circle?

DevOps is changing the culture of IT. This movement is bringing application development and operations teams to the same table and the same time, working to understand and overcome the challenges facing the entire application delivery process—not just their piece. Development and operations teams are forging new bonds and alliances in the spirit of accelerating software release cycles.

However, while quickness to market is paramount to success, businesses can’t forget about the internal implications of accelerated release cycles. With that in mind, there is one conspicuously empty seat within the “DevOps Inner Circle,” and that’s the database administrator’s (DBA).

DBAs hold the keys to one of businesses’ most important assets: the database. But database change innovation has not kept pace with agile development methodologies and DevOps tooling that enable continuous delivery of software updates and changes. The vast majority of enterprises are still updating databases the same way they have been for the better part of the last three decades: through manual script review, validation, execution and individual heroics. As a result, application release cycles ultimately slow down at the last mile—the database.

It’s time for a better approach. It’s time databases and their stewards, DBAs, be part of the DevOps Inner Circle. Including DBAs can create better, more efficient teams; save time and money; and even help companies create better solutions for their customers’ needs or their own.

Shattering Silos

One of the founding principles behind DevOps is the breakdown of silos between development and operations teams. Product managers can easily translate customer needs and communicate that feedback to developers in a way they understand—using epics and themes, for example. This helps bring everyone on the same page so that application updates or changes can be quickly coded, tested and delivered. But before application updates can be released to users safely and effectively, they have to be translated into the changes that will update the database. This is where the DevOps breakdown occurs. DBAs often have to rely on manually intensive, timeworn, error-prone processes and tools to make sure the right changes are made to the database.

By inviting DBAs into the DevOps Inner Circle, database updates that go against business policy and will ultimately lock the database or “break the build” (think inserting a new column with a default value when the row count exceeds a million) can be found faster and addressed by the development team well before that change reaches the database. Having DBAs involved in release cycles sooner can help ensure developers are coding with corporate compliance in mind, ultimately making changes to the database smoother while adhering to guidelines that DBAs have typically policed.

There was a time when databases needed protection from changes made by creative problem-solving in development, but DBAs simply cannot stand against the deluge of changes necessitated by accelerated cycles. Inviting DBAs into the DevOps Inner Circle enables teams to consider the implications of new changes and updates across the entire technology stack. Breaking down silos and making teams more aware of catchpoints in the last mile of the release process lets them anticipate and avoid database issues—which means faster releases and fewer headaches for everyone.

Saving Time (and Time is Money)

Faster release cycles are good for business, and not just because they get applications in front of end users sooner. Continuous delivery cycles are designed to cut costs associated with application development considerably by saving man-hours. Still, while development timelines keep getting shorter, the workload and time to deploy database changes gets longer.

Enterprises can have multiple database configurations, so each change needs to be checked for compatibility. As the complexity of data repositories grows, so too does the time it takes to review and approve changes. In a 2015 IOUG survey on database manageability, 41 percent of respondents said changes took a week or more to approve. With multiple change requests coming to DBAs each month, each week or maybe even daily, it’s clear that sheer manpower can’t keep up with continuous delivery forever. Relief for DBAs is nonexistent without automation.

Remember our earlier example, where we ran the risk of locking the database by inserting a new column with a default value when the row count exceeded a million? Database automation software protects against outcomes like this by forecasting the impact application changes will have on the database. DBAs can use forecast reports generated by automation software to pinpoint any issues without expensive hours or days of searching.

As part of a DevOps team, the DBA equipped with automation can do more than save time and headaches for themselves. Protecting against errors that could break the build saves teams from spending time to find and fix the source of a breakdown, and also saves a business from losing revenue while the fix is made. If so much time, money and potential frustration ride on DBAs’ ability to implement changes at the speed of continuous delivery, why are they still on the outside of the DevOps Inner Circle?

Freeing Up Time for Innovation

Flashes of inspiration rarely come about when you’re just trying to keep your head above water, and for so many DBAs, that’s the reality of work. Today, enterprises fight a war of attrition with the database, throwing manpower at the final hurdle of the release cycle. In addition to the attractive benefit of saving money on man-hours, bringing DBAs into the DevOps inner circle and automating some of their tasks also creates time and space for innovation.

The relational database is nearly a 50-year-old innovation, one that changed the way people and computers interface through data. After so much time, and with so much on the horizon, the next innovation seems imminent or perhaps even overdue. The advent of quantum computing may bring with it a fundamental change to the way databases interact with one another. It’s certain to bring a shift in the way data is stored and retrieved, though at this point experts expect only the most complex business processes will benefit from quantum computing. So, while future tech remains out of reach, DBAs will be vital in the effort to innovate faster, more streamlined ways for dealing with zeros and ones.

The first step to innovation, then, is addressing the needs of DBAs alongside those of customers and developers. Breaking down walls and increasing efficiencies between existing DevOps teams and DBAs will give teams more opportunity to create novel solutions to both their users’ problems and their own. Add another seat to the Inner Circle, save time and money, get quality applications to market even faster, and create innovative solutions to the problems of today and tomorrow.

About the Author

Derek Hutson joined Datical as CEO in 2015, bringing more than 15 years of leadership experience in enterprise software. Before joining Datical, he led multiple companies through extended periods of rapid growth and also held several executive roles at IBM. There he served on the leadership team for IBM’s acquisition of Telelogic, and was responsible for due diligence and integration of the acquired sales functions globally. He currently serves on the board of Hart InterCivic and Charity Dynamics. Other board or advisor positions have included CoreTrace (acquired by Lumension), Innography, StreamStep (acquired by BMC) and Phurnace (acquired by BMC).

February 17, 2016