Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • Survey Surfaces Major Observability Challenges

    Survey Surfaces Major Observability Challenges

    A recent survey found the biggest obstacles to observability were the pace of technology change, IT blind spots and the complexity of modern applications. The survey polled 300 IT professionals to identify the biggest challenges they faced in achieving observability. The accelerating pace of technology change (72%) topped the list, followed by IT blind spots and the growing complexity of modern applications (58% each), and lack of funding (52%).

    The survey, conducted by SolarWinds, also found the typical enterprise suffered nine brownouts or outages every month, each of which lasted around twelve hours. The full cost of outages and brownouts averaged $13.7M annually for these enterprises, according to the SolarWinds report.

    Jeff Stewart, field CTO and vice president, global solutions engineering at SolarWinds, said the survey makes it clear that a lack of observability is having a material impact on businesses. Organizations are now moving beyond monitoring predefined metrics to embrace observability platforms that make it simpler to investigate the root cause of issues that adversely impact businesses; these businesses are more dependent on IT than ever, he added.

    In fact, the primary reason organizations are investing in observability is to improve their customer experience (96%), enable faster innovation (71%), reduce time spent solving (71%) and detecting (60%) issues and improve operational efficiency (55%), the survey found.

    While it’s still early days as far as achieving observability is concerned, a lot of progress is starting to be made as organizations realize that complex IT environments require a different management approach. IT teams can no longer afford to navigate multiple monitoring tools in what often turns out to be a vain effort to prevent brownouts and downtime, noted Stewart.

    In addition, many IT teams are becoming increasingly aware that the telemetry data collected via an observability platform provides the foundation for infusing IT operations with artificial intelligence (AI) capabilities, he added. The ultimate Holy Grail is to one day achieve autonomous operations, noted Stewart.

    There is, of course, no shortage of observability platforms, but Stewart contends that providers of monitoring tools such as SolarWinds are in the best position to help IT teams make the observability transition. Rather than ripping and replacing a monitoring platform, a more seamless transition that results in less disruption is preferable, he noted.

    Regardless of approach, observability platforms that enable IT teams to launch queries across complex distributed computing environments are becoming a necessity. Distributed computing environments often have more dependencies than IT teams can manually track. It’s only a matter of time before the most talented DevOps professionals start to migrate to organizations that provide them with the management tools and platforms required to succeed. Otherwise, the stress of managing a complex IT environment will only result in higher rates of burnout among DevOps professionals.

    It may be a while before observability platforms are pervasively employed across IT environments, but as it becomes clear that brownouts and downtimes result in a decline in revenue, business leaders will understand what’s required to maximize profits. In many cases, the answer will be an observability platform that surfaces the insights needed to proactively manage modern IT environments.

  • Oracle Previews Latest Java 21 Innovations

    Oracle Previews Latest Java 21 Innovations

    Oracle today made generally available a Java 21 edition and provided early access to more than 15 proposed enhancements to the Java development kit (JDK).

    Those enhancements were announced at an Oracle CloudWorld 2023 conference, including support for virtual threads to improve overall throughput and adding support for a vector application programming interface (API) that makes it simpler to build Java applications that involve artificial intelligence (AI) models.

    Georges Saab, senior vice president of Oracle Java Platform and chair of the OpenJDK governing board, said the goal is to streamline access to the latest innovations that will be added to future versions of Java.

    Specifically, via Project Amber, JDK 21 delivers improvements such as support for string Templates, record Patterns, pattern Matching for switch, unnamed Patterns and variables and unnamed classes and instance main methods.

    In addition to the Vector API, Project Panama adds a Foreign Function & Memory API. Project Loom, in addition to virtual threads, adds scoped values and structured concurrency support.

    There is also a more efficient garbage collection mechanism being proposed.

    Oracle is committing to offering long-term support for Java 21 for at least eight years to encourage organizations to start working with this version of Java today. Oracle is also making available a Java Playground, an online sandbox on the Oracle Cloud Infrastructure (OCI) service where developers can create Java code using this edition without needing a local runtime or integrated development environment (IDE).

    In general, Java has been experiencing a renaissance after more organizations began contributing to projects once the core platform became available under an open source OpenJDK license. In fact, the Java community is now adopting many concepts pioneered in other programming languages. That enables organizations to, for example, drive digital business transformation initiatives that depend on the modernization of legacy applications. As part of those efforts, the rate at which Java applications are being deployed in the cloud has substantially increased.

    Despite the number of alternative programming languages, many enterprise IT organizations remain committed to Java. Rather than opting to retrain developers, it’s simply been more cost-effective to enable developers to continue to build applications using a programming language they already know.

    Many organizations are currently in the process of shifting to Java 17. It’s not clear how many organizations will skip Java 17 and jump to Java 21 from previous versions of Java, but it’s clear Oracle is committed to making the lag time between moving from previous versions of Java to Java 21 much shorter.

    Most organizations will find themselves continuing to deploy Java applications everywhere from the network edge to the cloud. These applications will be written in a programming language that has persevered for more than two decades and continues to evolve and mature for the next era of application development.

  • Buildkite Acquires Packagecloud to Streamline DevOps Workflows

    Buildkite Acquires Packagecloud to Streamline DevOps Workflows

    Buildkite Pty Ltd today revealed it has acquired Packagecloud as part of an effort to tightly integrate package management tools with its continuous integration/continuous delivery (CI/CD) platform.

    Buildkite CEO Keith Pitt said the goal is to reduce the level of friction that exists between providers of third-party package management tools and CI/CD platforms that DevOps teams are today required to address themselves.

    There is no shortage of package management tools used to configure, install and update software, but the level of integration between these tools and CI/CD platforms has not historically been very high. The acquisition of Packagecloud will result in a package manager becoming a first-class citizen within the context of a CI/CD platform, said Pitt.

    Buildkite will maintain the existing support Packagecloud provides for platforms such as Jenkins, but the acquisition will streamline DevOps workflows and improve overall developer productivity, he added.

    In the months ahead, Buildkite will also add a range of tools to better enable DevOps teams to achieve that goal, said Pitt. In addition, the company plans to add tools to streamline the management of compliance processes as regulations pertaining to application development are becoming more stringent, he added.

    It’s not clear how much IT organizations are reevaluating their CI/CD platforms to improve developer productivity, but platform engineering as a methodology to centralize the management of DevOps workflows is gaining traction. Those efforts promise to reduce the total cost of implementing DevOps at scale and improve developer productivity by making the scaffolding required to build applications more readily accessible. Today, too many developers are spending time managing developer environments rather than writing actual code.

    The challenge, of course, is convincing developers—who tend to jealously guard their tool prerogatives—to embrace a platform engineering methodology and cede control over the development environment to a centralized team.

    One way or another, developer productivity needs to improve as more organizations encounter economic headwinds. Developers are the most expensive resource any organization has, so improving the rate at which high-quality code is created will always be imperative, noted Pitt.

    Today, organizations depend on software to drive revenue. Investors are assessing senior leaders within those organizations on their ability to deliver quality software in a timely fashion. Each new application and subsequent software update now has a direct impact on the profitability of the organization. As such, tolerance for legacy approaches to building software that require more time and effort is dropping.

    The issue, as always, is that switching from one software development platform to another is an expensive proposition, so many organizations may find themselves supporting a mix of legacy and modern platforms. The challenge becomes defining the pace at which that migration occurs as new applications are created and legacy applications are continuously updated.

  • What DevOps Teams Should Know About Phishing and the Supply Chain

    What DevOps Teams Should Know About Phishing and the Supply Chain

    The DevOps pipeline is a critical component in any organization, and it has broader implications that can affect other organizations as well. Some of the biggest cybersecurity breaches of recent years were supply chain attacks, in which attacks infiltrated the development systems of one organization to break into the systems of its customers downstream. Needless to say, this had catastrophic consequences for the organization under attack.

    According to Deloitte, 91% of cyberattacks begin with a phishing email, and supply chain attacks are no exception. By understanding this common threat and preventing it, DevOps organizations can significantly improve their resilience to these attacks. Of course, phishing awareness and prevention should come as part of a broader cybersecurity program that addresses additional supply chain risks. 

    What is Phishing?

    Phishing is a method used by cybercriminals to trick you into revealing sensitive information. They do this by creating a replica of a legitimate website or email and asking you to provide personal information such as passwords, credit card numbers, and social security numbers.

    Phishing attacks can take various forms. Some of the most common include email spoofing, where the attacker sends an email that appears to be from a trusted source, and website spoofing, where the attacker creates a fake website that looks identical to a legitimate one.

    Regardless of the method used, the goal is the same: To trick you into providing sensitive information. Phishing is a serious threat to both individuals and businesses. It’s not just about losing money; it can also lead to identity theft, damage to your reputation, and even legal consequences. Get more background in this detailed blog post about phishing prevention.

    Implications of Phishing for the Software Supply Chain

    Entry Point for Larger Attacks

    The supply chain is a prime target for phishing attacks. This is because it provides an entry point for larger attacks. For example, a phishing attack on a supplier could compromise their security, allowing the attacker to infiltrate organizations that use their software downstream.

    This kind of attack can have devastating consequences. It could lead to the theft of sensitive information, disruption of operations and even compliance risks.

    Information Theft

    Information theft is one of the most significant risks associated with phishing attacks on the supply chain. When a supplier falls victim to a phishing attack, the attacker can gain access to a wealth of valuable information belonging to the supplier and, in some cases, to its customers or partners. This could include everything from financial data to proprietary business information.

    The loss of such information can have severe implications. It could lead to financial loss, damage to the company’s reputation, and legal consequences.

    Disruption of Operations

    Another significant risk associated with phishing attacks on the supply chain is the potential for disruption of operations. A successful phishing attack could compromise a supplier’s systems or the systems of organizations that rely on that supplier, leading to downtime and delays in the supply chain.

    This kind of disruption can cause significant damage to a business. It could result in lost sales, damage to customer relationships and even the potential for business failure.

    Compliance Risks

    Lastly, phishing attacks on the supply chain can lead to compliance risks. Many industries are subject to strict regulations regarding data security. If a phishing attack leads to a data breach, the companies involved could face hefty fines and penalties.

    Additionally, a data breach could damage a company’s reputation, making it harder to do business in the future.

    Practical Steps to Secure the DevOps Pipeline

    1. Implementing Security Awareness Training

    The first and most crucial step in countering phishing risks is implementing security awareness training. This involves educating all team members about the various forms of phishing attacks and how to recognize them. Interactive sessions, workshops and webinars can be very effective in conveying this knowledge.

    Another vital aspect of security awareness training is teaching employees how to respond to suspected phishing attempts. They should know the steps to take, such as not clicking on any links in a suspicious email, reporting the incident to the IT department and deleting the email.

    2. Deploying Anti-Phishing Tools and Technologies

    While awareness and education are critical, they are not enough on their own to protect against phishing attacks. This is where anti-phishing tools and technologies come into play. These tools can help detect phishing attempts and prevent them from reaching the intended targets.

    There are several types of anti-phishing tools available, including email filters that detect and block phishing emails, browser add-ons that warn users when they attempt to visit a phishing website and AI-based tools that can recognize even sophisticated phishing attempts.

    3. Incorporating Security into the Software Development Life Cycle (SDLC)

    Incorporating security into the software development life cycle (SDLC) is another crucial step in countering phishing risks. This means considering security at all stages of software development, from planning and design to coding, testing and deployment.

    Security should be a primary consideration when designing software systems. This includes designing systems to be resilient to phishing attacks, for example, by using secure coding practices to prevent common vulnerabilities that phishers can exploit.

    During the coding and testing stages, it’s crucial to conduct regular security audits and vulnerability assessments to identify any potential weaknesses that could be exploited by phishers. Any identified vulnerabilities should be promptly addressed.

    Finally, during the deployment stage, it’s vital to ensure that all software components are securely configured and that any security patches or updates are applied promptly. This can help prevent phishing attacks that exploit software vulnerabilities.

    4. Regular Phishing Simulations and Drills

    Finally, conducting regular phishing simulations and drills is an excellent way to test the effectiveness of your phishing prevention measures. These simulations involve sending mock phishing emails to employees to see how they respond. The results can provide valuable insights into areas where further training or technical measures may be needed.

    Phishing drills should be conducted regularly and should cover various phishing techniques. The results of these drills should be shared with all team members, along with feedback and recommendations for improvement.

    Phishing simulations should also be used to test the effectiveness of your anti-phishing tools. If a significant number of mock phishing emails get through your defenses, this could indicate that your tools are not effective and need to be updated or replaced.

    Conclusion

    In conclusion, the integrity of DevOps pipelines—and, by extension, the entire supply chain—is increasingly under threat from phishing attacks. This is a grave concern given the potentially devastating implications ranging from data theft, operational disruption, legal consequences and considerable compliance risks. 

    However, organizations can proactively safeguard their DevOps pipelines by fostering a security-conscious culture underpinned by regular training and awareness programs. Deployment of state-of-the-art anti-phishing technologies and the integration of security at all stages of the SDLC can further strengthen defenses. 

    Additionally, regular phishing simulations and drills can be instrumental in testing and enhancing the resilience of these measures. The war against phishing is continuous and staying one step ahead of the threat requires constant vigilance, innovative strategies and robust technical defenses.

  • Daytona Unfurls Developer Environment for On-Premises IT

    Daytona Unfurls Developer Environment for On-Premises IT

    Daytona has launched a development environment for on-premises IT environments that provides all the benefits of a cloud-based alternative.

    Ivan Burazin, CEO of Daytona, said the company’s namesake alternative to platforms such as GitHub Codespaces enables DevOps teams to retain control and better secure the intellectual property created by developers while simultaneously making them more productive.

    The Daytona platform enables developers to instantly start coding by accessing a development environment based on a set of preferred tools and frameworks, he added. Platform engineering teams looking to scale DevOps workflows can then take advantage of fine-grained access controls and advanced security features across developer environments spanning hybrid IT environments, said Burazin.

    He added that the ability to centrally manage development environments is designed to appeal to organizations attempting to improve developer productivity in highly regulated industries that are now allowed to use cloud-based alternatives. This is becoming a more pressing issue because as regulations become more stringent, organizations are trying to move source code off developers’ individual laptops that are more easily breached than a server environment, noted Burazin. The challenge is striking the right balance between enabling flexibility and centralizing the management of developer environments, he added.

    Of course, many of those organizations could opt to construct their own internal developer portal (IDP) to accomplish the same goal, but in most cases, that would prove expensive to both construct and maintain, noted Burazin.

    The same core team that created Codeanywhere, a cloud-based integrated development environment (IDE), is also behind the development of Daytona. The issue that organizations previously encountered when attempting to shift development to the cloud is that, in addition to regulations that forbid it, developers could not easily customize their environments. The Daytona platform is designed to enable more flexibility without sacrificing control, said Burazin.

    Arguably, organizations are more focused on developer productivity today than at any time in recent memory. Developers typically spend as much as 70% of their time maintaining environments versus writing code, so there is a clear need to reduce the level of toil. Reducing that toil doesn’t guarantee developers will spend more time writing code, but it does create the opportunity. DevOps teams are, as a consequence, being asked to eliminate as many of the bottlenecks that conspire to reduce developer productivity as possible in furtherance of that overall effort.

    Developer productivity issues are not going to be resolved overnight. Developers will not always be immediately inclined to give up control unless it’s conclusively proven that a platform engineering team will be responsive to their needs. The cultural challenge is finding that fine line between reducing friction while still giving the developer the sense that they can add a tool to a workflow that enables them to innovate.

    One way or another, change is coming to DevOps workflows. Each organization will need to determine how quickly that change will occur, but in the absence of any meaningful change, it’s clear they won’t be able to compete against rivals capable of producing higher-quality code faster.

  • DevOps is Making Gains on Mainframe Platforms

    DevOps is Making Gains on Mainframe Platforms

    A survey of 800 executive and technical professionals conducted by BMC found close to two-thirds (62%) are employing DevOps workflows to build and deploy applications.

    In addition, the survey also finds that just under a third of respondents (32%) are applying artificial intelligence to IT operations (AIOps) across all platforms.

    John McKenny, senior vice president and general manager of intelligent Z optimization and transformation at BMC, said the survey shows that organizations continue to invest in mainframe applications alongside distributed computing environments.

    In fact, 61% of respondents noted that data volume on mainframes increased in the last year, with 56% reporting an increase in the number of databases running. Well over a third of respondents (35%) also reported increased interest in taking advantage of cloud technologies to handle, for example, storage and data protection.

    Overall, the survey found that 94% of respondents have a positive perception of the mainframe, with nearly two-thirds (63%) reporting increased mainframe investments over the past year.

    Compliance and security lead the list of priorities for mainframe organizations, with 61% of respondents citing these as top issues, followed by cost optimization (49%), enhancing automation (41%) and data recovery (40%).

    In general, organizations with mainframes are adopting modern application development tools such as VS Code to attract a younger generation of developers. It’s critical to continue to attract developers to mainframe platforms that continue to run the most mission-critical applications in the enterprise, said McKenny. Many of those applications are being modernized using DevOps tools and practices rather than being moved to another platform, he added.

    He added that the appetite for using generative artificial intelligence (AI) to write code for mainframe applications is less clear because of intellectual property concerns. Most organizations are not going to want to expose their mainframe code to a general-purpose large language model (LLM) that drives a public generative AI platform, but there will be a role for private LLMs that are trained using code that has been validated, noted McKenny.

    Regardless of how generative AI evolves, there’s still much work to be done to further the adoption of DevOps best practices in mainframe environments. Each organization will determine how stringently to apply those practices based on the frequency at which applications running on mainframes need to be updated. In most cases, organizations with mainframes will use a mix of waterfall and DevOps-based approaches to building and deploying applications for many years. The decision as to which approach to employ will, naturally, have as much to do with culture as it does the rate at which the application needs to be built and deployed to drive, for example, a digital business transformation initiative.

    The days when mainframes were managed in isolation from the rest of a distributed computing environment are slowly coming to an end. A mainframe is, arguably, just another node for deploying applications. The challenge and the opportunity now is getting the right DevOps tools in the hands of the IT team managing heterogeneous IT environments, including mainframes.

  • Why Enterprises Should Embrace Data-Driven Software Management

    Why Enterprises Should Embrace Data-Driven Software Management

    Many Fortune 500 companies have recently undergone extensive layoffs and now find themselves having to achieve more with fewer people—while grappling with how to integrate generative AI into their products. They must build while economizing, streamlining and increasing efficiency in every part of their company. Yet one of the most vital cogs of the machinery has struggled to evolve over the past 20 years.

    In fact, until now, managing high-tech engineering teams at the world’s biggest companies has not been all that high-tech.

    Back in the 1970s, the “waterfall” model was introduced: An inflexible process in which each phase of software development depended on the previous one’s completion. Then, around the 2000s, companies started moving towards “agile” models that tracked progress in two-week sprints.

    Now, a third era of software development management is emerging. It’s not waterfall or agile; it’s data-driven.

    Current management systems cannot give managers real-time, granular insights so they can make decisions on the spot and run projects in the most efficient way possible. However, data-driven models generate live data on how teams are progressing which has far-reaching effects on businesses’ productivity and future survival.

    The emergence of DORA, a framework for tracking development metrics makes this possible. For the first time, new tools enable us to capture the software development life cycle automatically, without any manual input from the engineer, leading to fewer roadblocks, a 20% faster cycle time and greater ROI.

    Despite this, only a handful of Fortune 500 companies have embraced data-driven metrics. Here are the reasons that shift should happen now.

    Real-time Insights are Game-Changers

    Until now, companies have been using inaccurate methods to track their software development teams. Project management reports on engineers’ output are reviewed every two weeks, monthly, or even quarterly. This means that impactful changes are made at a delayed point in time rather than when they can make the greatest difference to cycle time.

    In contrast, DORA measures specific real-time performance indicators: Deployment frequency (DF), lead time for changes (LT), mean time to recovery (MTTR) and change failure rate (CFR) (For more information, see here). These far more data-driven metrics measure efficiency and velocity at every key point of day-to-day software development, with feedback to management happening continually.

    Often, individual engineers won’t have enough capacity or oversight to inform managers of specific issues during a cycle. Using DORA metrics is like being able to detect that a team has an abnormally high BPM though they are in a rest phase. It’s a signal of illness; that more or different resources are needed. That then requires you to go in and inspect the micro factors that can be adapted.

    For any Fortune 500 company, this quick turnaround is vital. Any small issue in a product cycle can easily escalate and become a critical problem in a matter of days. Instead, using DORA can accelerate software development and, ultimately, time to market.

    DORA Gives you Internal Benchmarks

    But, how can you tell if something is wrong while using DORA? In the first few months of adoption, it’s likely that companies will compare their internal data to industry benchmarks. Unprecedented data has recently been published that offers general performance benchmarks for each DORA metric based on industry research.

    But the end game is to be able to compare your DORA metrics to your own internal benchmarks. With time, each company will develop its own personal baselines that better represent internal capabilities and limitations based on innumerable variables.

    The purpose of DORA benchmarks, however, is not to draw a fixed red line. Think of it more like a speed limit that ensures that people are working at a steady pace while allowing for flexibility.

    A clear sign that your team may be burnt out is a really low cycle time. At times it can be a technical bottleneck, but the beauty of DORA is that it can also point you towards well-being issues.

    DORA Needs to be Coupled With Granular Insights

    DORA is unparalleled when it comes to flagging managers that something is wrong. DORA metrics can flag that a team has a high cycle time – for example, an abnormally long deployment frequency suggests that engineers are working more slowly or that there may be a build-up of code that isn’t being uploaded to the repository quickly enough during the review process. At that point, you need to zoom in to get more information. There are multiple metrics that provide insights into the exact pain points in a team’s development, and you can develop these internally or via tools or engineering management software that provides more holistic oversight.

    In this particular case, you can use a granular metric called “time to merge from first review” to see how fast engineers incorporate feedback from their peers during code reviews. If it is taking a week for the first review to be carried out, integrated into the code and finally uploaded to the general platform, then perhaps there’s a bottleneck occurring during the review process.

    Perhaps the most important benefit of Engineering Leadership 3.0 is that it no longer has to be a guessing game. If they sense something’s wrong, they can check their DORA dashboard, receive confirmation of the problem, hone in with granular metrics, and take corrective actions immediately.

    Teams that adapt their behavior as a result of these data-driven metrics will add incredible ROI to the company. But these changes can’t happen overnight. It will start with getting buy-in from engineering managers and the executive team. For Fortune 500 companies, that often requires elaborating action plans, integrating external tools to operate the tracking process and training engineering managers (in our case, this takes up to five weeks). But once they’re a part of the business, they will become indispensable in running smoothly without stacking up issues.

  • Summit Highlights Open Source Software Security Progress

    Summit Highlights Open Source Software Security Progress

    More than a year after the Open Source Security Foundation (OpenSSF) summit kicked off an initiative to better secure open source software-based software supply chains, a lot of progress has been made—but much work remains to be done.

    The OpenSSF this week hosted a Secure Open Source Software (SOSS) Summit 2023 event in Washington, D.C., during which it made available a Secure Open Source Software Vision Brief 2023. The brief describes the various efforts being made to improve open source software security, including, for example, providing maintainers of open source software projects with free DevSecOps tools.

    This week, the Cybersecurity and Infrastructure Security Agency (CISA) also published an Open Source Software Security Roadmap that defines its role in providing more visibility into how open source is being used and the associated risks.

    However, it’s not clear how much maintainers of these projects are embracing DevSecOps workflows. Many projects are led by a handful of maintainers that often lack the time and skills required to ensure the components they employ have not, for example, been compromised by malware that might find its way into downstream applications.

    Sonatype CTO Brian Fox said the focus of the summit’s participants will be on education and securing public code repositories. While there is a lot of focus on maintainers, he added that there is not enough attention to all the organizations that have not updated open source components within a software build with known vulnerabilities. Many IT teams are reluctant to upgrade components for fear of breaking applications with complex dependencies, but the amount of code that is potentially insecure is massive. “There’s a huge mountain to climb,” he said.

    The challenge is determining which code to upgrade first in a way that will have the most impact in terms of improving application security, added Fox.

    Shawn Ahmed, chief product officer for CloudBees, also noted that organizations should evaluate the DevSecOps processes being applied by maintainers of open source software projects. CloudBees, for example, reviews the plugins provided by the open source community for the Jenkins continuous integration/continuous delivery (CI/CD) platform for vulnerabilities every month, he noted.

    It’s also critical for organizations that consume open source software to contribute code to improve the security of open source software, added Ahmed. Too many organizations are focused on open source software security without devoting resources that would help resolve the issue. he added. “We need to make sure open source software is not a vulnerability threat,” said Ahmed.

    Moran Ashkenazi, chief strategy officer (CSO) and vice president of security engineering for JFrog, said on the plus side, there is a lot more awareness of open source software security issues since the disclosure of a zero-day vulnerability in the Log4j shell tool widely used to manage logs in Java applications. But added that this issue is not going to be resolved overnight. “That was a wakeup call,” she said.

    Tapabrata Pal, vice president of architecture for Fidelity Investments, noted that the fundamental problem is that cybercriminals have become more adept at injecting malware into software supply chains, so no one knows whether their application environments might be compromised. “It’s a serious issue,” he said.

    It’s not known whether the open source software that many developers routinely incorporate into their applications might contain vulnerabilities that could be exploited, but the level of technical debt that has accrued over the last several decades is considerable. The issue is finding a way to address it without becoming overwhelmed by the enormity of the task.

  • CloudBees CEO: State of Software Development is a Disaster

    CloudBees CEO: State of Software Development is a Disaster

    CloudBees CEO Anuj Kapur told attendees at a DevOps World event today that with developers spending only 30% of their time writing code the current state of software development in enterprise IT organizations is a disaster.

    After more than 14 years of effort, the promise of DevOps—in terms of being able to accelerate the rate at which applications are being deployed—remains largely academic, said Kapur. In fact, the effort to shift more responsibility for application security further left toward developers has only increased the amount of cognitive load and reduced the amount of time available to write code, he noted.

    However, with the rise of generative artificial intelligence (AI), an inflection point that will dramatically increase the velocity at which applications are being built and deployed has arrived, said Kapur. The challenge will be achieving that goal without increasing the cognitive load on developers. That cognitive overload results in 70% of developers’ time not being productive within organizations that often hire thousands of developers, he noted.

    Despite all the DevOps issues that need to be addressed, AI advances promise improvement. The overall DevOps market is still relatively young, given the current level of adoption, said Kapur. “We continue to believe the market is early,” he said.

    Today, CloudBees took the wraps off the first major update to the open source Jenkins continuous integration/continuous delivery (CI/CD) platform to have been made in the past several years. At the same time, the company also unveiled a DevSecOps platform based on Kubernetes that is optimized for building and deploying cloud-native applications based on portable Tekton pipelines. That latter platform provides the foundation through which CloudBees will, in the months ahead, apply generative AI to software engineering to, for example, create unit tests on the fly and automate rollbacks.

    In addition, DevSecOps capabilities will be extended all the way out to the integrated development environments (IDE) to reduce the cognitive load of developers.

    The overall goal is to reduce the number of manual processes that create bottlenecks that make it challenging to manage DevOps at scale.

    Criticism of the level of developer productivity enabled by DevOps compared to other development approaches needs to be tempered, said Tapabrata Pal, vice president of architecture for Fidelity Investments, because it still represents a significant advance. There is still clearly too much toil, but the issues that impede the pace at which developers can effectively write code tend to be more cultural than technical, he added.

    Organizations are not inclined to automatically trust the code created by developers, so consequently, there is still a lot of friction in the DevOps process, noted Pal.

    In theory, advances in AI should reduce that friction, but it’s still early days in terms of the large language models (LLMs) that drive generative AI platforms and their ability to create reliable code, he added. That should improve as LLMs are specifically trained using high-quality code, but in the meantime, the pace at which substandard code might be generated could overwhelm DevOps processes until AI is applied there as well, said Pal.

    Thomas Haver, master software engineer for M&T Bank, added that while assisted AI technologies will have a major impact, it’s not reasonable to expect large organizations to absorb them overnight. Patience will be required to ensure advances are made in ways that are both secure and sustainable, he added. In some cases, organizations may opt to build their own LLMs to achieve that goal, noted Haver. “You should not expect to change on a dime,” he said. “It will take time to see the fruits of our labor.”

    While many DevOps challenges need to be resolved, the benefits continue to outweigh the cost and effort required to succeed. The hope is that, with the help of AI, the return on those investments will continue to accrue.

  • JFrog swampUP: Keynotes and What’s Next

    JFrog swampUP: Keynotes and What’s Next

    At the sold-out JFrog swampUP conference this morning, the event’s keynotes were headlined by JFrog CEO Shlomi Ben Haim and co-founder and CTO Yoav Landman. The theme was “next”—what’s next for DevOps and what’s next for developers.

    Of course, there are several answers, but cutting to the chase, it seems security is job one. Developers are squarely in the crosshairs of the bad guys, and protecting them and their code is top priority at JFrog. To do so requires shifting security even further left into the integrated development environment (IDE) itself. Landman demonstrated new functionality in the JFrog Xray scanning and remediation solution’s IDE and emphasized the difference between quality assurance and quality testing.

    CEO Ben Haim took a higher-level view, looking at the issues facing organizations as they seek to develop more, develop faster and do so more securely. He also reinforced the themes hit on by Landman. Overall, the message from both co-founders was that the amount of code being deployed continues to increase exponentially. The need to go faster while being more secure is greater than ever, and JFrog has adopted that as the company’s mission, Ben Haim and Landman said.

    Audience enthusiasm was high, and despite growing to almost 1,000 employees, many of whom have been on board for less than a year, the culture at JFrog remains a constant focus. Landman and Ben Haim reiterated that the company is committed to their customers and their community. 

    That community was well represented, with all three of the major cloud providers exhibiting in the expo area, as well as a good mix of other DevOps providers like CloudBees (whose own DevOps World Roadshow kicked off today). Additionally, some of the new channel partners, such as IT Methods, also exhibited.

    Beyond the keynote, other JFrog presenters in the morning keynote sessions included the leadership of the Artifactory team and senior leadership of the security team.

    JFrog leaders were not the only ones on the agenda at swampUP. A leading games company presented a demonstration of their use of JFrog for CI/CD pipelines. One of the big three cloud providers presented a session discussing whether AI will replace developers (spoiler alert: The answer is no). Additionally, frequent DevOps.com contributors Tracy Ragan and John Willis also presented throughout the day. Our own Will Willis will be recapping some of those highlights.

    All in all, it was a return to normalcy for swampUP. This event felt much like previous swampUPs that occurred before  the COVID-19 pandemic began. The event was sold out with over 400 attendees, which tracks with what we’ve seen at other in-person events recently.

    JFrog has grown and matured but continues to emphasize what has made the company successful. We’re excited to see lots of new features for developers and DevOps practitioners to explore.