While both of these excellent offerings compete to bring the best product to market, the real winners here are all of us. True market dynamics are at play resulting in both GitLab and GitHub lowering prices and adding more features (and not just GitHub and GitLab but also their competitors, including Atlassian among others).
I had a chance to sit down with Sid Sijbrandij to discuss GitHub’s move, what GitLab will do and what this means for the market. (BTW, I have to apologize to Sid—it seems I have been mispronouncing his name for years and he is too much of a gentleman to correct me. The proper pronunciation of his name is “See Brandy.”) The video of our conversation appears below, and a blog on the GitLab site explains it all.
In our interview, Sid was very clear that GitLab owes a huge amount of gratitude to GitHub, as it was GitHub that spurred on the early development of GitLab. He truly respects what GitHub has done, as well as the great job Microsoft has done since acquiring GitHub.
The GitLab blog post lays out very clearly what the GitHub offering is and how it compares to the GitLab offering. It’s no coincidence that the new GitHub paid teams offering is the same price as the GitLab bronze offering.
Price aside, according to Sid, the real advantage of GitLab is that its vision of an end-to-end total DevOps solution and the features it adds to achieve this vision give GitLab customers more than they can get from GitHub. While I agree that is true today, I don’t think GitHub is going to be content with its current lineup for long. I think the Microsoft entity already envisions a total DevOps solution as being part of GitHub’s future.
On top of that, I think GitHub and Microsoft are already thinking of how they can leverage Azure to give GitHub an advantage. To Microsoft’s credit, though, at least until now there has not been any special advantage of using GitHub with Azure. Azure remains an open platform that all vendors seem to get fair access to and support from.
All of this aside though, we are all the real winners here. What a great time to be a developer/DevOps professional. While GitLab and GitHub compete with each other to bring more features to market for less money, as I mentioned other companies are competing to bring end-to-end DevOps solutions to market as well. We benefit from all of this competition by getting better tools and solutions at better prices. That’s true market dynamics at work.
It should get only better in the months and years ahead as well. In spite of COVID19 and the rest, it is a great time to be alive.
Copado, a provider of a DevOps platform building and deploying applications on top of Salesforce software-as-a-service (SaaS) applications, will make its platform available for free to anyone working on applications to help combat the COVID-19 pandemic.
In addition, Copado has launched a virtual DevOps training center and opened its DevOps community to anyone in the Salesforce ecosystem by making DevOps certifications available for free for 90 days to anyone who can pass an online examination. Previously, Copado charged $250 per certification.
Andrew Leigh, senior vice president for marketing and alliances for Copado, said the goal of the Copado Cares program is to train more than 10,000 individuals how to implement best DevOps practices on Salesforce platforms this year.
In terms of providing free access to its platform for building applications, Leigh said Copado is following the lead of Salesforce, which has launched its own Salesforce Cares initiative that provides free access to select cloud applications.
Leigh said that Salesforce applications will prove more relevant in the weeks and months ahead as fledgling digital business initiatives that organizations have launched rapidly become the foundation on which business continuity plans are now based. With more individuals working from home, many businesses need to deploy additional digital marketing and customer support applications rapidly, he noted.
The only way to achieve that goal is to embrace low-code development tools such as the ones provided by Salesforce, Leigh added. Those tools are already integrated with a suite of core applications, which Leigh said means IT organizations don’t need to write entire applications from the ground up. Instead, they can use low-code tools in combination with best DevOps practices to accelerate the development and deployment of applications.
In the case of health care, Leigh added that a foundation of battle-tested software-as-a-service (SaaS) applications is crucial because new COVID-19 applications being rolled out need to work reliably the instant they are deployed. Beyond the reliability of the core platform, it’s more critical than ever to employ best DevOps processes to ensure those applications have been thoroughly tested, he said.
Of course, network access to cloud applications can be uneven when everyone is working remotely, However, in time many organizations will increase the amount of bandwidth being made available to critical customers and end users alike. In fact, the economic uncertainty created by the COVID-19 pandemic is likely to accelerate the rate at which organizations have been embracing cloud applications that are consumed on a per-user basis.
In the meantime, it remains to be seen how long the adverse economic impact of the COVID-19 pandemic might be or to what degree relief measures being put in place by countries around the world might mitigate it. Regardless, it’s apparent that organizations that rely on digital processes are more resilient. In some cases, such as the online delivery of entertainment and education services, there has been dramatic growth. The degree to which that growth can be sustained, of course, depends heavily on how much money consumers are willing to allocate to these services when millions of people are unemployed. Whatever the outcome, however, it’s going to be a brave new world of application software.
Kunal Jain, senior product manager for CircleCI, said via the application programming interface (API) that CircleCI exposes DevOps teams can now determine, for example, which workflows are taking the longest to run or what tests might be creating bottlenecks into the CI/CD pipeline.
Armed with that insight DevOps teams can also optimize how credits to employ the CircleCI platform are allocated across their DevOps teams, added Jain. That capability should make it easier for DevOps teams to predict how much they are spending per month to run their CI/CD platform, said Jain. Many more IT organizations may opt to access CI/CD platforms using a software-as-a-service (SaaS) approach that limits the need for them to invest in their own IT infrastructure or in some cases even manage the platform.
DevOps teams have always been sensitive to efficiency but given the current economic climate, minimizing costs is becoming a higher priority for many organizations. As such, DevOps teams need more insights into, for example, how to best break up workflows to keep CI/CD platform costs to a minimum, said Jain. In fact, Jain says the total cost of operating a CI/CD platform is likely to now play a bigger role in selecting a platform as IT leaders demand more visibility into DevOps processes.
Of course, some DevOps teams may find themselves competing for credits based on how efficient they are. Teams who are more efficient than others could also allow IT leaders to reallocate credits as they best see fit based on the progress being made. In a previous era where compute resources were largely considered to be a nominal cost, many DevOps teams may find access to IT infrastructure might no longer be taken for granted.
CircleCI claims it runs more than 30 million independent jobs run every month. The company last year committed to exposing more API endpoints to help DevOps team better understand the languages, architectural patterns, code testing patterns, delivery success rates and team practices being employed. Like most providers of CI/CD platforms, CircleCI has made a commitment to making available a much broader range of actionable insights to DevOps teams via its API.
At this point, it’s unclear what the impact the economic downturn brought on by the COVID-19 pandemic might have on DevOps adoption. Undoubtedly, many organizations will put a hold on some application development projects as they reassess their priorities. On the other hand, with more people working from home, digital business transformation initiatives that require new applications are likely to become a higher priority as organizations seek to reinvent how they engage their end customers. Those projects may even be accelerated as part of a larger business continuity strategy. Regardless of the number of application development projects being launched, the scrutiny of how IT resources are being allocated and consumed is about to increase substantially.
Compuware today announced it is making it easier to shift application performance testing further left on to the shoulders of developers by adding support for a REST application programming interface (API) to its application performance management (APM) platform for mainframe applications, along with a plug-in for Jenkins continuous integration/continuous delivery (CI/CD) environments.
Sam Knutson, vice president of product management for Compuware, said during the current economic downturn brought on by the COVID-19 pandemic, organizations will find it is now more imperative to shift more responsibility for managing all aspects of application development toward developers. Many organizations simply won’t be able to afford to retain IT specialists such as application testers, said Knutson.
Instead, most organizations soon will be looking to automate as many aspects of DevOps as they possibly can with an eye toward enabling developers to achieve goals with as little intervention as possible from IT operations teams, he noted.
In addition, Knutson said the trend of convergence between mainframe and distributed computing teams within IT organizations is about to accelerate. In fact, there may soon be no such thing as “mainframe DevOps,” he noted; rather, the mainframe will be just another mainstream platform on which applications are deployed.
The economic downturn may limit the number of new mainframes being deployed. However, given that the total cost of computing on the mainframe tends to be lower than distributed systems, the number of workloads running on existing mainframes could increase as organizations deploy more Linux-based applications on the venerable platform.
The API Compuware is adding to its Strobe APM platform will help accelerate the development and deployment of those applications by making application testing a more integrated element of a DevOps workflow, said Knutson. Automated tests can be run within the code delivery pipeline using Compuware Topaz for Total Test, the Topaz Utilities plugin or Compuware Hiperstation. Development teams can be notified when performance tests are completed via communications tools such as Slack and Microsoft Teams.
Knutson said Compuware decided to build a plug-in for Jenkins because it is the most widely deployed CI/CD platform in mainframe environments.
Despite the pending merger with BMC Software, IT organizations can count on the fact that the Compuware portfolio of DevOps tools for mainframe environments will continue to be supported and updated, he said, pointing out that this latest announcement represents the 22nd consecutive quarterly update to the Compuware portfolio of DevOps tools for mainframes.
It’s too early to say what precise impact the economic downturn may have on DevOps adoption in mainframe environments. However, it’s safe to say that doing more with less is going to be the order of the day for some time to come. As such, the rate at which IT organizations that rely on mainframes to run their mission-critical applications will be embracing best DevOps practices is likely to increase.
In fact, rather than incurring the costs of replacing those mainframe applications the priority now is much more likely to be modernizing them as much and as soon as possible.
Akamai today extended its DevOps strategy to provide tighter integrations with continuous integration/continuous (CI/CD) platforms and IT automation tools such as Terraform from HashiCorp.
In addition, Akamai is adding support for serverless computing functions to Akamai EdgeWorkers, a JavaScript-based framework through which application logic can be executed on the edge of the Akamai content delivery network (CDN) now as a microservice.
Greg Griffiths, product marketing manager for DevOps solutions at Akamai, said the latest additions will make it easier for DevOps teams to view the Akamai CDN as a natural extension for deploying applications. Akamai launched its first DevOps initiative last year. The goal is to make possible for DevOps teams to spin up new properties and make configuration changes from within the context of their CI/CD workflows, he said.
Terraform support, meanwhile, will make it possible for DevOps teams to programmatically provision and manage properties and DNS zones as code, added Griffiths.
As part of that effort, the Akamai Pipeline can now synchronize with the Akamai Control Center to capture any manual configuration changes in a way that then allows them to be incorporated into a CI/CD workflow, he noted.
Akamai has been making a case for deploying applications as close to the network edge as possible using its CDN to reduce network latency. As part of that effort, EdgeWorkers allows developers to spin up microservices as needed. Those microservices can now access data embedded in the function, including all the data from the HTTP request such as cookies, headers, URL and query parameters.
DevOps teams can now also more easily conduct A/B testing and feature experiments using cached content in addition to delivering different application experiences by modifying the path to cached images and other content based on variables such as customer location or time of day.
Other new capabilities being added by Akamai include the ability to modify both the path and query arguments for a request and determine to which origin any request should be routed.
Griffiths said now that more organizations are leveraging the Akamai CDN as a vehicle for delivering applications at the network edge, the next big initiative will be to make it easier to leverage the company’s managed security services to embrace DevSecOps.
It’s not clear to what degree DevOps teams have embraced CDNs as a vehicle delivering applications. Organizations have, however, been leveraging CDNs to deliver web applications for years now. By providing tighter integration with CI/CD platforms Akamai is essentially making the CDN just another target for deploying applications at the end of a DevOps workflow. That capability may prove critical as organizations move to deploy more application code on edge computing platforms involving use cases that require data to be processed and analyzed in near real-time.
Of course, Akamai is not the only CDN providers with similar ambitions. It is, however, already the largest, so from a DevOps perspective most organizations will soon encounter an Akamai point of presence somewhere soon, if they have not already.
Quick Base, a provider of a platform for building low-code applications, announced this week that it is making its platform available for free through Sept. 30 to first responder organizations that need to build applications quickly to address the COVID-19 pandemic.
Jay Jamison, chief product and technology officer for Quick Base, said it’s apparent first responders soon will need applications to track things ranging from assets such as ventilators to heat maps that show the number of patients in a geographic area relative to the number of intensive care units (ICUs) available.
Quick Base is also making available templates that can be employed to build the most common types of emergency response applications, such as ones already being employed by the City of New Orleans.
Examples of other applications that will be needed include the ability to track businesses in real-time that may be flouting COVID-19 restrictions or landlords that are evicting tenants despite emergency decrees, noted Jamison.
Most of these applications will need to be developed in days versus weeks or months. To that end, Quick Base is also making available to first responder organizations the expertise of its internal customer success staff as well as third-party consultants, he said.
In addition, Quick Base plans to certify many of these applications for distribution via its online store, which will make it easier for a first responder organization in one locality to leverage an application that has already been developed by another first responder organization.
In general, Jamison said first responder organizations will need to apply DevOps principles across their entire organization to adjust to highly fluid situations. Applications undoubtedly will need to be modified as processes evolve and new emergency decrees are declared, he noted.
The biggest challenge from an IT perspective is many first responder organizations lack the process expertise needed to build an application on the fly. Volunteers with IT expertise will be needed to work alongside medical experts, who will need applications that most likely will be deployed in the cloud but made accessible via a range of mobile computing devices. The chances all those applications will work perfectly when first deployed is almost nil, so timely updates to applications will be critical.
Of course, applications and IT processes are not always the first things that come to mind to combat a pandemic. However, the faster first responders can respond to changing conditions on the ground, the more lives that might potentially be saved. In some large cities, it’s probable first responders already have access to a range of applications that to vary degrees might scale to meet the current challenge. However, in smaller localities, the availability of such applications is nominal at best.
Quick Base is not the only provider of low-code and no-code tools for building applications, so there are plenty of options for building applications quickly. Whichever the platform employed, time is going to be of the essence. Outbreaks in Italy, Spain and China have already shown how quickly events can spiral out of control. If any new application is going to be relevant in any other emerging CIVID-19 hot zone, the work to build that application needs to start immediately.
Tasktop this week announced the general availability of an application to manage projects based on a flow framework that captures events as they occur across the software development toolchain.
Company CEO Mik Kersten said Tasktop Viz is the first substantiation of the flow framework in software that provides a value stream management application to enable organizations to more effectively manage software development projects. Tasktop Viz doesn’t necessarily replace project management software as a system of record for billing purposes, for example, said Kersten; however, it does provide a way to visually model the software development environment in a way that makes it easier to identify bottlenecks and potential opportunities to reallocate resources.
Kersten said from a management perspective, existing approaches to managing software development projects are broken. They depend too much on software developers to manually enter data to update a project management application, which they don’t do as often as they should because it takes time away from developing software, he said. Tasktop Viz takes advantage of application programming interfaces (APIs) to automatically capture metadata from across the software development toolchain, providing instant visibility into software development projects without requiring DevOps teams to engage in an additional coding, Kersten noted.
Kersten has been making a case for the adoption of an approach to managing software development projects based on the flow framework for several years. Tasktop Viz now provides IT teams with an application that is designed from the ground up using that model.
Of course, the concept of value stream management applications has been around for some time. The debate now is not so much over the value of these applications as much as it is which architectural approach to building these applications best reflects modern software development. As the number of dependencies between projects continues to expand, it’s becoming next to impossible for organizations to manage multiple software development projects relying solely on spreadsheets and existing project management applications.
That issue is further exacerbated by the fact that businesses are now more dependent on software than ever, so any delay to a project could have a dramatic impact on future revenues.
Kersten said that despite the obvious business benefits, the biggest obstacle to adoption is more psychological than technical. Many software development teams are reluctant to adopt tools that might illustrate how chaotic the software development process within their organization really is. It’s critical that organizations that adopt value stream management applications do so with an eye toward wanting organizations to improve rather than just deploying another tool to measure metrics that are used to increase the amount of code being written.
Of course, there’s no correlation between the amount of code being written and the quality of the applications being developed. The real challenge is to not just accelerate the rate at which applications are being developed, but also to ensure that once those applications are deployed in a production environment the number of fixes required are kept to the absolute minimum possible.
Atlassian announced today it has added a no-code tool to enable DevOps teams to make it easier to customize Jira project management software without having to learn how to code.
Sean Regan, head of growth for software teams at Atlassian, said Automation for Jira will now become a core part of Jira Cloud that will be made available to all 65,000 customers using Jira software. Originally developed by Code Barrell, the tool was acquired by Atlassian last year. Previously, it had been available as an add-on adopted by about 6,500 customers, he said.
The goal is to enable administrators that track projects to reduce the amount of time they spend on manually entering data. On average, organizations are spending 51 hours a month on administrative tasks involving the management of projects, Regan noted. Organizations should take inventory of those tasks and use Automation for Jira to start automating the tasks that are the most repetitive, he said.
Automation for Jira, Regan said, is part of a larger ambitious effort to make Jira software accessible to more than 100 million active end users. By employing a visual tool to automate tasks it should become easier for a broader number of organizations to customize processes by defining rules that trigger events. Organizations will not be forced to depend on developers to write code to create those workflows, he noted.
Automation for Jira is also part of a concerted effort to modernize a venerable Jira project management application that has been widely employed by software development teams for decades. The ultimate goal is to enable software development teams to spend more time building applications versus trying to ascertain the status of any given development project, said Regan.
The no-code Automation for Jira tool is also designed to integrate with collaboration tools Slack and Microsoft Teams within the context of a set of best DevOps practices. In fact, Regan noted any time there is an issue on a software development project it almost always comes down to a lack of collaboration between all the stakeholders involved.
There is, of course, a lot more appreciation for project management software among DevOps teams that typically are trying to organize around multiple projects at the same time. A delay on one project might present an opportunity to reallocate resources to accelerate another. That can’t happen, however, if no one is aware of what bottlenecks exist in the first place.
Not everyone appreciates all the nuances of project management. The less obtrusive project management becomes the more effective it tends to be. Developers are especially notorious for not always updating project management applications, which usually results in project managers having to nag them to share information that other teams are counting on before they can move forward. Hopefully, there may come a day when all project management applications are updated automatically. In the meantime, the less time spent on manual tasks the happier all the members of the software development team are likely to be.
Kubernetes and Docker are two of the most commonly heard buzzwords in modern DevOps conversations. Docker is a tool that enables you to containerize and run your applications, and Kubernetes provides you with a platform to orchestrate or manage these containers—since managing thousands of containers manually using the Docker CLI would be a practical nightmare.
However, simply running thousands of containers and managing them through Kubernetes is not enough. You have to observe and analyze them properly to ensure that your services are up and running optimally. This process is called Site Reliability Engineering (SRE), a term initiated and popularized by Google. Observability and analysis are a major element of SRE. It can be subdivided into the following three areas:
Monitoring allows you to extract numerical metrics from your applications and resources that can later be visualized and analyzed to present the current state of your resources. Once the metrics are extracted, they can be used to set up alert rules, facilitate profiling and debugging, and make better SRE decisions.
Logging enables developers to debug their containers in case of a failure. Containers are short-lived, and so are logs. Kubernetes and Docker do provide a native way of browsing container logs, but it is very limited in its functionality. As a result, a centralized log plane is a must in any container-oriented environment.
Tracing allows you to debug services running on a network and follow a request trail until the source of a problem can be determined. In a microservices architecture, when multiple services/containers send requests to each other to perform one business task, a proper tracing solution is necessary.
This article will list and describe the most effective open source tools for monitoring and analyzing services running as containers.
Prometheus
Prometheus is the first tool that comes to mind when discussing open source monitoring solutions. It is very popular in the development community, and it is a graduate of the CNCF project, which focuses on the monitoring side of SRE. Originally created and open sourced by SoundCloud, Prometheus simplifies the process of pulling numerical metrics based on a time series from a given metrics endpoint. It was built to monitor highly dynamic container environments.
Prometheus is subdivided into three elements: Prometheus server, Alertmanager and exporters. Exporters are stand-alone, independent processes/containers that can be run on your target resource to generate and export metrics via a metrics API. The Prometheus server then takes care of service discovery as well as pulling metrics from the exporters to be stored in the Prometheus DB and later used for visualization or alerting. Alertmanager is responsible for setting up alert rules, analyzing the data in the Prometheus DB and sending alert messages to multiple receivers if a certain rule is triggered. There are a huge number of exporters, listed here, which are both officially supported by Prometheus and maintained by the community.
Prometheus has become the industry standard for monitoring cloud-native architectures. While it is known for its simplicity with service discovery, its ease of use, its alerting capacity and its integration with Kubernetes, its polling architecture is not ideal. Currently, the metrics endpoint has to be reachable by the Prometheus server. However, there is a pushgateway implemented in Prometheus that enables metric pushing rather than polling. Another downside of Prometheus is that it doesn’t scale well. This problem can be fixed in the Thanos adaptation of Prometheus.
Related tools and technologies: Grafana, Cortex, Thanos, Prometheus Exporters, Alert Manager, Istio, Prometheus Operator.
Grafana is an open source metric analytics and visualization suite. It allows you to create custom dashboards using data taken from multiple sources, such as Prometheus, Elasticsearch, MySQL, Postgres and Redis. Furthermore, Grafana has its own alerting system and a role-based access control (RBAC) system for software. As a data visualization tool, Grafana is famous among Prometheus users for enabling them to effectively visualize the metrics stored in Prometheus. There’s a wide array of official and community-built custom dashboards for various data sources in Grafana, allowing users to easily set up dashboards (found at this link) and get on with monitoring. Grafana offers another associated product called Loki, which aggregates logs in Kubernetes and integrates well with the Grafana UI.
Related tools and technologies: Loki, Prometheus.
Figure 2: Kubernetes Resources Dashboard in Grafana. Source: Replex.
Elastic Stack
Elastic Stack is a group of open source products from Elastic designed to help users search, analyze, and visualize data from any type of source, in any format, in real time. This product was previously recognized as the ELK stack, where each letter of the acronym stood for one of the company’s main products: Elasticsearch, Logstash and Kibana. Elastic Stack provides both monitoring and logging solutions with the help of its big data database, Elasticsearch.
In order to aggregate logs, people tend to use Elasticsearch for storage, Logstash or Fluentd for log streaming, and Kibana for visualization. Fluentd is not part of the Elastic Stack, but it is widely used with Kubernetes to stream logs in place of Logstash, the tool provided by Elastic Stack. Similarly, Metricbeat is used to scrape metrics and set up visualizations on Kibana. The enterprise version of Elastic Stack ships with X-Pack, a set of additional tools that enables reporting, alerting and role-based access control (RBAC), among other features. By default, the Elastic Stack GUI, Kibana, does not support RBAC. You have to use the previously mentioned enterprise version of Elastic Stack to enable it.
Related tools and technologies: X-pack, Metricbeat, Logstash, Kibana.
Figure 3: Discover View in Elasticsearch. Source: XpresServers.
Sensu Go
Sensu Go is a telemetry and service health checking solution for multi-cloud monitoring at scale. It allows you to gain visibility into servers, containers, services, applications, functions and connected devices across any public or private cloud. Sensu can be run side-by-side with Prometheus to get the best out of both solutions, or it can be run natively without Prometheus. Sensu works best alongside Prometheus, since exporting application level metrics to Prometheus requires loading the Prometheus SDK to your application codebase and exposing a metrics endpoint. The endpoint is then scraped and stored in the Prometheus Server. This may sound like a lot of work—and, sometimes, it is. Sensu avoids this complexity by using a sidecar concept. A Sensu agent is deployed alongside your application. The agent constantly collects and exposes metrics to the Prometheus server without your having to change the application codebase.
Sensu works without Prometheus too. It can operate natively in Kubernetes, where it has its own server to store and visualize metric data exposed by the previously mentioned Sensu agent.
Sysdig has two open source products: Sysdig Inspect and Falco. Here, we’ll focus on Inspect, which monitors and captures the container processes running in your system and allows you to drill into those processes for post-incident forensics. This enables you to analyze your application performance, troubleshoot errors and monitor any processors that could be misbehaving. Furthermore, if your system is breached, Sysdig allows you to understand how the breach occurred and what data was taken in the process. Sysdig Inspect is a very powerful tool that focuses on the performance tuning and security investigation of your system.
Related tools and technologies: Grafana, Sysdig, Sysdig Falco.
Jaeger is an end-to-end distributed tracing solution that was open sourced by Uber Engineering. It allows you to monitor and troubleshoot transactions in complex distributed systems. In modern microservice architectures, the majority of operational problems fall under the umbrellas of networking and observability. When a service failure occurs, you have no idea how the requests have gone from service to service over the network to complete a single business transaction. This makes debugging extremely difficult. Currently incubating under CNCF, Jaeger uses tracing to enable root cause analysis, performance and latency optimization, and distributed transaction monitoring. Jaeger works out of the box with Istio, a popular service mesh implementation open sourced by Google.
Related tools and technologies: Prometheus, Jaeger, Zipkin, Istio.
These tools are widely used in the tech industry, and they all have their benefits. Most of these solutions, however, require skilled implementation and ongoing manual maintenance that can be a burden for DevOps teams and a distraction from the business. There’s no one solution that can cater to all of your requirements, since each tool focuses on one or two specific aspects of observability and analysis. By mixing these tools together, you can derive a unique solution for your individual business needs.
For ease of comparison, the chart below outlines the features offered by each of the tools discussed in this article.
The rise of DevOps is starting to have a significant impact on the rate at which databases now need to be deployed and updated. A global survey of more than 2,000 developers, database specialists and IT leaders conducted by Redgate Software, a provider of tools for automating the management of databases, finds nearly half (49%) are now deploying database changes in production at least once a week or more.
Kendra Little, DevOps advocate for Redgate Software, said most of the changes are being driven by the adoption of best DevOps practices that are now having a cascading impact on other functions in the IT environment.
However, the survey shows the adoption of DevOps remains uneven. Only 18% of respondents said they have adopted DevOps across all projects, while 36% said they have adopted DevOps across some projects. Another 14% said they are at the proof-of-concept stage. Only 13% said their organizations have no plans to adopt DevOps at all. Survey respondents in the financial services and insurance industry sectors have the highest levels of adoption, with more than 77% of respondents saying their organizations are either in proof of concepts (16%), have adopted across some projects (41%) or have adopted across all projects (20%).
Progress appears to be rapid among those that have adopted DevOps. Well over a third (37%) report that only 1% or less of their deployments introduce code defects that require hotfixes. That compares to 30% for all other groups.
The survey also revealed that more than half of respondents (55%) perform most or all of their business-critical database deployments while their systems are still online, with 75% of that group reporting that 10% or less of those deployments caused defects that require hotfixes. Nearly half (46%) are also employing some of automation to deploy databases, according to the survey.
Nevertheless, the survey makes it clear challenges remain. Disruptions to existing workflows and business was cited as the top barrier to adoption (23%), followed by lack of skills (22%) and lack of alignment between developers and operations (16%).
Little said the survey makes it apparent that database management needs to become more aligned with the software development life cycle (SDLC) with organizations transitioning to DevOps. Over a quarter of respondents (26%) said it is still somewhat or very difficult to get code reviews for database changes. A further 16% said that no code reviews are done for database changes early in the development cycle.
Less clear is who precisely is managing the database. Developers in the Age of DevOps are exercising more influence over what databases are employed. However, Little noted that 43% of organizations still have a database administrator managing their databases. That compares to 34% that rely on developers and 21% that have a combination of both. Over time, Little said most organizations will continue to shift toward a combination of both. That, of course, will require a significant amount of cultural change within most IT organizations, where all too often developers have tended to view DBAs as a bottleneck to be eliminated whenever and wherever possible.
