devopsy.kinsta.cloud

Category: Blogs

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.

March 8, 2024
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.

March 7, 2024
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.

March 7, 2024
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 workﬂow. 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 beneﬁts, 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 eﬃcient and more innovative application development process.

How can the same spirit and quality of optimization extend to the database deployment workﬂow?

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 workﬂow 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 eﬃciency by analyzing its outputs, logs and workﬂow 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 workﬂows, a database observability dashboard showcases change management workﬂow 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 ﬁnd high and low performers or discover ineﬃciencies in data connections. Similarly, ﬁltering 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 eﬃcient 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 ﬁnd 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 workﬂow 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 workﬂows.

March 7, 2024
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.

March 7, 2024
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 Computing

The 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.
March 6, 2024
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.

March 6, 2024
AISecOps: Expanding DevSecOps to Secure AI and ML

The evolution from traditional software development to integrating artificial intelligence (AI) and machine learning (ML) has been nothing short of revolutionary. As AI adoption continues and AI technologies become essential to businesses and even our daily lives, they are increasingly prime targets for cybersecurity threats.

A particularly alarming trend is the targeting of code and image repositories by cybercriminals aiming to inject malware into the software supply chain. This tactic not only compromises the integrity of the software but also poses a significant risk to end-users and organizations that rely on these applications for critical operations. The threat of data poisoning presents a sinister challenge to the integrity of AI models. By introducing maliciously modified code and data into the training sets, attackers can manipulate the behavior of AI systems, leading to long-term impacts as the poisoned data persists within machine learning models.

This insidious form of attack underscores the importance of vigilance and robust security measures in safeguarding the data that fuels AI and ML innovations. The cybersecurity landscape has been profoundly shaped by our experiences in securing software through DevSecOps practices. These lessons now serve as invaluable blueprints for addressing the familiar challenges posed to AI and ML security, including the need to protect our software supply chain and the integrity of AI models from such insidious attacks.

Over the past five-plus years, DevSecOps has become a staple of how we develop and secure software through collaboration between software and security teams and by embedding improved security practices into every phase of the development process. Is DevSecOps “there yet” as our answer to our software security challenges? No, but it is continuing to improve and evolve as most security practices do. This integrated approach has helped us improve our software products’ security and increased the security visibility between security and software engineers. The principles and successes of DevSecOps can similarly guide the secure development and deployment of AI and ML models.

AI and ML models continuously learn and evolve, making them unique compared to traditional software. AISecOps, the application of DevSecOps principles to AI/ML and generative AI, means integrating security into the life cycle of these models—from design and training to deployment and monitoring. Continuous security practices, such as real-time vulnerability scanning and automated threat detection, protection measures for the data and model repositories, are essential to safeguarding against evolving threats.

One of the core tenets of DevSecOps is fostering a culture of collaboration between development, security and operations teams. This multidisciplinary approach is even more critical in the context of AISecOps, where developers, data scientists, AI researchers and cybersecurity professionals must work together to identify and mitigate risks. Collaboration and open communication channels can accelerate the identification of vulnerabilities and the implementation of fixes.

Data is the lifeblood of AI and ML models. Ensuring the integrity and confidentiality of the data used for training and inference is paramount. Lessons from DevSecOps emphasize the importance of secure data handling practices, such as encryption, access controls and anonymization techniques, to protect sensitive information and prevent data poisoning attacks.

Embedding security considerations from the outset is a principle that translates directly from DevSecOps to AI and ML development. This approach also aligns with the growing emphasis on ethical AI, ensuring that models are not only secure but also fair, transparent and accountable. Incorporating security and ethical guidelines from the design phase helps build trust and resilience in AI systems.

The security challenges presented by AI and ML technologies are complex but not new to us. It’s no silver bullet, but we must utilize the lessons from DevSecOps’ successes and failures. By applying DevSecOps lessons learned to AISecOps, we can approach these challenges with approaches that elevate the visibility of AI and AI data security and emphasize continuous security, collaboration, secure data practices and security by design.

Our future is AI-driven; cybersecurity and AI professionals must come together to fortify the foundations of these transformative technologies. It is critical we unlock the full potential of AI and ML while ensuring the safety, privacy and trust of all stakeholders involved.

March 6, 2024
Cloudflare Unveils Platform to Programmatically Unify Cloud Networking

Cloudflare today launched a Magic Cloud Networking platform that makes it simpler to programmatically manage multiple cloud networking environments using Terraform code.

Based on a platform the Cloudflare gained when it acquired the core technology from Nefeli Networks late last year, the Magic Cloud Networking platform presents IT teams with a console through which they can use the existing Cloudflare One secure access service edge (SASE) platform to securely manage multiple cloud networks. The Cloudflare global network spans more than 310 cities in over 120 countries and interconnects with more than 13,000 networks worldwide.

Annika Garbers, director of product for Cloudflare, said this addition to the Cloudflare portfolio promises to make it simpler to integrate network operations (NetOps) with DevOps workflows in a way that makes it simpler to enforce zero-trust IT policies.

The degree to which NetOps and DevOps are integrated tends to vary widely from one organization to the next. It’s still not uncommon for DevOps teams to be able to provision a virtual machine in seconds or minutes but then be forced to wait days for a NetOps team to provide then network access. Arguably, those kinds of delays defeat the purpose of investing in DevOps in the first place.

That’s becoming a more problematic issue as organizations start to deploy workloads across multiple clouds, each with its own construct for managing software-defined networking infrastructure. The Magic Cloud Networking platform provides DevOps teams with a higher level of abstraction for programmatically managing those networks using Terraform code that is already widely used to manage infrastructure-as-code, noted Garbers.

That approach eliminates the need to rely on cumbersome virtual routers that IT teams don’t want to manage. In fact, more IT teams than ever just want to be able to access network services versus having to build, deploy and manage physical routers and switches, said Garbers. In the age of the cloud, the physical network underlay is typically managed by the cloud service provider, so all that’s required is a way to programmatically unify the management of multiple cloud networks that can be invoked via lower-level application programming interfaces (APIs).

The one thing that is certain is that as networking services become more programmable, the pace at which applications can be deployed is only going to accelerate. Each organization will need to determine which teams are best suited to manage any given layer of the networking stack. Still, regardless of approach it’s clear networks are finally catching up to rest of the IT infrastructure that is already being managed using code. The challenge, as always, is making just as easy for network administrators that lack programming skills to manage those networks as easily as a DevOps team that already has extensive experience using code to manage the rest of the infrastructure used to provide IT services.

Of course, there will still be plenty of routers and switches to manage in on-premises IT environments but it’s only a matter of time before they become part of a larger DevOps workflow.

March 6, 2024
7 API Observability Anti-Patterns to Avoid
Observability has become a buzzword, and the API world is slowly catching up. But be careful when looking for content about API observability- there are many outdated best practices and irrelevant pieces of content.

I was recently invited as a guest to Stephen Townshend’s SlightReliability podcast, and his brilliant blog post on “Bad Observability” inspired me to start ranting about the topic.

Here is a follow-up to our discussion: The observability anti-pattern to avoid when working with APIs. Thanks, Stephen, for the inspiration!

Anti-Pattern: You Forgot Your Users

It’s easy to lose sight of the fact that APIs are built for people to use. APIs are not just a technical interface; they are a bridge that connects digital experiences and enables people to accomplish tasks efficiently.

There are two different kinds of users for your API:
- The developers who are integrating your API into their system.
- Your customers’ users, who will ultimately interact with the applications or services that rely on your API.
If you can’t understand how they interact with your APIs, you’re missing half the picture.

When developers integrate with your APIs, how long does it take them to make their first successful API call? What are typical errors slowing them down? Observability plays an essential role in surfacing insights to improve developer experience.

Once your customers’ applications or services relying on your APIs are in production, can you track how your releases impacted their requests? Which version of your APIs are they using? What are the most popular endpoints? Are all customers getting the same performance? Same error rates?

Anti-Pattern: Relying Only on API Monitoring

API monitoring typically involves sending automated test requests to API endpoints and verifying the responses. It helps you keep track of the health of your APIs even when there is no customer activity at all, and can be used to report uptime.

But API monitoring is nothing more than black box testing; you don’t see what is happening inside. You just know that your requests reach the API and receive responses, but you can only create and maintain tests for some possible use cases. You will miss something.

Anti-Pattern: Using API Access Logs for Troubleshooting

API access logs are records of requests and responses made to an API, capturing details such as the requestor’s IP address, HTTP method, requested endpoint, status codes and other relevant information for monitoring, debugging and security purposes.

Using access logs to troubleshoot API issues is like searching for a needle in your microservices haystack. One of our users had a performance issue with their APIs; they spent days searching for the root cause using access logs. Is it the gateway? Does it need more CPU? Is it a configuration issue? They enabled distributed tracing and, within seconds, they could see what was happening: All the time was spent in the authentication server issuing JWT tokens.

To really understand what is happening in your system, you need to be able to track a single user request from the API gateway to the upstream services and their dependencies for effective troubleshooting.

As Martin Thwaites puts it: “Logs are a poor man’s observability tool.” You need distributed tracing.

Anti-Pattern: Different Teams, Different Tools, Different Data

Different teams have different needs. The tool that works for your DevOps team might not fit your product team best. By forcing everyone to use the same tool, you’re not promoting unity but inefficiency.

However, while promoting tool diversity might be the right move for your organization, there should be some coordination and integration between different tools and data sources. Open standards like OpenTelemetry help ensure that information can be shared and leveraged across teams and tools.

The DevOps and the product teams should rely on the same error rate when assessing the performance and reliability of the newest API product launched.

Anti-Pattern: One Size Fits All

Different API architecture styles have different needs when it comes to observability.

REST APIs might be today’s default, but newer styles like GraphQL and gRPC are gaining popularity. Each of these styles has distinct characteristics and requirements regarding observability. Just think about GraphQL’s way of handling errors, which differs significantly from REST APIs. Web Socket and event-driven APIs have their own unique observability challenges, as well.

Different API architectures have different needs, and your observability strategy needs to reflect that to improve the overall reliability of your application.

Anti-Pattern: Observability for Production Only

Why aren’t you using observability in pre-production?

By using distributed tracing during the API development life cycles, developers can trace the flow of requests and responses across different services, providing a comprehensive view of how the API behaves under various scenarios.

With observability, they can identify performance bottlenecks and even detect architectural problems like N+1 problems in GraphQL queries.

For teams leveraging APIOps practices, observability data can be used as an additional validation before promoting an API to the production stage.

Anti-Pattern: Starting the Trace at the API Gateway is Overrated

Tutorials about observability usually start the instrumentation process at a microservice level. It is great to have detailed insights into your microservices. But a lot will happen at the API gateway level when dealing with APIs.

You want to capture all your user transactions, including those that never reach your microservices because of rate-limiting rules, an authentication problem or a caching mechanism.

Starting the trace at the API gateway gives you a clear entrance point and a complete picture of the journey of all your users. That’s why it’s important to use a modern API gateway with built-in support for OpenTelemetry.

So there you have it: Seven API observability pitfalls to avoid. Keep your APIs observable and your users happy!

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.
March 6, 2024