devopsy.kinsta.cloud

Category: Features

  • Survey Surfaces Spike in Generative AI Usage Across IT

    Survey Surfaces Spike in Generative AI Usage Across IT

    A survey of 800 DevOps and application security operations (SecOps) leaders published today found nearly all (97%) are making use of generative artificial intelligence (AI).

    Conducted by the market research firm Sago on behalf of Sonatype, the survey found that beyond writing code, a full 45% of the 400 security operations professionals have already embedded generative AI into their workflows compared to 31% of the 400 DevOps professionals.

    Security operations teams also reported greater time savings than their DevOps counterparts, with 57% saying generative AI saves them at least six hours a week compared to only 31% of DevOps respondents that saw the same benefit.

    The top benefits cited by security operations teams is increased productivity (21%) and faster issue identification/resolution (16%) compared to faster software development (16%) and more secure software (15%) cited by DevOps professionals.

    It’s still early days as far as embedding generative AI in workflows is concerned, but it’s clear the ability to write code faster is trumping concerns about the increased number of vulnerabilities that might find their way into application environments. The most widely used generative AI platforms are trained on a massive corpus of data that includes code of varying quality. As such, a lot of the code generated by a general-purpose AI platform will likely have as many errors, including vulnerabilities, as the code used to train it.

    The level of faith organizations will place in that code will be heavily influenced by use cases. A script used to automate DevOps workflows that are not externally facing may be one example of where a general-purpose AI platform can boost productivity. In other instances, code that contains vulnerabilities that find their way into a web application might be much more problematic.
    Despite those concerns, however, the survey finds nearly three-quarters (75%) of all respondents feel pressure to use generative AI.

    There are, of course, already large language models trained on code that has been vetted by software engineers. In the months ahead, the code generated by AI platforms specifically designed for that purpose should significantly improve.

    Sonatype CTO Brian Fox said it’s only a matter of time before IT organizations focus more on ensuring the generative AI platforms are tuned for specific tasks. In the meantime, however, application security may get worse before it gets better, with more than three-quarters of DevOps respondents noting that generative AI will result in more vulnerabilities in open source code. Only 58% of security operations professionals are similarly concerned.

    It will be up to the engineers that make up these teams to bring discipline to code quality practices and make sure the code running in a production environment is of high quality, regardless of how it was created, noted Fox. For the moment, the issue is that AI augmentation is now occurring at a faster pace than the AI advances that should one-day help DevOps teams cope with increasingly larger codebases, he noted.

    Survey respondents are also concerned about who might own the code generated by AI. A total of 40% said developers or the organizations they work for should own the copyright for AI-generated output, and most of them agreed developers should be compensated for the code they wrote if it’s used in open source artifacts in LLMs (DevOps 93% versus SecOps 88%). A total of 42% of DevOps respondents and 40% of SecOps respondents said a lack of regulation could deter developers from contributing to open source projects.

    DevOps and SecOps leads both want more regulation: Asked who they believe is responsible for regulating the use of generative AI, 59% of DevOps leads and 78% of SecOps leads said both the government and individual companies should be responsible for regulation.

    At this point, the proverbial generative AI genie is out of the bottle, so there is no going back. The issue that remains to be seen is how DevOps and security operating teams will adjust to that new reality.

  • Tips for Increasing Developer Velocity in the AI Age

    Tips for Increasing Developer Velocity in the AI Age

    These days, everyone is trying to improve release frequencies. Under mounting pressure to deliver more, many software teams are considering new strategies to enhance their developer velocity, like AI-assisted code development and platform engineering. AI has been a boon for automatic code generation, but all the code in the world doesn’t matter if you can’t deploy it into production efficiently.

    Another point is that velocity isn’t always measured productively, said Dori Exterman, chief evangelist of Incredibuild and a self-proclaimed ‘productivity freak.’ Too often, managers place value on quantitative elements, such as points per sprint and unrealistic metrics, when they really should be considering the quality of these components and how easy they are to maintain in the long run.

    I recently chatted with Exterman and other experts about tactics organizations can use to enhance their development velocity. Below, we’ll consider some helpful methods, from optimizing testing automation to creating internal development platforms (IDPs) and evolving your CI/CD processes. Essentially, optimizing the plumbing will be necessary to match the productivity of instant code generation—otherwise, the vision of continual release will remain stunted.

    New AI, Same Plumbing…

    No tech article today can mention developer productivity enhancements without a nod to AI. Just take the interest in Copilot, for example. Among GitHub Copilot users, 40% of the code they’re checking in is now AI-generated and unmodified, according to a Microsoft executive. And GitHub reported that 88% of Copilot users feel more productive when using the tool.

    In contrast to past hype cycles, the latest AI wave is not just a passing fad—it will have long-lasting effects, said Exterman. However, most of our current DevOps processes were constructed for manual code writing, not for the era of AI-assisted development.

    If you quadruple the amount of water you use but use the same plumbing system, you can’t push more water through, said Exterman. Similarly, if you amplify the amount of code you’re producing but don’t evolve your build processes, staging and testing, then DevOps suddenly becomes the new blocker.

    Ways to Accelerate Developer Velocity

    So, how can we improve development efficiency and productivity in the age of AI? Here are some actionable strategies for overcoming these bottlenecks and improving developer velocity.

    Accelerating the Plumbing

    Exterman stresses the importance of leveraging AI to enhance the foundational processes of development. This involves using techniques such as distributed computing and smart test selection to streamline build and testing processes. By optimizing these foundational steps, development teams can ensure that their coding efforts translate into efficient and rapid progress.

    Optimizing Testing through AI

    AI’s potential not only lies in code generation—it extends to optimizing testing processes. Exterman suggests tools like Launchable that allow AI to prioritize tests that matter most. This strategic approach to testing enables teams to focus on high-impact areas while maintaining comprehensive test coverage.

    Embracing Test Automation

    Exterman underscores the importance of comprehensive test automation. Rapid iteration loops are essential for maintaining velocity, and automation facilitates fast feedback cycles. This approach ensures that each code change undergoes rigorous quality checks, preventing errors from propagating downstream.

    Keeping an Eye on Technical Debt

    One of the potential downsides of increasing programming velocity is the accumulation of more technical debt. As more development occurs, the temptation to compromise on documentation, unit testing and best practices grows. Exterman emphasizes that velocity must be pursued in tandem with managing technical debt to ensure the long-term health of projects.

    Investing in Platform Engineering

    Recently, we’ve witnessed a paradigm shift toward platform engineering. Just over half of IT organizations have already embraced platform engineering, according to the 2023 State of DevOps Report. Exterman emphasizes the need for a robust internal developer platform that supports the seamless transition of code from development to staging and production. For instance, tools like Terraform and Earthly play a pivotal role in establishing testable environments and reproducible builds.

    “Bring more data services closer to the developers,” said Venkat Ramakrishnan, VP, product management and engineering, Portworx by Pure Storage. “Choose platforms that provide easy-to-deploy services that developers can consume and provide visibility and control into the underlying costs.”

    Enabling Observability

    Observability, according to Exterman, is also important for gauging efficiency. The ability to continuously monitor and log processes enhances the overall development cycle. One report from Splunk even found that 64% report their investment into observability has exceeded their expectations. Tools from New Relic and Datadog, for example, offer insights that tie quality, delivery and productivity together, enabling teams to make informed decisions.

    Evolving CI/CD With Continuous Merge

    One method to progressing CI/CD is continuous merge, a new concept that can be implemented with tools like gitStream that aims to decrease the window between a pull request, review and merge.

    “CI/CD has done wonders to improve the quality and efficiency of the software development toolchain, but it mainly focuses on things that happen after code has been written and reviewed,” said Ori Keren, CEO and co-founder of LinearB. “Continuous merge is a mindset that extends CI/CD practices further upstream to improve the quality and efficiency of the code review process. We’ve reached a point where code review times frequently cause the most significant delays in the software delivery process; continuous merge is how we fix that.”

    Using Cloud-Agnostic Platforms

    Cloud-native development has become more popular as organizations seek to design software architectures bred for the natural scalability of the cloud. Simultaneously, both technology and business motivators are resulting in a multi-cloud condition. In this scenario, IT really needs agnostic, open platforms to retain flexibility and reduce bottlenecks.

    “Enable developers to build their apps in a cloud-agnostic way so they can scale their apps globally,” said Ramakrishnan. “Much of developer and app momentum is lost when scaling apps. Helping the application teams architect it right by providing cloud-agnostic application platforms like Kubernetes enables developers to move faster, scale faster and reach their customers everywhere.”

    Measuring Developer Velocity

    The above tips should help improve velocity, but how exactly should you measure success? Well, measuring developer velocity goes beyond simply tracking the number of points completed in a sprint, reiterated Exterman. He emphasizes the importance of focusing on the ability to deliver high-quality products to the market swiftly. He underscores the need for a fast feedback loop for addressing bugs and iterating quickly. AI plays a role here, too, aiding in test writing and enabling continuous delivery.

    End Benefits of Improved Developer Velocity

    Exterman concludes by highlighting the real-world benefits of increased developer velocity. Faster bug-fixing and release cycles, particularly crucial in industries like gaming, result in improved user experiences and customer satisfaction. He emphasized the significance of aligning key performance indicators (KPIs) and objectives and key results (OKRs) with the aspects that truly matter, promoting a culture of measured and sustainable progress.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    CareerBuilder.com

    Cognizant Technology Solutions
    Phoenix, Arizona
    Senior DevOps Architect
    $130,000 to $180,000

    Indeed.com

    IBM
    Research Triangle Park, North Carolina
    SAP DevSecOps SME
    $126,000 to $235,000

    Dice.com

    DGN Technologies
    Dallas, Texas
    Azure DevOps Engineer
    $110,000 to $115,000

    SimplyHired.com

    Sabre Systems
    Lexington Park, Maryland
    Cloud Engineer – DevOps
    $106,000 to $134,000

    LinkedIn

    Deloitte
    Miami – Fort Lauderdale, Florida
    Junior Cloud Infrastructure Architect
    $65,000 to $97,000

  • Oracle Bill is 5x Client’s Budget ¦ Toyota Out of Space

    Oracle Bill is 5x Client’s Budget ¦ Toyota Out of Space

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Birmingham looks like the Detroit of the UK—is it Oracle’s fault?
    Plus: Was Toyota’s factory failure caused by running out of disk space? (more…)

  • Despite Concerns, AI Increasingly Used to Build Software

    Despite Concerns, AI Increasingly Used to Build Software

    A survey of 1,001 senior technology executives, developers, and security and operations professionals published this week by GitLab finds 67% are working for organizations already using artificial intelligence (AI) to build software, with 60% of those respondents reporting their organizations use it every day. A full 90% said their organizations are either already using or plan to use AI to build software.

    More than half (51%) have already identified productivity as a key benefit, but 32% are also “very” or “extremely” concerned about introducing AI into the software development life cycle (SDLC).

    Those concerns included AI-generated code introducing security vulnerabilities (39%) and whether that code may not be subject to the same level of copyright protection as human-generated code (48%). A full 95% of senior technology executives said they prioritized privacy and intellectual property protection when selecting an AI tool.

    Most organizations will continue to move forward with AI, but nearly two-thirds of respondents (65%) who use or are planning to use AI for software development said their organization hired or will hire new talent to manage its implementation.

    A full 81% cited a need for training to successfully use AI in their daily work, with 75% of respondents saying their organization provides training and resources for using AI. However, a roughly equal percentage also said they are finding resources on their own.

    David DeSanto, chief product officer for GitLab, said it’s already clear that AI will have a major impact on productivity simply because 75% of a developer’s time is typically spent on activities that have nothing to do with writing actual code.

    Less clear is the amount of expertise required to use AI to build software. In some cases, development teams may need to master, for example, prompt engineering to automate DevOps workflows at scale, but in many more instances, it’s likely the DevOps platform will automatically execute the commands required.

    Regardless of approach, it’s clear that as the amount of code being created by developers starts to steadily increase, the need to leverage AI to manage DevOps workflows will become more acute. The challenge is the pace at which developers can leverage AI to write code is, for the moment, exceeding the pace at which it is being embedded into DevOps platforms.

    In addition, organizations must determine whether to converge DevOps workflows with the machine learning operations (MLOps) workflows used to build AI models that are integrated into applications. As more MLOps capabilities are added to the GitLab platform, it will become easier to achieve that goal and enable data scientists to work more collaboratively with DevOps professionals, noted DeSanto. Today, a cultural divide between two distinct IT cultures is slowing down the pace of AI innovation.

    One way or another, DevOps workflows are about to be transformed. The challenge now is determining which tasks and bottlenecks are likely to be eliminated by AI to enable DevOps teams to focus on managing applications at an unprecedented scale.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    Icertis
    Phoenix, Arizona
    Principal Azure DevOps Engineer
    $132,000 to $199,000

    SimplyHired.com

    Decision Sciences International
    Remote
    DevOps Engineer
    $130,000+

    Indeed.com

    Hewlett-Packard Enterprise
    Durham, North Carolina
    DevOps Engineer
    $124,500 to $286,300

    CareerBuilder.com

    CACI
    Oklahoma City, Oklahoma
    DevOps Platform Engineer
    $104,200 to $229,200

    Dice.com

    SPECTRUM
    Greenwood Village, Colorado
    DevOps Engineer
    $78,900 to $139,500

  • Internal Developer Platform (IDP) Reference Architectures

    Internal Developer Platform (IDP) Reference Architectures

    If you’ve been following the DevOps space recently, you’ve probably noticed the excitement brewing around platform engineering. Despite uncertainty in other areas of tech, it seems like platform engineering is poised for growth—Gartner even expects that by 2026, 80% of software engineering organizations will have established platform teams.

    The platform engineering idea hinges on an internal tooling system known as an internal developer platform (IDP), which platform teams own and operate and is exposed to developers to improve their efficiency, satisfaction and release fluidity. IDPs have been the talk of the town. But what does an IDP actually look like? What sort of components are they usually composed of?

    Well, at PlatformCon 2023, McKinsey representatives shared a reference architecture for building out IDPs. This framework was modeled after hundreds of internal platforms and could be a helpful benchmark for other organizations as they begin developing and standardizing their internal developer platforms.

    Below, we’ll examine the sample IDP reference architecture and its components. We’ll also have a refresher on the platform engineering concept and offer some expert tips on overcoming potential obstacles while implementing platform engineering and IDPs.

    Why Engineer Internal Platforms, Why Now?

    First, for those new to the idea, let’s explain what platform engineering is. I’ve previously defined platform engineering as “maintaining an internal self-service platform that serves the needs of developer consumers.” The practice doesn’t necessarily supplant DevOps, rather, the experts I’ve spoken to view it as the next evolution.

    This trend is essentially a response to developers overseeing more and more aspects of software life cycle management. Complexity in enterprise-level software delivery workflows has escalated in the last decade, leading to what The State of Platform Engineering Report describes as “increased cognitive load on engineers.” This is negative, as it could lead to shadow operations and burnout.

    The fact is, most developers require the same sort of technologies, which could be standardized across the board. For instance, take the consolidation around containers and Kubernetes, infrastructure-as-code and the need to implement similar build configurations and security policies across applications.

    By outsourcing the maintenance of tools for shipping and running cloud-native applications to a common platform, you take the burden off developers and free them up to code. Also, by centralizing DevOps tooling, you can enforce more governance and build out internal standards. Which should help reusability and overall deployment agility … at least, that’s the promise of it all. 😉

    Sample IDP Reference Architectures

    So, let’s turn to some real-world examples to see how this is being implemented. Mike Gatto, senior DevOps engineer, McKinsey, shared an internal platform reference architecture for AWS-specific environments:

    McKinsey’s Internal Developer Platform reference architecture

    As you can see, the architecture is divided into these subgroups. At a high level, they perform the following functions:

    • Developer control plane: This is the version control, where developers publish their code. They provide a workload specification (in McKinsey’s case, a Score file) that codifies specific configurations.
    • Integration and delivery: This includes the CI pipeline to build application code into a container and publish it to a registry. This notifies the platform orchestrator to initiate a build. Then, resources are provisioned. This area also includes a CD pipeline and infrastructure control plane.
    • Monitoring and logging: This plane includes tools for observability, analytics, and application performance monitoring.
    • Security plane: This area includes tools for secrets management, policies, and security vetting.
    • Resource plane: This plane encompasses cluster management, database tools, networking, and messaging architectures.

    “By separating developer and platform team concerns and allowing them to control the respective areas they’re experienced in separately, without requiring too much overlap,” said Gatto, “we’re making deployments more compliant and better aligned with client initiatives.”

    Humanitec has also created internal developer platform reference architectures for GCP and Azure, displayed below.

    IDP Reference Architecture for GCP
    IDP Reference Architecture for Azure

    PlatformEngineering.org has also expanded McKinsey’s original IDP reference architecture with a tooling landscape that adopts the same umbrella subgroupings but includes other pluggable tools.

    The Internal Developer Platform tooling landscape

    Roadblocks to Developer Platforms

    Starting from a blueprint could be a big help to rapidly construct IDPs. Yet, there will still be some potential roadblocks associated with adopting an internal developer experience platform. One of them is creating common platforms that actually cater well to all environments.

    “You can not and should not try to please everybody,” said Kaspar von Grünberg, CEO and co-founder of Humanitech. “Platform engineering is an 80/20 game.”

    “Platform organizations often face a lot of pressure when it comes to meeting demands for building more services that are both agile and agnostic to cloud and data center environments,” said Venkat Ramakrishnan, VP, product management and engineering, Portworx by Pure Storage. “At the same time, almost all platform engineering teams are understaffed while facing the need to support large application development initiatives and developer teams twice their size.”

    Tips to Get Platform Engineering On Track

    Reference architectures for various clouds could help cater IDPs to different scenarios. But outside of that, it will take a product mindset approach to strategically accept feedback and iterate the platform. This will involve doubling down on developer experience and adopting cloud-native foundations that can scale.

    “Platform engineering teams must consider adopting Kubernetes as it enables them to manage and deploy applications in production at scale, without having to manage applications at the individual level,” added Ramakrishnan. “Additionally, it may not be realistic to expand platform engineering teams alongside growing platforms, so teams should also consider leveraging automation and self-service capabilities to help them better manage projects at scale.”

    Is ‘You Build It, You Run It’ Dead?

    The idea of ‘you build it, you run it’ is starting to look a little antiquated next to the new and shiny platform model. It’s tough to say, but I’ll be keeping an eye on this area to see if all the effort to standardize the internal engineering approach pays off!

  • Broadcom Survey Surfaces Drive to Consolidate Automation Platforms

    Broadcom Survey Surfaces Drive to Consolidate Automation Platforms

    Broadcom this week published a global survey of 535 IT leaders that found more than three-quarters (78%) are moving to consolidate cloud automation tools and platforms. However, thus far, only 8% of respondents said they had completed that effort.

    Overall, the survey also found more than 81% already have multiple cloud automation solutions in place, and 70% noted this issue had created significant challenges, including increasing time to automate (59%), time to report (52%) and time to remediation (52%) and higher costs (49%). In addition, 46% noted it’s more difficult to troubleshoot IT environments, while 41% noted multiple tools increase compliance risks.

    IT teams also find that having multiple automation tools slows down software delivery (37%) and contributes to the over-provisioning of IT environments (32%).

    Aline Gerew, head of automation for the Agile Operations Division at Broadcom, said the multiple islands of automation that have evolved on various cloud computing platforms now need to be centralized to reduce the current level of friction in the cloud. Those efforts need to start with platforms capable of unifying observability across all the platforms employed, she added.

    The amount of consolidation that any IT organization can implement depends on the amount of political capital they have. In many cases, the applications and associated automation tools running in any given environment have been adopted by a department or business unit that exercises a lot of autonomy regarding IT. The issue that creates is multiple tools and platforms increase the total cost of IT. At a time when many organizations are experiencing economic headwinds, the need to reduce the total cost of IT naturally becomes a more pressing concern.

    Rather than consolidate automation tools and platforms, the simpler option is to deploy an automation framework that is designed to be integrated with the various tools and platforms that are already in place, noted Gerew. That approach enables automation to be applied at much higher levels of scale to reduce costs without forcing every arm of an organization to standardize on the same tools and platform, she noted.

    The survey found that, when it comes to cloud automation, the most important consideration factors are operational costs (62%), performance (53%) and operational efficiency (49%).

    Responsibility for cloud automation will naturally vary from one organization to the next, but the survey noted that 67% of respondents currently have a cloud architect on staff and another 33% are planning to hire one.

    That role is increasingly required as organizations find themselves managing a wide range of cloud computing environments, including software-as-a-service applications (57%), legacy applications that have been lifted into the cloud (56%), new cloud-native applications (46%) and legacy applications that have been refactored for the cloud (41%).

    It’s apparent that cloud computing environments are becoming more complex with each passing day. There may come a day when artificial intelligence (AI) helps reduce the level of complexity; in the meantime, IT organizations need to find ways to streamline the management of cloud computing environments. Today, those environments are made up of applications based on a wide range of increasingly divergent architectures as the rate of application deployments exceeds the retirement of legacy apps.

  • Cisco Aligns With Nutanix on Hybrid Cloud Computing

    Cisco Aligns With Nutanix on Hybrid Cloud Computing

    Cisco and Nutanix this week announced a strategic partnership through which the two companies will collaborate to advance hybrid cloud computing.

    As part of that agreement, Cisco is committing to making AHV virtual machine software from Nutanix available from the edge to the cloud, starting with the Cisco Unified Compute Systems (UCS) rack and, soon after, blade servers.

    Jeremy Foster, senior vice president and general manager of Cisco Compute, said via a software-as-a-service (SaaS) platform, Cisco will be able to centrally manage virtual machines from Nutanix alongside the other major virtual machines it already supports.

    In addition, the partnership will enable Cisco to apply multiple forms of artificial intelligence (AI) across a hybrid cloud computing environment, he added.

    Thomas Cornely, senior vice president of product management for Nutanix, said the goal is to provide IT teams with an opportunity to consolidate infrastructure across a hybrid cloud computing environment. In effect, Nutanix and Cisco are working toward converging the control planes across their entire respective portfolios, he added.

    The goal is to enable IT teams to streamline the number of platforms that need to be supported as part of an effort to reduce the total cost of IT, said Cornely.

    The issue that IT organizations regularly encounter is that each platform requires hiring additional IT personnel to manage. At a time when many organizations are encountering economic headwinds, there is a natural inclination to reduce the number of platforms as the size of the IT staff is reduced. Despite advances in automation, IT labor costs still represent the largest overall segment of any IT budget.

    It’s not clear how aggressively IT teams are consolidating IT infrastructure to reduce costs, but after more than a decade of continuous investments in IT, many organizations are discovering they are supporting a wide range of platforms. During a downturn, however, IT teams tend to more aggressively eliminate “snowflake” platforms that require unique skillsets to manage, noted Cornely.

    In the meantime, IT environments are also becoming more distributed as more workloads move to the network edge. Those workloads are not replacing applications running in on-premises or cloud computing environments, so the overall IT footprint will continue to increase. Given the chronic shortage of IT skills, the only way to effectively manage that IT estate will be to rely more on automation frameworks increasingly infused with AI.

    Each IT organization will need to determine for itself what level of automation to embrace, but Cisco is betting most will opt to rely on a SaaS platform provided by a vendor versus building and maintaining an IT management platform themselves. Regardless, legacy approaches that depend heavily on manual processes will increasingly give way to cloud-based platforms that can more easily manage workloads wherever they happen to be deployed.

    The issue now, as always, is funding the transition to new platforms to bring the total cost of IT back under control and eventually pay for themselves.

  • Grafana Labs Delivers Open Source Code Profiling Tool

    Grafana Labs Delivers Open Source Code Profiling Tool

    Grafana Labs this week released version 1.0 of an open source tool that collects data about an application’s code to aid debugging, troubleshooting and optimization efforts. The tool makes it simpler to identify the specific lines of code driving a process or task within an application.

    Ryan Perry, engineering director for Pyroscope at Grafana Labs, said Grafana Pyroscope 1.0 combines a tool acquired last year from a company he led with Grafana Phlare, a code profiling tool that Grafana Labs previously developed. The combination of the two tools provides a more precise code-tracking capability with an underlying database that is designed to scale horizontally, he added.

    For example, Grafana Pyroscope 1.0, which supports extended Berkeley Packet Filtering (eBPF) running on Linux systems, can now ingest, store and query workloads from any project of any size. Grafana Pyroscope 1.0 has already been used to profile more than 50,000 application instances at a rate of more than 6,000 unique profiles per second.

    The code profiling tool was added to Grafana Cloud Profiles, the hosted continuous profiling tool that Grafana makes available as a service, earlier this month.

    While the primary use case for Grafana Pyroscope is to troubleshoot applications, organizations are also using it to identify and then remove dead code within an application as part of a larger application modernization initiative, noted Perry. As updates to applications are made over several years, organizations frequently find that subsets of the application code are no longer needed, said Perry.

    The goal going forward is to add support for features such as flame graphs in GitHub pull requests, canary deployments, profile-guided optimization (PGO), integrating profiling with load testing tools such as Grafana k6 and integration with visual editors such as VS Code.

    In addition, Grafana Labs is committed to working with the OpenTelemetry project led by the Cloud Native Computing Foundation (CNCF) to ensure Grafana Pyroscope remains aligned with the OpenTelemtry effort to develop an OTel-native profiling tool. Grafana Pyroscope 1.0 will provide the ability to ingest data from that tool and contribute client-side instrumentation capabilities the company has developed.

    Grafana Labs is also working toward improving client-side software development kits (SDKs) to add more real-time agent management features, such as sampling controls, ad hoc profiling capabilities and alternative instrumentation options.

    Finally, Grafana Labs plans to improve eBPF integration for languages such as Python, Java and .NET.

    DevOps teams naturally spend a lot of time trying to optimize application performance and troubleshooting issues that arise long after an application is initially deployed. Code profiling tools are emerging as a tool that makes it much simpler to aggregate metrics, logs and traces and surface actionable insights that make debugging and troubleshooting applications much less tedious. The challenge is finding the time to identify and proactively address potential issues before they become another incident to manage.