devopsy.kinsta.cloud

Author: Mike Vizard

  • Tasktop Adds Dashboard to Surface VSM Insights

    Tasktop Adds Dashboard to Surface VSM Insights

    Tasktop today unveiled a dashboard that it promises will simplify tracking of key performance indicators (KPIs) spanning multiple projects.

    In addition, the value stream management (VSM) platform provider revealed it has garnered an additional $100 million in funding.

    Tasktop CEO Mik Kersten said the Tasktop Viz VSM Portfolio Insights dashboard makes it simpler to surface the insights that the company’s VSM platform aggregates as it collects metrics and analytic data from the tools and platforms that make up a DevOps workflow.

    Organizations are then better able to determine the impact any change to the rate at which an application is being developed will have on the business, noted Kersten. IT and business leaders can also more easily identify how constrained resources or persistent quality control issues might be adversely impacting those business goals, added Kersten.

    As a DevOps discipline, VSM is still relatively new. However, Tasktop claims more than half of the Fortune 100 employ its VSM platform. Customers include BMW, CGI, E*Trade and T-Mobile. Despite the economic downturn brought on by the COVID-19 pandemic, the company reports it saw a 30% increase in revenues driven mainly by organizations that have accelerated multiple digital business transformation initiatives. A recent Forrester Consulting Total Economic Impact Study indicated organizations realize a potential 640% return on investment over a three period after implementing the Tasktop VSM platform.

    Tasktop is also a founding member of the Value Stream Management Consortium, which is seeking to promote adoption of VSM platforms to close the divide that often exists between individual DevOps projects and the strategic business goals of an organization.

    The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a process that is automated as much as possible using DevOps best practices, the need to monitor the impact of, for example, missed software development deadlines on the business has become more acute as organizations appreciate just how dependent they are on software.

    VSM platforms automatically take technical metrics, gathered via a DevOps process, and match them to a set of key performance indicators (KPIs) defined by business leaders. The challenge many organizations still face is, first, making sure they have the tools in place to collect the appropriate technical metrics and then identifying the KPIs that truly matter to the business. Once those metrics are gathered and KPIs established, organizations are able to apply advanced analytics to optimize allocation of resources that include people, platforms and processes, noted Kersten.

    It may be a while before VSM becomes pervasively applied with organizations. However, those organizations that find a way to consistently deliver quality applications, on time, that have a greater impact on the business will inevitably start to outperform rivals. The challenge and the opportunity is to bring a level of discipline to bear that ensures that goal is always achieved.

  • DevOps Skills Increasing Among Salesforce Developers

    DevOps Skills Increasing Among Salesforce Developers

    A survey of 521 attendees at a recent online Future of Salesforce DevOps Summit event hosted by Gearset, a provider of a continuous integration/continuous delivery (CI/CD) platform for Salesforce developers, found just under half (47%) of respondents now release software at least multiple times a week, with another 29% releasing software weekly or biweekly.

    More than half of respondents (52%) also noted they now can deploy software in less than an hour.

    Gearset CEO Kevin Boyle said the survey suggested the level of DevOps maturity among developers building applications on top of the Salesforce software-as-a-service (SaaS) platform is increasing rapidly. In the wake of the COVID-19 pandemic, many organizations embraced SaaS platforms to accelerate their digital business transformation initiatives rather than building entire applications from scratch.

    However, the biggest benefit cited by survey respondents was not the ability to release applications faster, but rather the improvements to application quality (77%), followed by increased productivity (69%) and enhanced collaboration (46%). Other benefits cited included reduced complexity thanks to automation; increased agility; more reliable releases and time and cost savings.

    Overall, the survey identifies source code control, CI/CD, unit testing, change monitoring and backups of metadata and data as being the most widely implemented DevOps capabilities that have been adopted. Over the next 12 months, capabilities that will see the most increased adoption among survey respondents include CI/CD, static code analysis and sandbox seeding with data.

    Survey respondents said their top obstacles to adoption of DevOps are ramp-up time, followed by difficulties adopting source control and a perceived steep learning curve. For many organizations that have adopted Salesforce, the intimidation factor when it comes to adopting DevOps best practices is still fairly high, Boyle noted.

    Most recently, Gearset added a free training platform, dubbed DevOps Launchpad, that employs gamification techniques to make DevOps more accessible to developers. Topics covered include version control fundamentals, Git branching strategies and Salesforce backups.

    Gearset counts McKesson, Zillow, Traction on Demand, Intercom, Accenture, IBM and Johnson & Johnson among its customers. It’s not clear to what degree appreciation for DevOps has risen among smaller companies. However, as the number of custom applications deployed as extensions to the Salesforce platform increases, it is apparent that manual processes for building and deploying applications will not scale. The Salesforce platform itself is uniquely constructed using a set of objects and tables that generally lead organizations to adopt a DevOps platform built for that environment. However, it is possible to build and deploy applications using a DevOps platform designed for building and deploying applications that might need to span multiple platforms. Those applications would be integrated with the Salesforce platform at an application programming interface (API) level.

    Regardless of how custom applications are built and deployed, it’s clear Salesforce platforms are becoming more widely used in enterprise IT environments. Each DevOps team will need to determine how best to integrate those platforms within the context of their overall DevOps strategy.

  • Apollo GraphQL Makes Federated Server More Accessible

    Apollo GraphQL Makes Federated Server More Accessible

    In advance of its online GraphQL Summit this week, Apollo GraphQL announced today it has updated its Apollo Federation offering that enables a GraphQL Server to span multiple platforms, making it more accessible to a wider range of developers using different tools.

    Apollo Federation is now integrated with both Apollo Studio, a web-based tool for navigating GraphQL application programming interfaces (APIs), and Apollo Workbench, a plugin for Microsoft Visual Studio.

    At the same time, Apollo GraphQL is making available a command line interface (CLI), dubbed Rover, that makes it simpler to integrate Apollo Federation within a DevOps workflow.

    Matt DeBergalis, CTO, Apollo GraphQL, said GraphQL is continuing to gain traction as an alternative to more rigid REST APIs as more organizations begin to appreciate how dependent they have become on software. REST APIs may be simpler for developers to create, but APIs based on GraphQL are easier to update and manage, DeBergalis noted.

    Apollo GraphQL

    The challenge organizations encounter is that a GraphQL Server can become too large to easily navigate. Apollo Federation provides a mechanism that enables of subset of those APIs to be managed on multiple platforms that make up a federated instance of a GraphQL server, DeBergalis explained.

    DeBergalis also noted that IT vendors that have embraced GraphQL are also starting to add support for Apollo Federation. DataStax, a provider of a curated instance of the open source Cassandra database, has added Apollo Federation to the open source data gateway Stargate it provides to access data stored in a Cassandra database.

    At its core, QraphQL provides an open source data query and manipulation language for APIs along with a runtime for fulfilling queries. Originally developed by Facebook, the GraphQL Foundation is now an arm of the Linux Foundation. As more organizations embrace APIs to construct applications based on microservices, GraphQL adoption has steadily increased. It’s not likely GraphQL will completely replace REST APIs any time soon, however, given how pervasively deployed REST APIs already are.

    However, DeBergalis said that organizations that require a more agile approach to building and deploying software are voting with their feet for GraphQL APIs that are easier to update. As the rate of change in software environments continues to increase, the need for a more flexible approach to deploying and updating APIs becomes that much more apparent, added DeBergalis.

    GraphQL is also more efficient than REST APIs in terms how much data is shipped back and forth between a client and a server. At a time when the amount of data that is being consumed is steadily increasing, the need to give clients more control over how data is returned from a server has become more pressing. Apollo GraphQL claims more than two billion queries per day are now being launched against instances of its GraphQL Server.

    Regardless of what types of APIs are employed there are more of them with each passing day. As the number of digital business transformation initiatives increased in the wake of the COVID-19 pandemic, so too did the number of internal and external facing APIs. Developers may have their own individual preference for the type of API they want to use, but as developers are increasingly being tasked with both building and managing APIs after they are deployed, the appeal of GraphQL becomes harder to ignore.

  • BMC Tightens Integration Across DevOps Tools for Mainframes

    BMC Tightens Integration Across DevOps Tools for Mainframes

    BMC has extended its BMC Automated Mainframe Intelligence (AMI) and BMC Compuware portfolios as part of an ongoing effort to make mainframes just another platform for DevOps teams to build and deploy applications on.

    John McKenny, senior vice president and general manager for Intelligent Z optimization and transformation at BMC, said the DevOps technologies that the company gained last year with the acquisition of Compuware have now been fully integrated with the rest of the BMC mainframe portfolio.

    The BMC Compuware continuous integration/continuous delivery (CI/CD) platform has been integrated with Visual Studio Code, a free tool from Microsoft that is employed widely by developers, he added.

    The BMC Compuware ISPW solution integrates with Visual Studio Code to enable developers to compile changed code on the mainframe with a right-click.

    In addition, the BMC Compuware Topaz platform for applying DevOps practices to the development of mainframe applications has a new command-line interface (CLI) along with support for multiple application programming interfaces.

    A BMC Compuware File-AID 21 tool now makes it possible to reduce the time required to search billions of transactions and log files on a mainframe, while the BMC AMI Security tool has been integrated with the BMC Helix IT service management (ITSM) platform.

    Finally, the BMC AMI Ops Insight tool has been updated to provide diagnostic capabilities to more easily identify the probable cause of an issue, while the BMC AMI SQL Performance for DB2 tool now includes a plug-in for the open source Jenkins continuous integration/continuous delivery (CI/CD) platform.

    McKenny said the goal is to integrate mainframes with any DevOps workflow as part of an effort to either deploy new applications or modernize legacy applications already running on the platform. Modernization of mainframe applications is being driven by the need to add application programming interfaces (APIs) to mainframe applications that need to be integrated with a much broader array of distributed applications, he noted.

    Much of the demand for those APIs is being driven by digital business transformation initiatives that require applications to be able to access backend transaction processing and analytics applications running on mainframes, added McKenny.

    It’s not clear at what rate IT teams that build and deploy applications on mainframes are moving away from waterfall-based processes to embrace best DevOps practices. However, McKenny noted, the rate of changes being made to mainframe applications has accelerated significantly over the last few years.

    While large numbers of applications have been migrated off mainframes over the last decade, the number of enterprise IT organizations that continue to rely on the venerable platform to process transactions remains considerable. Many organizations aren’t convinced that it’s worth rewriting the applications they have relied on for decades when it’s easier to make them more accessible to other applications by adding an API. In effect, McKenny noted, mainframe applications are becoming just another microservice that can be invoked by a developer.

    Regardless of the motivation, it’s clear mainframe applications will continue to run well into the next decade. The challenge IT teams now face is finding a way to make those mainframes just another platform on which to deploy applications at the end of a DevOps toolchain.

  • GitLab Survey Surfaces Advances in DevOps Education

    GitLab Survey Surfaces Advances in DevOps Education

    As more organizations clamor for employees with some type of DevOps education, higher education is responding in kind, according to survey findings.

    A survey of 843 students and teachers at various academic institutions who have had some exposure to the GitLab continuous integration/continuous delivery (CI/CD) platform suggests the number of individuals with DevOps skills graduating from these programs soon might increase significantly.

    The survey, which was conducted by GitLab, identifies the top four use cases for the platform as learning (28%), teaching (22%), research (20%) and information technology/professional use (19%). Nearly a quarter (22%) also indicated they had a secondary use case on campus.

    Certification (57%) was ranked highest in terms of interest, followed by e-learning (49%) and virtual instructor led-training (35%). Students and graduate students are more interested in certification at 58% and 67%, respectively, while administration, faculty and staff were more interested in e-learning.

    The primary benefit of teaching and learning GitLab was identified as the ability to teach operations competencies (57%) and the ability to teach with an end-to-end tool for learning DevOps competencies (51%). For students specifically, the top benefit cited was the ability to teach operational competencies (49%), followed by the ability to build a portfolio and record of contributions (45%). Workforce readiness was cited at 40% and 46% of students and faculty, respectively.

    Dr. Christina Hupy, senior education program manager at GitLab, said the teaching of best DevOps practices within an academic environment is critical because it takes on average six years for IT professionals to master DevOps in the workplace. To help increase the overall pool for DevOps talent, GitLab has been making its software available for free via individual licenses to students and teachers. That program is now being extended to include a GitLab for Campuses offer, which makes the GitLab platform available to multiple users at a reduced price.

    In general, higher education programs have not been meeting the needs of organizations that are looking to hire IT professionals with proven DevOps skills, noted Hupy. Since launching the GitLab for Education Program in 2018, GitLab is trying to help fill that void, issuing more than $2 billion worth of GitLab software licenses in more than 75 countries. In 2020, the organization added 340,000 seats across 250 institutions to the program.

    More than a third of survey respondents (37%) reported they had access to a GitLab subscription at their institution and used it. The most common use case for GitLab cited was source control management (55%); followed by verification, also known as continuous integration, at 36%; planning, at 30%; and management and release, also known as continuous delivery, at 27% each.

    There is also significant use of GitHub among survey respondents, with 85% reporting using it. A distant second was Jenkins (21%), followed by BitBucket (17%), Travis CI (11%) and GitHub Actions (15%).

    IT organizations, of course, have a vested interest in helping educational institutions develop DevOps programs as the number of application development projects being launched simultaneously continues to increase. Otherwise, they will find themselves paying top dollar for DevOps talent that is difficult to find and retain. The challenge, of course, is identifying the institutions that have access to the DevOps tools and platforms that are going to be a pre-requisite for a successful DevOps career those students might eventually enjoy.

  • AlmaLinux Foundation Delivers on CentOS Promise

    AlmaLinux Foundation Delivers on CentOS Promise

    A nonprofit organization launched this week to oversee future development of AlmaLinux, a distribution of Linux based on code originally contributed to the open source CentOS project.

    At the same time, CloudLinux, which created AlmaLinux in response to a decision by Red Hat to pull financial support for CentOS, announced that a stable version of the operating system is now available. CentOS itself was based on the Red Hat Enterprise Linux (RHEL) distribution that is made available via a subscription.

    Jack Aboutboul, community manager of AlmaLinux, said AlmaLinux is the result of the $1 million that CloudLinux committed toward creating a distribution of Linux based on a CentOS project used by hosting providers, such as CloudLinux, to run RHEL-compatible applications at a lower cost. AlmaLinux OS is a binary compatible fork of RHEL 8, which the foundation pledged to update to maintain that compatibility.

    AlmaLinux is one of two distributions based on CentOS that have been created. The other, RockyLinux was created by Gregory Kurtzer, one of the original creators of a CentOS project. Red Hat, in the meantime, has moved to make RHEL subscriptions available for free to individual developers.

    Aboutboul said AlmaLinux is more mature than RockyLinux, because it is based on a Linux distribution that has been battle-tested by IT service providers. AlmaLinux also added a SecureBoot capability as well as support for VMware and the Amazon Web Services (AWS) public cloud, noted Aboutboul.

    The AlmaLinux Foundation also decided to publicly share errata about the ongoing development of the operating system, to make it easier for IT teams to troubleshoot issues that might arise in a production environment.

    It’s not clear yet how much support either AlmaLinux or RockyLinux have. However, at this juncture, forks are becoming fairly common across the open source community. Those disruptions, however, don’t seem to be dampening enthusiasm for open source software. A global survey of 1,250 IT leaders conducted by Red Hat finds nearly 80% of respondents expect to increase their use of emerging open source software technologies over the next two years, with the top three use cases being infrastructure modernization (64%), application development (54%) and digital transformation (53%).

    As Winston Churchill famously said, democracies are messy, and the open source community is no exception. Passions run high. At the same time, the various business models that spring up around open source projects often conflict; because of animosity, greed or differences of opinion, it is not uncommon for multiple forks of an open source project to emerge and evolve over time.

    Despite that issue, IT organizations remain committed to open source for two primary reasons. First, no one needs permission to download open source software to a laptop. That enables developers to more easily experiment with new technologies. Second, cost. Many IT organizations prefer to use free open source software, rather than paying to license commercial software. They may one day pay for support, but the number of open source software users still dwarfs the number willing to pay for support; especially since knowledge and expertise is freely and equally shared across a growing open source community.

    Given those benefits, any friction in the open source community itself is largely seen as an acceptable risk and just the potential cost of doing business.

  • 42Crunch API Security Platform Now Available On-Premises

    42Crunch API Security Platform Now Available On-Premises

    42Crunch has announced that the scanning tools it provides to enable DevOps teams to secure application programming interfaces (APIs) can now be deployed in on-premises IT deployments.

    Previously only available as a cloud service, the 42Crunch API Security Platform has also been updated to provide expanded support for the OpenAPI specification for REST interfaces defined by the OASIS standards body.

    Finally, the 42Crunch API Security platform now allows IT teams to share collections of APIs among specific teams and users with different levels of access in addition to providing integration with third-party identity management platforms.

    Dmitry Sotnikov, chief product officer for 42Crunch, said the on-premises edition of the API scanning platform will make it possible for IT organizations, including those that require all the platforms they run to be deployed in an IT environment, to exercise more control over and extend their DevSecOps workflows to include scans of APIs.

    Cybercriminals are increasingly targeting insecure APIs because they potentially provide access to a trove of data, Sotnikov noted. Those same APIs also enable cybercriminals to compromise an entire software supply chain, Sotnikov added.

    At a time when more organizations are deploying APIs, thanks to the rise of microservices, it’s apparent there is a greater need for a tool that dynamically scans APIs for vulnerabilities before they are deployed, said Sotnikov.

    In general, Sotnikov said IT organizations are becoming more sophisticated in their approach to securing software. Ford Motor Co., for example, is using the 42Crunch API Security Platform to secure both internal and external APIs, Sotnikov said. 42Crunch claims its revenues increased 900% in 2020, with more than 150,000 users of the platform.

    As organizations of all sizes become more dependent on software, cybersecurity teams are now reviewing how that software is constructed. Of course, responsibility of security is still shifting left as part of the overall transition to DevSecOps best processes, but Sotnikov said cybersecurity teams still want to verify for themselves that whatever software is deployed is secure. IT organizations are moving away from a “whack-a-mole” approach to security as they embrace DevSecOps, Sotnikov added.

    Unfortunately, APIs don’t always receive the level of attention they deserve. Many developers still tend to view them as an afterthought, and once deployed, it’s not uncommon for APIs to languish for years without being reviewed or updated. Making sure APIs are secure requires dynamic scanning processes to be baked into DevOps workflows if organizations want to ensure the integrity of their software, said Sotnikov.

    APIs are, of course, everywhere now. The days when a handful of APIs were exposed to share data with a limited number of customers and partners are long over. There are almost no applications built and deployed today that doesn’t expose myriad APIs. Cybersecurity teams obviously can’t keep pace with the rate of change being made to those APIs, as new ones are added and others updated or replaced. The onus for securing all those APIs is, now more than ever, clearly on the DevOps team.

  • Linux Foundation Takes Control Of AsyncAPI Specification

    Linux Foundation Takes Control Of AsyncAPI Specification

    The Linux Foundation announced today that it now plays host to an AsyncAPI Initiative that has developed a specification and a suite of open source tools for asynchronous application programming interfaces (APIs) and event-driven architectures.

    Founding sponsors of the AsyncAPI Initiative include Ably Realtime, Apideck, Bump, IQVIA Technologies, Slack, Solace and TIBCO. Most recently, Postman, a provider of API management tools, committed to providing engineering resources to the project as well.

    AsyncAPI provides a language for describing the interface of event-driven systems, regardless of the underlying technology, and supports the full development cycle of event-driven architecture. That approach helps unify documentation automation and code generation, as well as managing, testing and monitoring asynchronous APIs.

    Chris Aniszczyk, CTO and vice president for developer relations at the Linux Foundation, said the Linux Foundation will work with the member organizations to facilitate a governing framework similar to the frameworks other open source projects have adopted under its auspices.

    In general, reliance on event-driven architectures is on the rise thanks, in part, to the rise of digital business process initiatives that require the processing and sharing of data across multiple platforms in near-real-time. The AsyncAPI Initiative makes it simpler for disparate event-driven platforms to be integrated. It’s unlikely multiple organizations involved in a digital business initiative are ever going to standardize on the same event-driven platform, so an AsyncAPI specification provides a critical linchpin.

    Usage of the AsyncAPI Initiative is already fairly widespread, with Adidas, PayPal, Salesforce, SAP and Slack all employing it in production environments. In fact, the Linux Foundation cited research that identified AsyncAPI as the fastest-growing specification being implemented by developers, after seeing adoption rates in production environments triple from 2019 to 2020.

    Event-driven IT architectures have, of course, been around for decades. However, as they have gained traction in the modern era of software development, the need for the equivalent of a REST API for asynchronous communications between platforms, based on different event-driven architectures, became apparent. The AsyncAPI doesn’t replace the need for other types of API specifications, but Aniszczyk noted that, over time, it will soon player a larger role, especially as cloud-native application environments become more distributed and the number of use cases that can’t be addressed using traditional batch-oriented techniques continues to rise.

    In the meantime, the number of providers of event-driven platforms based on proprietary architectures spans vendors ranging from Oracle and IBM to cloud service providers such as Amazon Web Services (AWS). At the same time, open source messaging platforms such as Apache Kafka are starting to have a significant impact on how IT teams build their own event-driven platforms.

    The level of enthusiasm for an API specification that makes all those platforms more interoperable than they would otherwise be is unclear. However, as modern IT platforms continue to evolve, more IT teams are becoming aware of the crucial role API specifications play in preventing them from becoming locked into one platform.

  • CircleCI Previews Support for Arm Platforms

    CircleCI Previews Support for Arm Platforms

    CircleCI today previewed the ability to deploy applications on platforms based on Arm processors in a forthcoming release of its namesake continuous integration/continuous delivery (CI/CD) platform.

    Tom Trahan, vice president of business development for CircleCI, said that Arm processors are rapidly being embraced by DevOps teams seeking to take advantage of the price/performance advantages they currently have over conventional x86 processors. Amazon Web Services (AWS), for example, makes available an AWS Graviton2 service based on 64-bit Arm Neoverse processors that it claims provides a 40% advantage in overall price/performance.

    The Arm community, meanwhile, has adopted many of the libraries employed on x86 platforms, Trahan noted, which is making it simpler to automate the deployment of applications on Arm-based platforms using a CI/CD platform.

    It’s not clear how quickly developers are building applications for Arm processors. Historically, Arm processors can be found in a wide range of embedded systems typically deployed at the network edge. However, cloud services based on Arm processors are also becoming more widely available, and it’s only a matter of time before more Arm-based platforms are deployed in on-premises IT environments.

    Arm itself is also in the process of being acquired by Nvidia, which envisions running machine learning algorithms, and other classed of advanced workloads, on both Arm processors and graphics processing units (GPUs). Many of the early efforts to build processors optimized for running AI workloads at the network edge are based on Arm processors.

    The addition of Arm platforms to any IT environment will naturally create some management challenges for DevOps teams. In some cases, developers may even decide to build applications using, for example, the latest generation of machines from Apple, that are based on Arm processors, to streamline the application development and deployment process. In other cases, however, applications that are intended to be deployed on Arm processors might still be built on x86 systems.

    Regardless of approach, the arrival of more Arm-based platforms in the enterprise doesn’t mean other classes of processors are going to fade away. Rather, from a processor perspective, IT environments are about to become a lot more diverse as more workloads are deployed on a wider range of processors. It may be quite a while before Arm-based platforms usurp x86-based systems that still dominate the IT landscape. However, during any turbulent economic time, the number of organizations inclined to reduce the total cost of IT by embracing new platforms always increases.

    Fortunately, as more IT infrastructure is managed as code, the easier it becomes to switch platforms. There may even come a day when the decisions about which platform to employ and when is completely automated by machine learning algorithms trained to maximize IT infrastructure efficiency to the fullest extent possible.

    In the meantime, DevOps teams should expect, to one degree or another, to revisit their workflows processes in the months ahead. Not only are more workloads being pushed out to edge computing platforms where Arm processors are commonly found, those Arm processors will soon find their way into the rest of the extended enterprise.

  • Sysdig Adds CSPM Module to DevSecOps Platform

    Sysdig Adds CSPM Module to DevSecOps Platform

    Sysdig today announced it added a cloud security posture management (CSPM) module to its Sysdig Secure DevOps Platform for monitoring application performance and security to enable IT teams to continuously detect threats.

    Pawan Shankar, director of product marketing for Sysdig, said this CSPM capability is based on an open source Cloud Custodian tool that enables IT teams to define rules for accessing cloud infrastructure. In addition, the tool enables IT teams to collect utilization metrics that could be used to turn cloud resources off when they are not being employed. IT teams can now also automatically discover all cloud services being employed, including identifying which ones are misconfigured or might have compliance and regulatory issues that need to be addressed, via a software-as-a-service (SaaS) platform.

    The overall goal is to help reduce the friction that organizations encounter today as they embrace DevSecOps best practices, added Shankar.

    Sysdig is making its CSPM offering available for free, for one account, to encourage DevOps teams to make use of a CSPM capability along with Sysdig’s open source Falco threat detection capabilities. Sysdig today also announced that it extended its implementation of Falco to consume audit logs created on the Google Cloud Platform (GCP). Sysdig donated Falco to the Cloud Native Computing Foundation in 2018. More recently, Sysdig also contributed a sysdig kernel module, along with libraries for the Falco security platform for Kubernetes, that runs in the extended Berkeley Packet Filter (eBPF) microkernel to further improve Linux security.

    The free tier includes a daily check against CIS benchmarks as well as support for inline scanning of up to 250 container images per month running on either the Fargate or Elastic Container Registry (ECR) services provided by Amazon Web Services (AWS).

    Sysdig has been making a case for the convergence of traditional IT monitoring functions and security for several years now. In the wake of some recent high-profile breaches involving software supply chains, the company is betting that more DevOps teams will soon be revisiting how their software supply chains are managed at a time when it’s become easier for malware to move laterally across an entire IT environment. In fact, Sysdig cited research that estimates that malware moving laterally through an organization is involved in 70% of cyberattacks.

    Of course, with the rise of applications based on microservices, the average IT environment is about to become a lot more integrated, which naturally makes it easier for malware to move laterally. IT organizations now require greater visibility across an entire potential attack chain to combat those threats, Shankar noted.

    As DevSecOps continues to evolve, the relationship between developers and cybersecurity teams is also clearly evolving. Now that developers are being held more accountable for cybersecurity, many of them are gravitating toward tools that can be easily integrated within the context of a larger DevOps toolchain.

    It remains to be seen exactly how security tools will be integrated within those tool chains, but for DevOps teams that already rely on Sysdig to monitor their IT environments, the ability to access a raft of additional security services is only a few mouse clicks away.