devopsy.kinsta.cloud

Author: Mike Vizard

  • CDF Report Surfaces DevOps Workflow Gains

    CDF Report Surfaces DevOps Workflow Gains

    At its cdCon 2022 conference today, the Continuous Delivery Foundation shared a State of Continuous Delivery in 2022 report that found nearly half of developers (47%) use either continuous integration or continuous deployment platforms—but only about 20% report using both to automate all application build, testing and deployment.

    Overall, only a little less than a quarter (23%) of the 18,585 developers surveyed by SlashData on behalf of the CDF said they are not involved in any DevOps-related activities.

    Fatih Degirmenci, general manager for the CDF, said that the relatively low percentage suggested that DevOps workflows are now more widely employed than ever. Monitoring software and infrastructure performance and using continuous integration to automatically build and test code changes remain the most popular DevOps-related activities cited in the survey, at 36% each.

    The survey also found that, among large enterprises, the proportion of low performers when it comes to lead time for code changes has dropped from 34% to 24% in the last six months, while the proportion of top performers that need less than one day for code changes has also increased from 13% to 21%.

    Larger enterprises are also seeing an increase in developers that report they can restore a service in less than an hour (22%) versus those that still require one week (18%), according to the report.

    The survey also suggested there is a strong correlation between the adoption of modern backend technologies such as microservices, containers and Kubernetes and improved lead times for code changes and time to restore. Survey respondents using containers are twice as likely to have lead times of less than one day, while respondents that have adopted Kubernetes are one-third more likely to be top performers.

    However, the survey found no impact on deployment frequency. The percentage of top performers capable of deploying code multiple times per day is 11%, the report found. Developers who don’t use these technologies are, in fact, about twice as likely to deploy multiple times per day. Overall, only 53% of developers that work in backend development are using microservices.

    Degirmenci said it is clear there is still much work to be done in terms of simplifying DevOps workflows. The average number of technologies that DevOps practitioners use now stands at 4.6 in the first quarter of 2022. The CDF last month launched a CDEvents project to create a vendor-neutral specification for defining a format for sharing event data across multiple services, platforms and systems.

    In the meantime, the CDF survey also noted more than a quarter of respondents (26%) now rely on managed continuous integration/continuous delivery (CI/CD) services rather than building and maintaining a DevOps platform themselves.

    It’s too early to say how much complexity is driving organizations to rely on managed services, but as the pace at which applications are being developed continues to increase, more organizations are starting to focus on developer productivity. As a result, more than a few organizations are reviewing their existing approach to DevOps and whether it is actually a bottleneck rather than an accelerant for building and deploying applications faster.

  • Contrast Security Adds Free Code-Scanning Tool

    Contrast Security Adds Free Code-Scanning Tool

    Contrast Security this week made available a free security tool that enables developers to scan their code using the same core engine used by the cybersecurity team within their organization.

    Steven Phillips, vice president of product marketing for Contrast Security, said while there is no shortage of free tools for scanning code these days, the majority are not especially accurate. The scanning engine in CodeSec by Contrast Security is more than 10 times more accurate, Phillips said, because it is optimized to identify true positives versus generating a lot of false negatives, he claimed. He added that CodeSec is not just another freemium offering for developers that is a hobbled version of a commercial offering.

    CodeSec also differs from Contrast Security’s existing application security tool because it provides access to a command-line interface (CLI) that makes it easier to integrate within the context of a DevOps workflow. That approach makes it simpler for organizations to shift more responsibility for application security further left toward developers, noted Phillips.

    However, shifting responsibility left toward developers is not a panacea, Phillips said. The Contrast Security approach enables more collaboration between development and cybersecurity teams that are using the same scanning engine via a software-as-a-service (SaaS) platform to discover vulnerabilities, he noted.

    It’s difficult to determine just how far cybersecurity might shift left, but every vulnerability discovered by an application development team is one less for cybersecurity teams to ask developers to fix in a production environment. The challenge is making it as simple as possible for developers to discover those vulnerabilities.

    One way or another, the amount of time and effort being applied to application security has increased sharply in recent months following the disclosure of a series of high-profile breaches. Cybercriminals are now targeting software supply chains as part of an effort to compromise a wide range of downstream applications. Many of the modules that developers routinely reuse are being compromised by surreptitiously inserted malware. The fundamental challenge organizations are trying to address is how to build and deploy more secure applications without slowing down the rate at which they are built.

    Naturally, training developers to recognize security issues is a big part of the equation. However, no two developers are ever going to have the same level of cybersecurity expertise. Tools that identify vulnerabilities in ways that developers can act on are critical for advancing the adoption of DevSecOps best practices. Those tools require some level of acceptance among developers because they tend to prefer CLI tools.

    In the meantime, organizations will most likely have to scan a wide range of already-deployed applications for vulnerabilities. Applications running both inside and outside the cloud have been routinely deployed with a minimum level of scanning. The truth is that many developers have tended to view cybersecurity policies as an impediment to building and deploying applications. Unfortunately, cybercriminals now appreciate and take full advantage of the opportunity to wreak havoc.

  • Orca Security Adds CLI to Improve Cloud Security

    Orca Security Adds CLI to Improve Cloud Security

    Orca Security has extended its cloud security platform via a command-line interface (CLI) that makes it simpler to integrate with a wide range of DevOps tools.

    Rather than relying on agents, the Orca Security platform creates a risk profile using read-only access to block storage accessed via a runtime hosted on Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform. That approach, dubbed SideScanning, eliminates the need for DevOps teams to deploy and maintain agent software to ensure cloud security.

    The platform then scans both workloads and cloud configuration metadata to build a map of risks that better enables DevOps teams to prioritize cloud security efforts.

    Orca Security CEO Avi Shua said the CLI will now make it easier to shift responsibility for cloud security further left toward developers and the DevOps teams that support them by making it easier to scan for vulnerabilities with the context of a larger set of DevSecOps best practices.

    Cloud security remains a major challenge because infrastructure is often provisioned by developers that have little to no security expertise. It’s almost inevitable that mistakes will be made. Orca Security is making a case for a tool that enables organizations to identify those security issues without deploying additional agent software across a wide area network.

    The challenge, of course, is determining how far left to shift responsibility for application security. Even when alerted to a security issue, many developers may not fully appreciate the severity of that issue, noted Shua. Many developers also assume their cloud service provider is providing a level of security that they actually don’t. It’s the responsibility of the entity deploying the application to secure it and the associated configurations used to deploy it. Integrating a cloud security tool within a DevOps workflow becomes critical because it enables more members of a DevOps team to evaluate potential risk to the business as the application is being built rather than after it’s running in a production environment, he added.

    Many existing DevSecOps tools don’t provide enough context; all they do is provide static analysis of the code that’s been deployed, Shua noted. Developers need to have a deeper understanding of which issues represent a level of risk that requires their immediate attention, he said.

    There is, of course, more focus than ever on cloud security as more organizations review how their software supply chains are constructed in the wake of a series of high-profile cybersecurity breaches. Many are discovering that the level of security visibility they have into cloud computing environments is limited, at best.

    It’s not likely security concerns will slow down the rate at which applications are now being deployed in the cloud. Instead, the challenge is better understanding how to secure those applications using substantially different tools and processes than those used to secure applications within an on-premises IT environment.

  • LogicMonitor Expands Reach and Scope of Observability Platform

    LogicMonitor Expands Reach and Scope of Observability Platform

    At its LM Elevate user conference, LogicMonitor today formally launched LM Envision, an observability platform that incorporates artificial intelligence (AI) to both discover and then remediate issues.

    LogicMonitor CEO Christina Kosmowski said LM Envision is the only observability platform available via a software-as-a-service (SaaS) model that can be applied to both on-premises and cloud applications. In total, there are already more than 2,000 integrations for the platform as part of the open LM Envision ecosystem, she noted.

    Over the last year, additional capabilities have been developed and added to the observability platform. These include application performance monitoring (APM) tools to identify bottlenecks and optimize performance, expanded support for public clouds and Kubernetes environments, integration with the StackStorm automation platform, integration with Terraform infrastructure-as-code tools and more advanced tools for searching logs.

    The company has also extended its AI operations tools to provide more context when troubleshooting issues by aggregating logs and including topology tools and graphs.

    Finally, LogicMonitor has added a push metrics application programming interface (API) to make it simpler to ingest data, pre-integrated dashboards and support for open source OpenTelemetry agent software.

    Kosmowski said it’s only a matter of time before observability and AIOps converge to the point where IT teams will finally be able to spend less time managing platforms. One of the major challenges IT teams face is that each platform they use requires its own framework to monitor and manage it. As observability and management frameworks converge, the overall overhead associated with managing modern IT environments should steadily decline as machine learning algorithms make it easier to surface issues before they create a major disruption, she noted.

    The overall goal is to close the loop between the discovery of an IT issue and its remediation, Kosmowski added.

    Observability, of course, is one of the core tenets of any set of DevOps best practices. Achieving it, however, has always been a challenge. The goal now is to eventually replace the hodgepodge of monitoring tools that track a limited set of pre-defined metrics with an observability platform that not only aggregates metrics but enables DevOps teams to launch queries and surface IT issues. In some instances, the rationalization of monitoring tools will help justify the acquisition of an observability platform. The paradox is that, as IT environments become more complex, it may actually become easier to manage those environments as more applications become instrumented and the various silos that isolate IT teams from one another start to collapse.

    In the meantime, there is no shortage of observability platform options. The primary difference between each of them is the degree of integration they provide and their ability to employ AIOps to automatically resolve issues, said Kosmowski. Each minute DevOps teams don’t spend on managing IT platforms is a minute that can be applied to spurring innovation, she added.

    One way or another, DevOps teams will soon have more access to information about their IT environments than ever. Less clear is how much of the data being collected by observability platforms will actually constitute actionable intelligence. But as observability continues to evolve, it’s now more a question of the degree to which that goal will be achieved versus if or when.

  • Catchpoint Enables Experimentation by Automating Web App Testing

    Catchpoint Enables Experimentation by Automating Web App Testing

    Catchpoint this week expanded its open source WebPageTest performance testing suite of tools to enable IT teams to run instant tests that surface suggestions for improving overall web application and site performance.

    In addition, Catchpoint is now providing support for private tests, bulk tests and priority testing capabilities within the WebPageTest tool suite.

    Tim Kadlec, director of engineering for WebPageTest, said the goal is to make it easier for both developers and DevOps teams to experiment with how changes to applications and websites could improve performance using a capability that has now been added to the core suite.

    Identifying opportunities to improve performance typically requires tediously constructing manual tests over a period of weeks, noted Kadlec. Much of that effort is experimental in the sense that no one knows for sure if the tests being constructed will have a material impact on performance.

    The Opportunities and Experiments capability provides teams with a low-code tool for building tests based on a set of best practices that Catchpoint has defined. That approach makes it simpler to automatically generate and test tweaks that, for example, eliminate blocking scripts, optimize image rendering and minimize layout shifts. The result is optimization tests that show how their applications and websites could benefit from specific, actionable improvements without having to change any of the code that has already been deployed, said Kadlec.

    That’s a critical capability because it will encourage a level of experimentation that previously IT teams shied away from, simply because the amount of effort required to achieve an uncertain outcome was too high.

    It’s not precisely clear who is conducting these types of tests, as more responsibility for testing applications continues to shift left toward developers. The latest additions to WebPageTest make it easier for developers to conduct those tests without necessarily requiring help from a DevOps team, noted Kadlec.

    While there has always been a tremendous amount of focus on web application and site performance, the attention level has risen across organizations in the digital business transformation era. Many of the processes being implemented via web applications are extremely latency-sensitive. As more of those applications become routinely tested, the overall level of application performance should steadily improve.

    At the same time, the number of web applications and websites that most organizations are supporting also continues to expand. Most of those organizations are looking for ways to test applications without necessarily having to expand the size of the testing team or significantly increase the amount of time spent on testing.

    Regardless of the approach, it is apparent that testing is becoming more automated. The goal is not so much to eliminate the need for dedicated testing teams, but reduce the number of rote tasks that contribute to test avoidance in the interest of saving time. In theory, the more tests run—and the earlier they are run—the fewer issues that DevOps teams will need to deal with later.

  • Eclipse Foundation Opens Marketplace for OpenJDK Binaries

    Eclipse Foundation Opens Marketplace for OpenJDK Binaries

    The Eclipse Foundation this week opened an Adoptium Marketplace through which DevOps teams can access Java binaries based on the OpenJDK specification. OpenJDK was created based on the Java standard edition (SE) of the programming language and virtual machine.

    Mike Milinkovich, executive director of the Eclipse Foundation, said the goal is to make it easier for IT teams to access open source binaries via a vendor-neutral marketplace that complies with the Java SE Technology Compatibility Kit (TCK) that was created to make sure runtimes based on OpenJDK conform to the original Java specification.

    The marketplace has been set up in collaboration with the Adoptium Working Group that was set up by the Eclipse Foundation to govern OpenJDK, an open source implementation of the Java SE originally created at Sun Microsystems and later acquired by Oracle.

    Members of The Adoptium Working Group include Alibaba Cloud, Azul, Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic and Red Hat. That group created an Eclipse AQAvit project to test binaries for compliance with the Java SE TCK specification.

    OpenJDK is a reference implementation used by multiple vendors to create their own binaries, which are only guaranteed to be compatible with the standard until the next update arrives; updates are released approximately every six months. The Eclipse Adoptium project will make it simpler for developer teams to identify which binaries are compatible with specific implementations of OpenJDK. Ultimately, the goal is to encourage developers to build applications using frameworks that make use of new OpenJDK features as they are added to the platform versus continuing to rely on older binaries.

    Java remains the dominant language for developers working in enterprise IT organizations. Over the last few years, however, OpenJDK has gained traction as organizations adopted an open source implementation of the specification that enabled providers of application development frameworks to reduce licensing costs.

    It’s not clear at what rate enterprise IT organizations are replacing proprietary editions of Java with OpenJDK. However, during an economic downturn, more organizations tend to rely on open source software. Many organizations are also now looking to build microservices-based applications using Java frameworks based on OpenJDK runtimes.

    It’s obviously taken quite a bit of time for the OpenJDK community to put together a vendor-neutral marketplace. In the meantime, a wide range of other programming languages gained traction in the enterprise. There is still a lot of dependency on Java for building backend applications and services, but it’s more common than ever to see frontends that access those backend applications and services being built using, for example, a framework based on JavaScript.

    Java, of course, isn’t going away any time soon. The sheer number of enterprise developers that rely on it to build applications will ensure its continued longevity. The important thing to note, however, is that as more open source platforms are employed, the pace at which the overall community will innovate should continue to accelerate.

  • JFrog Aims to Push DevOps to the Edge

    JFrog Aims to Push DevOps to the Edge

    At its swampUP event, JFrog launched a JFrog Connect platform for updating, managing, monitoring and securing remote Linux and internet of things (IoT) devices.

    The JFrog Connect platform is based on a lightweight agent JFrog gained last year with the acquisition of Upswift and that has now been integrated with the JFrog Artifactory repository. DevOps teams can now use a low-code tool to build flow logic that is integrated with a Git repository in addition to triggering a rollback to ensure a device returns to its previous known software state when necessary.

    DevOps teams will also be able to connect to a wide range of Linux-based IoT devices from anywhere in the world and then manage and monitor them in real-time by name, description or tags.

    JFrog CTO Yoav Landman said in the near future, DevOps teams will find themselves building and deploying applications that will not only be deployed on fleets of endpoints at the network edge, but also will be continuously updated.

    Historically, those endpoints have been managed mainly by operations technology (OT) teams, but it will soon be up to DevOps teams to automate the management of those platforms down to an individual container using the lightweight agent created by Upswift, he said.

    The number of application workloads being deployed on edge computing platforms is rising sharply as organizations seek to process and analyze data closer to the point where it is being created and consumed. In fact, that shift is at the core of digital business transformation initiatives that depend on edge computing platforms and devices running, for example, IoT applications that process data in near-real-time.

    The challenge today is in many cases organizations lack the ability to consistently deploy software on edge computing platforms, which results in the creation of a hodgepodge of homegrown tools to manually deploy software on edge computing platforms. There is a clear need to raise the DevOps bar to address edge computing requirements, said Landman.

    It’s too early to say just how much software will be deployed on the edge, but there may come a day when there is more software at the edge than there is in the cloud. In the meantime, the line between edge computing and cloud computing continues to blur. Many more DevOps teams will soon find themselves managing thousands of distributed endpoints from a central cloud.

    In the meantime, DevOps teams should expect to find themselves working more closely with OT teams that generally have a significantly different culture. Many of those OT teams are just now coming to terms with the implications of connecting endpoints to the internet. The need to continuously update the software on those platforms is not typically the first issue that comes to mind for them. Today much of the software running on edge computing platforms is rarely updated. In the future, however, that software is likely to be updated at a rate that many OT teams are not ready to envision much less manage.

  • Broadcom Acquires VMware to Expand Software Portfolio

    Broadcom Acquires VMware to Expand Software Portfolio

    Broadcom today pulled the trigger on an acquisition of VMware for $61 billion in cash and stock that could dramatically expand its software portfolio.

    Tom Krause, president of the Broadcom Software Group, told investors that the Broadcom infrastructure software group will become part of VMware once the deal closes. The deal, however, includes a 40-day “go shop” option for VMware to court another suitor who might be willing to acquire VMware at a higher price.

    Should the deal close, Broadcom is committed to melding its portfolio of DevOps, AIOps and security offerings with the VMware portfolio, said Krause. Broadcom acquired CA Technologies in 2018 and the enterprise division of Symantec in 2019.

    Krause said Broadcom plans to invest in the core VMware vSphere, vSAN and vRealize management software platforms that drive the most revenue for VMware today. Broadcom is also committed to increasing VMware earnings from $4.7 billion to $8.5 billion within the next three years. The primary driver of that growth will be savings generated by eliminating duplicate functions in the combined company and a forecasted increase in the volume of workload running on VMware platforms, said Krause. There are currently 300,000 vSphere customers that are increasing the number of workloads they are deploying both in the cloud and in on-premises IT environments, he noted.

    Broadcom is also committed to shifting as many customers as possible away from perpetual software licenses to subscriptions that generate more consistent recurring revenues, added Krause. VMware today reported revenue for the first quarter of fiscal 2023 was $3.09 billion, an increase of 3% from the first quarter of fiscal 2022. Subscription and software-as-a-service applications accounted for 29% of total revenue for the quarter. Subscription and SaaS revenue for the first quarter was $899 million, an increase of 21% year-over-year.

    Dan Kirsch, principal analyst and managing director for Techstrong Research, an arm of the parent company of DevOps.com, said given the size of the deal, many existing VMware customers are naturally going to be nervous. The primary concern will be the degree to which Broadcom might attempt to increase licensing fees to meet its financial goals, he noted.

    The acquisition of VMware comes at a time when the number of workloads being deployed in the cloud is far outpacing the rate at which workloads are being deployed in on-premises IT environments. The bulk of those workloads run on non-VMware-based hypervisors. However, many of the workloads that run on VMware today in a data center are being shifted to the cloud. VMware has also invested in building a Tanzu platform for building and deploying cloud-native applications on Kubernetes clusters.

    Broadcom is committed to investing in research and development across the combined software portfolio, said Krause.

    It remains to be seen how much of the VMware employee base will remain with the combined company. It’s not uncommon for there to be a ‘brain drain’ in the wake of a major merger, noted Kirsch.

    Whether or not the deal closes, a lot of IT teams will, at the very least, be reviewing their VMware software portfolio in the weeks ahead as the new Broadcom-VMware entity evolves. In fact, it’s likely that the acquisition of VMware will set off a wave of mergers and acquisitions during what appears to be an economic downturn. That means regular reviews of vendor relationships will soon be the order of the day for a wide range of IT organizations.

  • JFrog Launches Blockchain Project to Secure Open Source Software

    JFrog Launches Blockchain Project to Secure Open Source Software

    At its swampUP event, JFrog today launched Project Pyrsia, an open source project that uses a blockchain platform and Sigstore Cosign and Notary V2 cryptographic signature software to secure software packages. In addition to JFrog, other contributors to the project include Docker, Inc., DeployHub, Futureway and Oracle.

    Stephen Chin, vice president of developer relations for JFrog, said Project Pyrsia will enable organizations to establish a chain of provenance for open source software components stored in a secure network of repositories.

    In effect, Project Pyrsia is making use of decentralized Web3 technologies to secure the open source supply chain, noted Chin. That approach to validating the integrity of software components using a blockchain platform will ensure that any software component being employed by developers has not been compromised, he added.

    Ultimately, the goal is to contribute Project Pyrsia to the Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation that, as a consortium, is looking to coordinate efforts to better secure open source software. JFrog’s own research efforts identified more than 20 different open source software supply chain attacks, with two of those involving zero-day threats for which there was no immediate software patch available. Cybercriminals are targeting open source projects because any malware that gets included will later show up in any number of downstream applications. Their ultimate goal is to activate that malware at a time of their choosing.

    Securing open source software became a more urgent issue following the discovery last year of the zero-day Log4Shell vulnerability that impacted Java applications. Many developers routinely reuse open source software, but many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited; the onus for making sure that software is secure falls on the organizations that decide to deploy it. The trouble is, many developers assume that software is more secure than it really is. Initiatives like Project Pyrsia are part of a larger effort to make it simpler for maintainers to secure open source software.

    It’s not clear whether security concerns are prompting organizations to review the amount of open source software they consume. Most organizations are more dependent on open source software than they realize, because most packaged applications will include open source components. Whenever a zero-day vulnerability is discovered, organizations can spend months looking for all the instances of an open source component that might be vulnerable.

    In theory, increased focus on open source software should lead to greater adoption of DevSecOps best practices that reduce the number of vulnerabilities in production environments. In the meantime, more scrutiny of open source software components is necessary, considering that they are employed by almost every organization.

  • WhiteSource Becomes Mend, Launches Automated Remediation Platform

    WhiteSource Becomes Mend, Launches Automated Remediation Platform

    WhiteSource rechristened itself Mend today and launched a remediation platform that automatically resolves security issues for application developers.

    Rami Sass, co-founder and CEO of Mend, said now the company is going beyond just identifying vulnerabilities in open source software using software composition analysis (SCA) tools and is also fixing them. The overall goal is to make it simpler for developers to address security issues without taking time away from writing code or slowing down the rate at which applications are developed, he added.

    To further that effort, Mend also announced today it is making available a plug-in for JFrog Artifactory that enables Mend Supply Chain Defender, formerly WhiteSource Diffend, to enable detection of malicious open source code. Last year the company acquired Diffend followed by the acquisition of two startup providers of static analysis security testing (SAST) tools.

    Collectively, those applications enabled the company to build the Mend Application Security Platform, a software-as-a-service (SaaS) offering that combines SCA and SAST tools to create an automated remediation framework that can be applied to both open source and proprietary code residing in a repository.

    Mend claimed it added more than 350 customers in the last year to bring its total to more than 1,000 organizations. Most recently, the company raised an additional $75 million in financing to continue investing in a platform specifically designed to address application security issues. In the wake of a series of high-profile security breaches involving software supply chains, Sass noted there is now a much greater appreciation for securing applications and that demand for application security solutions is growing. That demand, in turn, is fueling a wave of consolidation that is, in part, enabled by the convergence of application security tools made available via a SaaS platform, he added.

    Historically, much of the focus on application security focused on discovering vulnerabilities that developers are asked to patch. The issue is that developers are being asked to patch the same modules repeatedly. The Mend Application Security Platform keeps track of what modules have been successfully updated to give developers higher confidence in the updates being applied, said Sass.

    Those recommendations are not being surfaced using machine learning algorithms but rather by the data analytics capabilities that have been added to the company’s portfolio of tools over time, he noted.

    While there may never be such a thing as perfect security it’s apparent that most application security issues can be traced back to relatively common mistakes that developers routinely make. The more those issues are surfaced within a developer workflow, the less dependent organizations will need to be on embedding guardrails within DevSecOps workflows to prevent vulnerabilities from finding their way into production environment. The Mend Application Security Platform doesn’t eliminate the need for those guardrails as much as it reduces the sheer volume of security issues that might otherwise need to be addressed.

    It may be a while before these more advanced developer security tools achieve that result, but it’s clear from how quickly advances are being made that such tools should have a material impact on the overall state of application security.