Category: Blogs
-
What’s Driving Changes in Open Source Licensing?
Open source projects like Kubernetes transformed the software industry with the help of cooperative communities like the CNCF and the ability to share information quickly. Open source has also made it easier to launch products and gain market share with vendor-driven open source software (OSS) projects, kind of like a premium or PLG sales go-to-market (GTM) model.
However, years of SaaS innovation and disruption have threatened the profitability of vendor-driven open source projects, forcing several major players to shift away from the open source licensing that their companies were founded on. These changes have not only upset the user community but have also caused some people to wonder about the future of OSS. However, there are key differences between the projects that have recently changed their license to be more restrictive and projects supported by communities like the CNCF.
Vendor-Driven Versus Community-Led OSS
How involved and influential is the user community compared to the main or original vendor? This is one way to classify open source projects. Open source projects driven by the community are those where the community of users has the lead role in creating, updating, supporting and securing the software. Some examples are Kubernetes, Linux, Apache and CNCF projects. These projects usually use permissive licenses, such as GPL, Apache or MIT, that let users change, share and use the software for any reason without imposing limits or requirements. These projects also follow the cloud-native principles of scalability, portability, resilience and automation. Open source projects that are driven by vendors are those where one vendor or a few vendors provide most of the software and maintenance. At the same time, the community of users may add some modifications, support and patches. The primary motivation behind these projects is to monetize them. Some examples of open source projects that are driven by vendors are MongoDB, Elastic, Redis Labs and HashiCorp. These projects often use licenses that are more limiting or conditional, such as AGPL, SSPL or BSL, that restrict the use of the software in some situations, such as offering it as a service, or requiring users to pay fees or share changes. These projects may also have features or services that are proprietary or not available in the open source version or that are customized for specific cloud platforms or environments.
SaaS Influence on Open Source Projects
The advent of cheap and ubiquitous cloud computing resources and fast broadband connections has transformed the way software is delivered and consumed. Software-as-a-service (SaaS) has become a dominant model for many applications, offering users convenience, scalability and cost savings. However, SaaS also poses a challenge for some vendor-driven open source projects, as it enables cloud providers and other competitors to offer the same or similar software as a service without contributing back to the original vendor or the original project. This reduces the revenue potential and the incentive for the vendor to continue investing in the open source project.
In response to the challenges posed by cloud computing, some vendor-driven open source projects have changed their licenses or their GTM models. For example, MongoDB, Elastic, Confluent, Redis Labs and HashiCorp have adopted new licenses that restrict the use of their software-as-a-service by third parties or require them to pay fees or share their modifications. These changes are intended to protect the revenue and sustainability of the original vendors and to ensure that they can continue to invest in the open source project. However, these changes have also caused some controversy and backlash from the user community, who may feel that the project is becoming less open and more proprietary or that they are losing some of the benefits and freedoms of open source.
However, community-driven open source projects have largely maintained their permissive licenses and their collaborative approach. These projects still benefit from the diversity and scale of their user community, who contribute to the development, maintenance, support and security of the software. These projects also leverage the support of organizations and foundations, such as the Linux Foundation, the Apache Software Foundation and the CNCF, who provide governance, funding and infrastructure. These projects may also offer premium features or services, such as certifications, training or consulting, to generate revenue and sustain the open source project.
Summary
There are many different types of projects, licenses, communities and business models at play. While some vendor-driven open source projects have faced challenges covering development costs and have changed their licenses to be more restrictive, community-driven projects have largely maintained their permissive licenses and collaborative approach because the incentives behind these projects aren’t driven by profit. Open source is and will remain a vital and valuable component of the technology industry, enabling innovation, collaboration and interoperability.
To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.
-
Sumo Logic Eliminates Ingest Fees for Observability Log Data
Sumo Logic this week announced it will no longer charge a fee for ingesting log data into its observability platform to encourage DevOps teams to apply analytics more deeply.
Michael Cucchi, vice president of product marketing for Sumo Logic, said the Sumo Logic Flex Licensing plan eliminates what amounts to a tax for using an observability platform. Flex Licensing is being made available immediately to new customers and will be offered to existing Sumo Logic customers later this year. There are no hidden monthly charges, feature restrictions, performance tradeoffs or user limitations being applied under the plan.
The licensing plan only applies to log data, but DevOps teams will be able to ingest all structured, semi-structured and unstructured data for a lower cost that Sumo Logic is working to store more efficiently, said Cucchi. The overall goal is to make available a disruptive approach to licensing that lowers the total cost of observability, he added.
Storing log data is going to be increasingly critical as organizations begin to apply multiple types of artificial intelligence (AI) models to further automate IT operations, he added. Those AI models promise to make observability platforms more accessible because algorithms will be able to surface issues that need to be addressed. Historically, the value of an observability platform has been tied to how proficient a DevOps team became when using its query language.
IT teams that have adopted observability platforms have been, to varying degrees, limiting the amount of data they collect and retain to keep storage costs from exploding. The challenge is that as DevOps teams deploy more microservices-based applications, the amount of log data generated has exploded. Determining the root cause of any issue involving those applications can be problematic if log data isn’t readily available. Log data is, after all, the atomic unit for observability, noted Cucchi.
In general, IT environments are becoming too complex for humans to manage without the aid of observability platforms augmented by AI models, noted Cucchi. Each application environment is fairly unique, so it is pivotal for those AI models to be exposed to as much data as possible to ensure optimal results.
It’s not clear whether observability platforms might one day replace the need for many of the monitoring tools that IT teams rely on today to track a set of pre-defined metrics. However, one thing that is certain is that observability platforms, at the very least, present an opportunity to rationalize some of those tools. The biggest challenge is finding ways to fund the acquisition of an observability platform in the first place, which then creates an opportunity to consolidate those tools later.
Given the complexity of highly distributed computing platforms, it’s only a matter of time before most IT teams have some type of observability capability in place. Of course, observability has always been a core DevOps tenet. The trouble is that the tools being used to achieve it are legacy monitoring platforms that don’t provide the level of depth required to successfully manage modern application environments.
Image source: Joshua Sortino via Unsplash.
-
What is RISC-V and Why Has it Become Important for Java?
RISC stands for reduced instruction set computer, and V points to its fifth release in 2015. RISC-V is the new processor architecture to watch out for. Arm-based processors, which stayed among the most popular ones in recent years, may capture a significant share of the semiconductor market, and this is why.
Arm and RISC-V are a type of processor architecture. Another well-known processor architecture type is x86.
Arm and RISC-V chips are used by various industries, from tablets to servers, but initially, they targeted the embedded market. Their design specifics allow them to offer sufficient performance while keeping power consumption low.
RISC-V is a novel open source instruction set architecture (ISA) based on the reduced instruction set computer (RISC) model. The project started at the University of California, Berkeley and was taken over by the RISC-V Foundation in 2015.
Using the x86 and arm processors for hardware development implies high fees because you need to pay royalties to the providers of processor IP, making production expensive and delivering bureaucratic complications. The RISC-V project brought liberation in this sense, creating a new model based on the open-source approach, allowing users to use these processors free of charge. In short, RISC-V is getting more and more popular thanks to its improved design and open-source approach to its development.
RISC-V consists of a set of basic instructions. These instructions act as a communication bridge between hardware and software. RISC-V includes 47 instructions, and additional extensions can be added in a modular way. Thanks to that, RISC-V is smaller compared to x86 or ARM.
In contrast to other popular processors, RISC-V is open source, and therefore, anyone can design, manufacture and sell RISC-V chips and software. As such, RISC-V established new opportunities for modern computing devices, from mobile phones to supercomputers and even microchips for the space industry. Space industry technologies are very challenging as they operate in very different environmental factors. Consequently, the recent NASA announcement on selecting SiFive RISC-V as the core CPU for the high-performance spaceflight computing (HPSC) processor is a great example of the power of RISC-V architecture.
RISC-V belongs to so-called “disruptive technologies.” It removes drawbacks of older systems, eliminating complexity together with licensing fees,, as a result delivering new levels of software flexibility and performance and reducing costs of application development.
According to the RISC-V market report by SHD Group, RISC-V SoCs are forecasted to reach $92.7 billion by 2030, representing a 47% annual growth rate. So, we are still in the early stages of adaptation. Considering that RISC-V can be used as a key ingredient for anything from a smartphone chip to advanced processors for artificial intelligence, its market share could grow very quickly.
It should be noted that Asia is a step ahead in using RISC-V architecture today, with Huawei and Alibaba leading the game. But we also see increasing involvement from companies such as Google, IBM and others. At the same time, the early adoption of RISC-V has already caused a political debate on the microchip trade policy between the U.S. and China.
Java on RISC V
Java has always been at the top of the list for enterprise coding languages, and it is also one of the most widespread languages for embedded systems.
However, applying Java to embedded systems requires adapting it to their technical requirements, which is why Oracle and several OpenJDK vendors have created a special edition of Java for embedded systems. Java runtime for embedded should be compiled into the native ISA for the target hardware, supported by highly tailored, relatively small runtime packages, able to execute on multiple processors if needed for capacity expansion.
RISC-V presents a new type of hardware and needs an adapted version of Java too. So, the Java community initiated the RISC-V port, which was successfully integrated into JDK 19.
However, even with a port in place, you still need to build and test the JDK binary correctly to use it with RISC-V. Today, many OpenJDK vendors and Linux distributions look to offer packages for RISC-V, and gradually, most of the vendors will be delivering JDK packages adapted to RISC-V. But it is great to be among the first. BellSoft released Liberica JDK builds for Linux on RISC-V for JDK 21 LTS. BellSoft commits to supporting version 21 until 2032, providing users with all the benefits of an open source Java runtime from a leading OpenJDK contributor. This includes quarterly CPU and PSU updates and additional solutions for Java development. The RISC-V support in Liberica JDK comes with a Standard JDK flavor, offering three VMs: Server VM, Client VM and Minimal VM designed specifically for systems with lower performance so that your Java applications start up faster and utilize less memory.
OpenJDK and RISC-V are both open source projects; Liberica JDK is free for personal and commercial use. The BellSoft team is glad to continue contributing to the secure and easy development process of Java applications and allowing early access to evolving technologies.
RISC-V is changing the hardware manufacturing market and requires the closest attention from software developers too. RISC-V delivers a sustainable approach to development, removing unnecessary barriers, providing new levels of flexibility and scalability and, as a result, reducing the cost of chip production. RISC-V combined with correct application development practice can completely change the tech future.
-
appCD Launches Platform to Securely Provision Cloud Infrastructure
appCD this week launched a namesake platform that analyzes an application about to be deployed to automatically generate the code needed to provision the IT infrastructure required.
Fresh from raising $6 million in seed funding, appCD CEO Sachin Aggarwal said that approach makes it possible to consistently create secure code for provisioning IT infrastructure versus requiring developers with little to no cybersecurity to manually write it.
Instead, appCD reviews Python or Java code to understand intent, identifies dependencies and then infers application programming interface (API), service configuration, ingress/egress and other environment variables. Terraform code or Helm charts are then automatically generated based on the static analysis of the code that has been reinforced using artificial intelligence (AI) learning techniques.
That approach also makes it simpler for platform engineering teams to centrally manage the provisioning of IT infrastructure using a set of pre-defined policies that are automatically implemented each time an application is deployed to ensure security by default, he added.
DevOps teams can also use appCD to visualize the deployment environment before and after an application is deployed, said Aggarwal.
While infrastructure-as-code (IaC) tools have accelerated the rate at which cloud infrastructure can be provisioned, they are also often the root cause of the security issues that plague cloud computing environments. Developers often misconfigure cloud infrastructure by, for example, inadvertently leaving ports open. The appCD platform reduces the potential such mistakes will be made, noted Aggarwal.
That capability also eliminates the need to attach cybersecurity specialists to a DevOps team because issues are automatically resolved by the guardrails enforced by appCD, he added.
In theory, at least, there may soon come a day when AI routinely improves the quality of the code being used to both build and deploy applications. The more the code used to train a large language model (LLM) is vetted, the more reliable the output becomes. In the meantime, platforms such as appCD are combining static analysis with AI reinforcement learning to achieve that same goal in a use case that is specific to generating code to provision IT infrastructure.
Each DevOps team will naturally need to determine the best path forward, but as regulations pertaining to securing software supply chains become more stringent, it’s only a matter of time before organizations will be required to embrace DevSecOps workflows. In the meantime, DevOps teams should assume that given the probability cloud infrastructure has been misconfigured, it’s all but certain there will be multiple cloud security incidents. In fact, cybercriminals are actively scanning for misconfigurations that they have already created playbooks to specifically exploit in a matter of minutes.
In the absence of being able to prevent all those issues from arising, the immediate priority becomes remediating as many issues as possible before cybercriminals exploit those vulnerabilities. However, it’s also important to draw a proverbial line in the sand to ensure that all cloud infrastructure being provisioned in the future is much more secure than it has tended to be thus far.
-
Permiso Makes Open Source Tool to Identify Cloud Threats Available
Permiso today launched an open source tool dubbed CloudGrappler that surfaces indicators of compromise in cloud computing environments.
Based on a cloudgrep project originally created by Cado Security, CloudGrappler detect patterns that Permiso, a provider of an identity threat detection and response platform, associated with tactics and techniques commonly used by various cybercriminal syndicates.
The tool enables DevSecOps teams to define the data sources they want to scope in a scan of an Amazon Web Services (AWS) or Microsoft Azure cloud. Via a JSON file, DevSecOps teams can access a list of predefined tactics, techniques and procedures (TTPs) that are commonly used to exploit cloud computing environments. DevSecOps teams can also dynamically add queries or a file with multiple queries to scan a specific data set. After scanning, CloudGrappler delivers a JSON report that provides a breakdown of the scan results.
Ian Ahl, senior vice president for P0 Labs, the research arm of Permiso, said that capability makes it possible for DevSecOps teams to identify issues in cloud computing environments that warrant further investigation before there is a major incident. The primary goal is to make it simpler for DevSecOps teams to determine if they need additional assistance to thwart a potential threat, he added.
Cybercriminals are, like almost everyone else, creatures of habit and often tend to leverage the same TTPs multiple times simply because they know they’re effective. However, those TTPs also provide clues to their presence in an IT environment. Once discovered, a DevSecOps team can decide if they can remediate the issue themselves or need to tap external cloud security expertise, noted Ahl.
In general, cloud computing environments may be more secure than most on-premises IT environments. However, the processes used to provision cloud computing environments are often flawed because developers typically don’t have much cybersecurity expertise. Misconfigurations are often rife across cloud computing environments.
Cybercriminals are also especially adept at stealing credentials to gain initial access to cloud computing environments, which they leverage to escalate privileges in a way that provides them unfettered access to the entire cloud computing environment.
Adoption of DevSecOps best practices has improved cloud security, but there are still plenty of instances where, for example, a port inadvertently left open has enabled cybercriminals to infest a cloud computing environment with malware that could lie dormant within cloud applications for months before finally being activated.
There are simply not enough cybersecurity experts available to secure cloud computing environments, so it’s going to be largely up to DevOps teams to secure them. The issue is that in the race to build and deploy applications as quickly as possible, cloud security best practices are either forgotten or simply ignored. Of course, it’s that very carelessness that cybercriminals are counting on to allow them to wreak havoc in an era where the percentage of mission-critical applications running in cloud computing environments will only continue to increase exponentially.
-
Database Observability Extends DORA Metrics and More to Database DevOps
Extending DevOps to the database helps teams keep up with application deployments by shifting left and streamlining previously slow, manual stages in the workflow. Implementing change management automation and governance represents a major step in completing the “last mile” of your CI/CD pipeline. But to fully embrace DevOps and its benefits, you not only need to automate and integrate but continuously optimize your processes.
DORA’s four key metrics provide a compass to application and DevOps teams for continuous optimization of the development pipeline. Measured and represented in analytics and monitoring platforms, these insights drive a faster, more efficient and more innovative application development process.
How can the same spirit and quality of optimization extend to the database deployment workflow?
Organizations are leveraging database observability to apply DORA metrics to change management and use those insights to:
● Accelerate the pipeline
● Improve security
● Reduce errors and remediation
● Anticipate and prevent issues
● Detect and avoid database drift
Much like other elements of DevOps, it’s possible to bring visibility to the database change process thanks to the components that power workflow automation. Database observability unlocks DORA metrics along with other indicators that matter to your DevOps, application, database and IT teams.
The Role of Database Observability in DevOps
Database observability is the capacity to understand a system’s current state and optimize CI/CD pipeline performance, security, and efficiency by analyzing its outputs, logs and workflow data. These measurements inform insights for continuous improvement and proactive problem management, closing the gap between application development and database management in traditional DevOps practices.
Just like a DevOps observability dashboard provides visibility into the performance of application development workflows, a database observability dashboard showcases change management workflow measurements. It can answer questions like, “What is the current state of our environments?” or, more precisely, “Which changes have been deployed? Which of those succeeded or failed? What is the context surrounding those changes – and what can we learn from this information that can help make the pipeline better?”
Teams embrace database observability so they can:
● Streamline database operations by identifying bottlenecks and improving efficiency
● Enhance auditing capabilities through transparent and traceable database change logs
● Foster a culture of continuous improvement by leveraging data-driven insights for database management
● Align with application pipeline acceleration efforts to achieve overall DevOps agility and maturity
● Reduce the frequency and risk of deployment failures and operational downtime
Database observability enables you to shift left, proactively detecting issues and improving integrity earlier, before errors occur in production or further down the pipeline. It supports a high-performing data infrastructure with the ability to detect problems before they endanger your production system and identify opportunities for process improvement that make way for the team to focus on progress and innovation.
DORA Metrics for Database Change Management Optimization
With visibility into your systems, you can use actionable insights to inform decisions for the continuous improvement of your CI/CD pipeline. Think of DORA’s metrics (deployment frequency, lead time for changes, change failure rate, and time to restore service) in the database context, then expand to answer your optimization questions.
Identifying metrics is a critical step in the database observability initiative. Observability insights will help answer, “How do we improve these metrics?” and “What does improvement look like?” By capturing and analyzing database change logs over longer periods, teams can see trends and patterns previously obscured to them by lack of visibility.
Breaking down deployment frequency, for instance, can help highlight the metrics by database, application, and team to find high and low performers or discover inefficiencies in data connections. Similarly, filtering and slicing observability data to create baselines, comparisons and aspirations enables teams to use the data they’re already collecting to look inward and optimize the process itself. This can answer questions like:
● Which deployment pipelines are least efficient and why? How can these be optimized, unblocked and accelerated?
● How often are database rollbacks occurring – and how is that affecting reliability?
● What kinds of errors are most common and costly – and how can they be avoided?
● Which users and systems are accessing which databases – and how can they be more secure?
In addition, database observability provides security and compliance enhancements by enabling trend analysis, reducing remediation time and anticipating potential issues before they occur. It can also identify drift in the intended state of your environment with detailed reports to find the problem fast.
Achieving database observability has typically been an uphill battle – as one of the last areas of the overall application pipeline to be automated, database change management often relies on manual processes that take hours or days, not seconds. However, automated database change management workflow data provides all the ingredients for a successful database observability dashboard, not to mention the capability for self-service deployments and built-in policy checks.
In the context of full-pipeline visibility and continuous optimization, database observability brings much-needed clarity and granularity to teams embracing DevOps at every stage of their workflows.
-
The Ultimate DORA DevOps Guide: Boost Your Dev Efficiency With DORA Metrics
Imagine having a powerful tool that measures your software team’s efficiency, identifies areas for improvement and unlocks the secrets to achieving speed and stability in software development – that tool is DORA metrics.
DORA metrics offer valuable insights into the effectiveness and productivity of your team. By implementing these metrics, you can enhance your dev practices and improve outcomes.
In this blog, we will delve into the importance of DORA metrics for your team and explore how they can positively impact your software team’s processes. Join us as we navigate the significance of these metrics and uncover their potential to drive success in your team’s endeavors.
What are DORA Metrics?
Software teams use DORA metrics in an organization to help improve their efficiency and, as a result, enhance the effectiveness of company deliverables. It is the industry standard for evaluating dev teams and allows them to scale.
The metrics include deployment frequency, lead time for changes, mean time to recovery, and change failure rate. They have been identified after six years of research and surveys by the DORA (DevOps Research and Assessments) team.
To achieve success with DORA metrics, it is crucial to understand them and learn the importance of each metric. Here are the four key DORA metrics
The Four DORA Metrics
1. Deployment Frequency: Boosting Agility
Organizations need to prioritize code deployment frequency to achieve success and deliver value to end users. However, it’s worth noting that what constitutes a successful deployment frequency may vary from organization to organization.
Teams that underperform may only deploy monthly or once every few months, whereas high-performing teams deploy more frequently. It’s crucial to continuously develop and improve to ensure faster delivery and consistent feedback. If a team needs to catch up, implementing more automated processes to test and validate new code can help reduce recovery time from errors.
Why is deployment frequency important?
● Continuous delivery enables faster software changes and quicker response to market demands.
● Frequent deployments provide valuable user feedback for improving software efficiently.
● Deploy smaller releases frequently to minimize risk. This approach reduces the impact of potential failures and makes it easier to isolate issues. Taking small steps ensures better control and avoids risking everything.
● Frequent deployments support agile development by enabling quick adaptation to market changes and facilitating continuous learning for faster innovation.
● Frequent deployments promote collaboration between teams, leading to better outcomes and more successful projects.Use Case:
In a dynamic market, agility is paramount. Deployment frequency measures how frequently code is deployed. Infrequent deployments can cause you to lag behind competitors. Increasing deployment frequency facilitates more frequent rollouts, hence, meeting customer demands effectively.
2. Lead Time for Changes: Streamline Development
The time it takes to implement changes and deploy them to production directly impacts their experience, and this is the lead time for changes.
If we notice longer lead times, which can take weeks, it may indicate that you need to improve the development or deployment pipeline. However, if you can achieve lead times of around 15 minutes, you can be sure of an efficient process. It’s essential to monitor delivery cycles closely and continuously work towards streamlining the process to deliver the best experience for customers.
Why is the lead time for changes important?
● Short lead times in software development are crucial for success in today’s business environment. By delivering changes rapidly, organizations can seize new opportunities, stay ahead of competitors and generate more revenue.
● Short lead times help organizations gather feedback and validate assumptions quickly, leading to informed decision-making and aligning software development with customer needs. Being customer-centric is critical for success in today’s competitive world, and feedback loops play a vital role in achieving this.
● By reducing lead time, organizations gain agility and adaptability, allowing them to swiftly respond to market changes, embrace new technologies and meet evolving business needs. Shorter lead times enable experimentation, learning, and continuous improvement, empowering organizations to stay competitive in dynamic environments.
● Reducing lead time demands collaborative teamwork, breaking silos, fostering shared ownership and improving communication, coordination and efficiency.Use Case:
Picture your software development team tasked with a critical security patch. Measuring lead time for changes helps pinpoint the duration from code commit to deployment. If it goes for a long run, bottlenecks in your CI/CD pipeline or testing processes might surface. Streamlining these areas ensures rapid responses to urgent tasks.
3. Change Failure Rate: Ensuring stability
The change failure rate measures the code quality released to production during software deployments. Achieving a lower failure rate than 0-15% for high-performing dev teams is a compelling goal that drives continuous improvement in skills and processes. Establishing failure boundaries tailored to your organization’s needs and committing to reducing the failure rate is essential. By doing so, you enhance your software solutions and deliver exceptional user experiences.
Why is change failure rate important?
● It enhances user experience and builds trust by reducing failures; we elevate satisfaction and cultivate lasting positive relationships.
● It protects your business from financial risks, and you avoid revenue loss, customer churn, and brand damage by reducing failures.
● Reduce change failures to allocate resources effectively and focus on delivering new features.Use Case:
Stability is pivotal in software deployment. The change failure rate measures the percentage of changes that fail. A high failure rate could signify inadequate testing or insufficient quality control. Enhancing testing protocols, refining code reviews and ensuring thorough documentation can reduce the failure rate, enhancing overall stability.
4. Mean Time to Recover (MTTR): Minimizing Downtime
Mean time to recover (MTTR) measures the time to recover a system or service after an incident or failure in production. It evaluates the efficiency of incident response and recovery processes. Optimizing MTTR aims to minimize downtime by resolving incidents through production changes. The goal is to build robust systems that can detect, diagnose, and rectify problems. Organizations ensure minimal disruption and work towards continuous improvement in incident resolution.
Why is mean time to recover important?
● Minimizing MTTR enhances user satisfaction by reducing downtime and resolution times.
● Reducing MTTR mitigates the negative impacts of downtime on business operations, including financial losses, missed opportunities and reputational damage.
● Helps meet service level agreements (SLAs) that are vital for upholding client trust and fulfilling contractual commitments.Use Case:
Downtime can be detrimental, impacting revenue and customer trust. MTTR measures the time taken to recover from a failure. A high MTTR indicates inefficiencies in issue identification and resolution. Investing in automation, refining monitoring systems and bolstering incident response protocols minimizes downtime, ensuring uninterrupted services.
Key Use Cases
Development Cycle Efficiency:
Metrics: Lead time for changes and deployment frequency, high deployment frequency, swift lead time:
Teams with rapid deployment frequency and short lead time exhibit agile development practices. These efficient processes lead to quick feature releases and bug fixes, ensuring dynamic software development aligned with market demands and ultimately enhancing customer satisfaction.
Low deployment frequency despite swift lead time:
A short lead time coupled with infrequent deployments signals potential bottlenecks. Identifying these bottlenecks is vital. Streamlining deployment processes in line with development speed is essential for a software development process.
Code review excellence:
Metrics: Comments per PR and change failure rate, few comments per PR, low change failure rate:
Low comments and minimal deployment failures signify high-quality initial code submissions. This scenario highlights exceptional collaboration and communication within the team, resulting in stable deployments and satisfied end-users.
Abundant comments per PR, minimal change failure rate:
Teams with numerous comments per PR and a few deployment issues showcase meticulous review processes. Investigating these instances ensures review comments align with deployment stability concerns, ensuring constructive feedback leads to refined code.
Developer Responsiveness:
Metrics: Commits after PR review and deployment frequency, frequent commits after PR review, high deployment frequency:
Rapid post-review commits and a high deployment frequency reflect agile responsiveness to feedback. This iterative approach, driven by quick feedback incorporation, yields reliable releases, fostering customer trust and satisfaction.
Sparse commits after PR review, high deployment frequency:
Despite few post-review commits, high deployment frequency signals comprehensive pre-submission feedback integration. Emphasizing thorough code reviews assures stable deployments, showcasing the team’s commitment to quality.
Quality Deployments:
Metrics: Change failure rate and mean time to recovery (MTTR), low change failure rate, swift MTTR:
Low deployment failures and a short recovery time exemplify quality deployments and efficient incident response. Robust testing and a prepared incident response strategy minimize downtime, ensuring high-quality releases and exceptional user experiences.
High change failure rate, rapid MTTR:
A high failure rate alongside swift recovery signifies a team adept at identifying and rectifying deployment issues promptly. Rapid responses minimize impact, allowing quick recovery and valuable learning from failures, strengthening the team’s resilience.
Code Collaboration Efficiency:
Metrics: comments per PR and commits after PR is raised for review
In collaborative software development, optimizing code collaboration efficiency is paramount. By analyzing comments per PR (reflecting review depth) alongside commits.
After PR is raised for review, teams gain crucial insights into their code review processes.
High comments per PR, low post-review commits:
Thorough reviews with limited code revisions post-feedback indicate a need for iterative development. Encouraging developers to iterate fosters a culture of continuous improvement, driving efficiency and learning.
Low comments per PR, high post-review commits:
Few comments during reviews paired with significant post-review commits highlight the necessity for robust initial reviews. Proactive engagement during the initial phase reduces revisions later, expediting the development cycle.
Impact of PR Size on Deployment:
Metrics: Large PR size and deployment frequency
The size of pull requests (PRs) profoundly influences deployment timelines. Correlating large PR size with deployment frequency enables teams to gauge the effect of extensive code changes on release cycles.
High deployment frequency despite large PR size:
Maintaining a high deployment frequency with substantial PRs underscores effective testing and automation. Acknowledge this efficiency while monitoring potential code intricacies, ensuring stability amid complexity.
Low deployment frequency with large PR size:
Infrequent deployments with large PRs might signal challenges in testing or review processes. Dividing large tasks into manageable portions accelerates deployments, addressing potential bottlenecks effectively.
PR Size and Code Quality:
Metrics: Large PR size and change failure rate
PR size significantly influences code quality and stability. Analyzing Large PR size alongside change failure rate allows engineering leaders to assess the link between PR complexity and deployment stability.
High change failure rate with large PR size:
Frequent deployment failures with extensive PRs indicate the need for rigorous testing and validation. Encourage breaking down large changes into testable units, bolstering stability and confidence in deployments.
Low change failure rate despite large PR size:
A minimal failure rate with substantial PRs signifies robust testing practices. Focus on clear team communication to ensure everyone comprehends the implications of significant code changes, sustaining a stable development environment.
Leveraging these correlations empowers engineering teams to make informed, data-driven decisions — a great way to drive business outcomes— optimizing workflows, and boosting overall efficiency. These insights chart a course for continuous improvement, nurturing a culture of collaboration, quality and agility in software development endeavors.
Help Your Team With DORA Metrics!
In the ever-evolving world of software development, harnessing the power of DORA metrics is a game-changer. By leveraging them, your software team can achieve remarkable results. These metrics are vital to enhancing user satisfaction, mitigating financial risks, meeting service-level agreements and delivering exceptional software solutions.
-
SEC Introduces Enhanced Climate-Related Disclosure Rules
The Securities and Exchange Commission (SEC) has adopted new rules to enhance and standardize climate-related disclosures by public companies and in public offerings. These rules aim to meet investor demands for consistent, comparable, and reliable information on the financial effects of climate-related risks on companies’ operations and their risk management strategies.
The Importance of Transparency
According to SEC Chair Gary Gensler, the initiative is based on the principle that investors should be able to make informed decisions based on companies’ complete and truthful disclosures. The regulations introduce comprehensive requirements for disclosure of significant climate-related risks and their efforts to address them.
Key Aspects of the SEC Rules:
- Mandatory disclosure of climate-related risks that significantly affect or are likely to affect a company’s strategy, operations, or financial condition.
- Details on efforts to mitigate or adapt to climate-related risks, including financial expenditures.
- Disclosure requirements for climate-related targets or goals and their impacts on the company.
- Requirements for certain companies to report Scope 1 and Scope 2 emissions, with an accompanying assurance report. (Scope 1 emissions are direct emissions from owned or controlled sources, while Scope 2 emissions are indirect emissions from the generation of purchased electricity, steam, heating, and cooling consumed by the reporting company.)
Phased Implementation and Review Process
Set to become effective 60 days after publication in the Federal Register, the rules will be implemented in phases based on the filer status of registrants.
Strategic Implications for DevOps and Cloud ComputingThe new SEC rules could catalyze a strategic pivot in DevOps and cloud computing towards more sustainable practices. Specifically, they may further incentivize the development of tools and methodologies for accurately measuring and managing Scope 1 and Scope 2 emissions. New roles or teams may be dedicated to environmental impact analysis within IT departments. These shifts would ensure sustainability becomes a core consideration in tech deployment strategies.
Driving Innovation for Greener Technology
Software solutions that automate the tracking of energy consumption and emissions data across cloud and on-premises environments may see increasing demand. Particularly as organizations seek actionable insights for reducing carbon footprints.
This emphasis on detailed climate-related disclosures may also serve to drive innovation in cloud infrastructure design and management. For example, cloud service providers might introduce new features or services that enable customers to more easily assess and optimize the environmental impact of their cloud usage.
This could lead to the adoption of more energy-efficient computing resources, such as serverless architectures. Dynamically allocating resources could be prioritized to reduce unnecessary energy consumption
Advancing Eco-friendly Solutions with AI
These new rules amplify the global lean into AI for faster and more effective solutions. Utilizing predictive analytics and machine learning, AI can accurately forecast computing demand and make changes in real-time. This ensures that energy consumption closely matches actual usage, minimizing waste and reducing both operational costs and environmental impact.
Balancing AI’s Energy Demand
The flip side, though, is the high energy demands of AI. The new SEC rules will likely place an increasing focus on creating and implementing AI algorithms that are both potent and energy-efficient.
Look for greater focus on AI-driven cooling systems for data centers and the use “lightweight” AI models that require less data and computing power for training and
operation. Such models aim to maintain high efficiency while drastically cutting down the energy needed for their training and inference phases. All striving towards the broader goal of making AI more environmentally friendly.
Sustainability and Innovation: The Path Ahead
With the implementation of the SEC’s new rules, the landscape of corporate reporting and technology development is poised for significant change, emphasizing the importance of sustainability and environmental considerations in business strategies and operational practices.
-
Copado Streamlines Custom Salesforce App Testing
Copado today added a testing tool to its platform for managing DevOps workflows in Salesforce application environments that automatically creates scripts based on manual tests being conducted.
Announced at the TrailblazerDX conference hosted by Salesforce, Copado Explorer enables DevOps teams to integrate those scripts into testing processes that can be repeated as required.
David Brooks, senior vice president and lead evangelist for Copado, said the goal is to make it simpler for DevOps teams to add those tests to the regression tests that are incorporated into pipelines created using the Copado continuous integration/continuous delivery (CI/CD) platform.
In addition, markup and annotation tools enhance collaboration by allowing non-technical subject matter experts to provide detailed feedback and insights to quality assurance and development teams as part of an effort to streamline communications between product owners, testers and developers. Testers without a technical background can use that capability to contribute to the creation and deployment of effective automated tests. That capability makes it possible to shift testing further left to incorporate the business teams that better understand how an application should function, said Brooks.
The challenge is far too many organizations still overlook the importance of testing, noted Brooks. There is a tendency when using low-code tools to assume that not as much testing is required because the tools that generate code create a false sense of instant quality despite flaws that might not manifest themselves until an application is deployed, noted Brooks.
Rather than constantly updating applications, more testing should improve the quality of the applications being built sooner. That’s critical because most organizations don’t have the time and resources needed to continuously iterate applications until they eventually arrive at what the business requires, said Brooks.
It’s still early days so far as the level of DevOps maturity that organizations using the Salesforce platform to build and deploy custom applications have thus far attained, noted Brooks. However, just about every organization that licenses the software-as-a-service (SaaS) platform from Salesforce customizes those applications to better align them with their internal business processes, he added.
Each organization will naturally need to determine to what degree they are prepared to deploy customer applications, but it’s clear it’s becoming simpler to build them. Late last year, Copado, for example, added generative artificial intelligence (AI) tools to make it easier to manage the DevOps workflows used to build these applications, which means the speed at which these apps are built and deployed is about to exponentially increase.
Salesforce, of course, is only one of many SaaS platforms that organizations rely on to build and deploy custom applications. However, as one of the most dominant platforms, the pace at which custom applications are being built continues to increase, with a larger percentage of these applications being built by professional developers familiar with DevOps best practices.
Eventually, those DevOps workflows will be extended to every kind of developer, but for now, most organizations building applications are looking for more consistent outcomes regardless of what type of tool is used to build them.