devopsy.kinsta.cloud

Author: Mike Vizard

  • Deepgram Enables Developers to Issue Voice Commands to DevOps Tools

    Deepgram Enables Developers to Issue Voice Commands to DevOps Tools

    Deepgram has developed a framework that leverages artificial intelligence (AI) technologies to enable developers to automate multiple tasks using a single voice command.

    Natalie Rutgers, vice president of product for Deepgram, said Deepgram Saga is essentially a voice operating system that can be layered on top of existing tools and platform that converts natural speech into a set of prompts that invokes the Model Context Protocol (MCP) developed by Anthropic.

    Via a single voice command, an application developer can verbally request, for example, to run tests, commit changes, deploy, and then update the team using any tool or platform that exposes an MCP server, thereby eliminating the need to type commands or switch between AI chat windows.

    Alternatively, an application developer can now verbally describe an idea, which Deepgram Saga transforms into a set of prompts for AI coding tools to then execute. Deepgram Saga will capture that stream-of-consciousness and transform it into structured documentation, tickets or pull request descriptions.

     

     

     

     

     

     

     

     

     

     

     

     

    Deepgram has been enabling developers to build speech-enabled applications for the better part of a decade but is now making an AI framework designed specifically for software engineering tasks. Deepgram Saga understands technical context, domain-specific terminology, and the nuanced terms that developers commonly use, noted Rutgers.

    It’s not clear just how readily application developers might give up their keyboards, but there are a wide range of tasks that many of them would probably prefer to verbally assign to an AI agent to complete. An application developer would still need to review that output generated by those AI agents but via a voice interface it now becomes easier to chain various tasks together to create a workflow.

    The pace at which application development teams are embracing AI is already accelerating. A recent Futurum Group survey finds that 41% of respondents expect generative AI tools and platforms will be used to generate, review and test code. Additionally, The Futurum Group finds that over the next 12 to 18 months organizations plan to increase spending on not only AI code generation (83%) and agentic AI technologies (76%) but also existing familiar tools that have been augmented with AI. Deepgram is essentially making a case for using a speech interface to accelerate the adoption of these tools by eliminating the need to master prompt engineering.

    Each developer will need to determine for themselves the degree to which they might be willing to give up typing altogether, but the one thing that is certain is many of them will be spending more time reviewing the output of AI agents than actually writing code and creating scripts they then have to maintain. That may require a significant amount of cultural adjustment and there may still be times when it is simply easier to type something than it is to verbally explain it.

    Regardless of any attachment developers might have to typing, the need to become more productive will almost assuredly force them to rely a lot less on keyboards when a faster speech interface for issuing orders to an army of AI agents is readily available.

  • Red Hat Woos Corporate Developers with Free Instances of RHEL

    Red Hat Woos Corporate Developers with Free Instances of RHEL

    Red Hat today launched an initiative intended to make a free distribution of Red Hat Enterprise Linux (RHEL) available to individual developers working within a corporate environment.

    Chris Wells, senior director of product marketing for RHEL, said the Red Hat Enterprise Linux for Business Developers program will reduce the level of friction that developers of corporate applications might otherwise encounter.

    Red Hat already has a long-standing developer program that is structured around organizations rather than individual developers. Rather than needing to become part of a program set up by an internal IT organization in collaboration with Red Hat, the Red Hat Enterprise Linux for Business Developers program provides application developers with direct access to a repository through which they can download up to 25 physical, virtual or cloud-based instances of RHEL. Previously, Red Hat also made available a free personal RHEL license option to application developers.

    The overall goal is to not only encourage developers to build applications using RHEL but also reduce the level of friction that might occur when applications are deployed in production environments that are based on RHEL, said Wells. Otherwise, a DevOps team would have to migrate an application developed on another distribution of Linux to RHEL, he added.

    Red Hat now provides access to instances of RHEL that can be deployed using traditional package management tools or as an immutable container. That latter approach tends to especially appeal to individual developers who would rather rip and replace a set of containers versus trying to apply a patch each time a new RHEL update is made available, noted Wells.

    There are, of course, any number of additional commercial services that application developers can also subscribe to if needed, he added.

    As always, there is an ongoing battle for the hearts and minds of application developers. In the wake of changes made to how Red Hat makes its offerings available to organizations, Red Hat is now clearly trying to make sure that application developers are able to build applications on top of its operating system without incurring any cost.

    It’s not clear how many application developers are building software on top of RHEL, but should application developers opt for a different operating system, Red Hat is concerned those platforms might one day supplant RHEL in production environments. Red Hat is also hoping that DevOps teams will encourage developers to build applications on top of RHEL to streamline application deployments.

    Regardless of motivation, making it possible for application developers to self-service their own for building applications is generally a good thing as long as it complies with existing corporate standards. The challenge is that many application developers when it comes to tooling have a lot of personal preferences that often fall outside the scope of those standards.

    Each organization will, naturally, need to determine how much freedom of choice they want to provide application developers, realizing, of course, that most of them have the resources and skills required to set up their own application development environments. Fortunately, it’s also not too long before most of those developers also conclude they would prefer to have somebody else manage those environments on their behalf.

  • Bitrise to Invest $3M in DevOps Cloud for Mobile Apps in EU

    Bitrise to Invest $3M in DevOps Cloud for Mobile Apps in EU

    Bitrise, a provider of a DevOps platform for building mobile applications, plans to invest $3 million to create data centers in the European Union (EU) that meet sovereign cloud requirements.

    Company CEO Barnabás Birmacher said Bitrise has spent much of the past year integrating its stack and consolidating the infrastructure it needs to support its platform in the U.S. Now, Bitrise is taking the next step toward ensuring that any data used to build a mobile application doesn’t leave the EU at a time when many organizations are either voluntarily deciding to depend less on IT infrastructure in the U.S. or are being required to use IT infrastructure in a specific geographic region.

    To satisfy those requirements, Bitrise is acquiring the server and storage infrastructure it requires, which is then housed in a data center facility in Amsterdam that is owned by a third-party provider. That approach ensures that at any point necessary those servers and storage systems can be moved to another data center, noted Birmacher.

    Regardless of location, the data centers will be based on the same Apple M4 and Linux-based infrastructure that Bitrise has built a DevOps platform on top of to streamline the building and deployment of mobile applications.

    It’s not clear how fragmented software engineering is about to become as teams are required to ensure that application development projects only access data located in specific regions. Many DevOps teams have been relying on software-as-a-service (SaaS) application platforms that are designed to scale out across multiple geographic regions as additional compute resources have been needed. With the rise of sovereign cloud requirements, however, providers of those platforms need to ensure that any data being accessed never leaves a specific region.

    That issue can be especially challenging for organizations that may have relied on highly distributed teams of developers that may reside in multiple countries.

    In fact, one of the reasons more organizations are relying on the managed DevOps services that Bitrise provides is to help minimize that complexity, said Birmacher.

    As the pace of mobile application development continues to accelerate, more organizations are looking to rely on managed DevOps services, added Birmacher. They simply can’t afford to not only only build a DevOps platform, but also maintain, update and secure it, he noted. That’s especially the case when it comes to building mobile applications simply because there isn’t a lot of forgiveness when it comes to, for example, having to rollback an application once it’s been made available in an app store, so ensuring that every test has been properly conducted is crucial, said Birmacher.

    Regardless of who actually manages a DevOps environment, the need to continuously update mobile applications created additional challenges. End users expect that new features and capabilities will be added at a regular cadence. The number of organizations that can afford to invest in their own DevOps environment, as a percentage of those building mobile applications, remains comparatively small. So for the bulk of them, the only way to ensure best software engineering practices are being consistently followed is, after all, to rely on a service.

  • Survey: Pace of Increased Adoption of GitOps Varies Widely

    Survey: Pace of Increased Adoption of GitOps Varies Widely

    A survey of 660 software development professionals finds 93% have embraced GitOps as a methodology for building and deploying software, with 68% planning to increase usage.

    Conducted by Octopus Deploy, a provider of an automation platform for releasing software, the survey finds another quarter (25%) plan to retain their current usage compared to 7% that plan to reduce or stop GitOps usage.

    Steve Fenton, director of developer relations for Octopus Deploy, said the survey also makes it clear that GitOps maturity levels also tend to vary considerably. For example, under one-third of organizations use GitOps across less than 20% of their production systems. The survey also finds only 35% of respondents that have adopted GitOps make use of continuous reconciliation and automatic rollback mechanisms. That suggests that many organizations might only be going so far as to house infrastructure-as-code (IaC) configurations alongside source within a centralized Git repository.

    GitOps, at its core, refers to the process of automating the provisioning and management of IT infrastructure using a set of best practices that extend to include IaC tools. Ideally, a GitOps workflow should ensure a system is managed declaratively, automatically pulls the desired state declarations from the source, stores that data in a way that enforces immutability and versioning, and then provides some way to observe those interactions.

    Once infrastructure is managed with code, it becomes easier to converge the management of IT operations and application deployment. Kubernetes, meanwhile, provides an ideal GitOps platform because it presents a standard set of application programming interfaces (APIs) that enable clusters to automatically pull code as required versus requiring an IT team to manually push code out to a platform.

    Regardless of the level of GitOps maturity, there tends to be a high correlation between adoption of GitOps and modern IT platforms such as Kubernetes, noted Fenton. In general, many organizations are typically inclined to rethink legacy processes whenever a new platform is adopted, he added. In fact, it’s not uncommon for a team that has adopted GitOps to deploy microservices-based applications to be working along software engineering teams that are using legacy approaches to deploy more monolithic applications, said Fenton.

    A GitOps workflow should ultimately make it simpler for IT operations to achieve continuous delivery of applications, a goal that has remained elusive despite the widespread deployment of continuous integration/continuous delivery (CI/CD) platforms. In fact, while CI is widely used to build applications, the percentage of organizations consistently using CD to deploy software has remained comparatively small.

    It’s not clear to what degree the rise of platform engineering as a methodology for managing DevOps workflows at scale might drive increased adoption of GitOps. The one thing that is certain is that as the pace of application development continues to accelerate in the age of artificial intelligence (AI), the need to revisit software engineering workflows will become apparent. The only issue to be resolved now is determining how much to revamp existing workflows versus opting to simply start over again from scratch.

  • Kusari Adds AI Security Tool to Inspect Code as Pull Requests Are Made

    Kusari Adds AI Security Tool to Inspect Code as Pull Requests Are Made

    Kusari has added an artificial intelligence (AI) tool that runs a security risk assessment every time an application developer makes a pull request.

    Company CTO Mike Lieberman said Kusari Inspector is designed to make it simpler for security to be shifted left toward application developers in a way that doesn’t impinge productivity.

    Most application developers care about security, but getting the information they need to ensure it has historically been problematic, said Lieberman. Kusari Inspector makes use of AI and dependency graph analytics to surface issues long before vulnerabilities and other structural flaws are incorporated into a software build, he said.

    Using a tool priced at $10 per seat per month, Kusari Inspector continuously learns about the codebase and individual application developer preferences, making it possible to generate instant, context-rich, annotated security reports with inline explanations for every new or updated pull request. Developers are then provided go/no-go guidance, remediation suggestions, and step-by-step instructions to mitigate risks such as exposed credentials, misconfigurations, typosquatted or maliciously named dependencies and prohibited licenses.

    In addition to identifying those issues, Kusari Inspector will also rank risky, low-trust, or vulnerable dependencies—direct and transitive—based on multiple data sources to provide developers with a deeper understanding of application security issues, said Lieberman. Developers via a natural language interface can also chat with Kusari Inspector to clarify findings, customize recommendations, and set security standards.

    Finally, Kusari Inspector will automatically generate and collect source data for a software bill of materials (SBOM) across all connected projects and repositories.

    The core Kusari platform leverages AI to identify dependencies and understand the blast radius of incidents using metadata it collects from throughout the software supply chain. That capability is now being extended further left to provide application developers with a tool that enables them to write more secure code.

    It’s not clear how much DevOps teams are investing in AI, but a recent Futurum Group survey finds that 41% of DevOps professionals expect generative AI tools and platforms will be used to generate, review and test code. A separate Futurum survey of cybersecurity leaders finds all are investing in software supply chain security, with application security posture management (ASPM) and DevSecOps automation and orchestration topping the priority list, followed closely by security composition analysis (SCA) tools, application programming interface (API) security and dynamic application security testing (DAST) tools. In addition, 30% of respondents expect to be piloting a software bill of materials (SBOM) initiative in the next 24 months/

    However, the source of the funding for these initiatives is becoming more of a shared responsibility, with only 21% of respondents reporting that security budgets are the sole source. In fact, half of the respondents (50%) noted that application development teams now own responsibility for application security.

    Overall, only 25% of respondents said there is limited collaboration with application development teams, resulting in occasional friction, compared to 59% that said there is good collaboration with room for improvement. Only 16% said there is a tight partnership based on shared goals.

    Hopefully, AI tools will continue to close that gap in a way that reduces the current level of stress felt today by all concerned.

  • Fast Code, Real Risks: Guardrails for AI-Generated Software

    Fast Code, Real Risks: Guardrails for AI-Generated Software

    Yonatan Arbel, developer advocate in the Office of the CTO at JFrog, dives into the potential risks and rewards of relying on artificial intelligence (AI) agents to build and deploy software.

    Yes, more code is shipping faster than ever, Arbel admits, but volume alone isn’t a win—each hastily synthesized line must still survive build servers, security scanners and production reality. “Not everything in life comes for free,” he reminds, framing AI acceleration as an IOU that must eventually be paid down with careful review.

    To drive the point home, Arbel shares a personal misadventure. While traveling, he used a “vibe-coding” platform to whip together a receipt-tracking app. The tool auto-generated an impressive login flow and slick UI, so he proudly shared the URL with friends—only to discover their receipts mixed with his the next morning. A quick code dive revealed an AI-written SQL query that fetched every user’s data instead of scoping to the current account, proving how easily privacy can be breached when humans skip the boring inspection step.

    From there, the conversation turns to guardrails. Developers are becoming “pilots with copilots,” Arbel notes, spending more time instructing chat windows than writing functions. That shift demands automated policy checks, dependency vetting and runtime governance so velocity doesn’t eclipse trustworthiness. DevOps teams must embed quality gates early and often, treating AI-generated packages and prompts just like any other third-party code subject to organizational rules.

    Arbel’s advice is pragmatic: Start small, review everything, and remember that speed without oversight is just a fast track to technical—and financial—pain. Used thoughtfully, AI can compress months of work into days, but only if teams stay vigilant, enforce context-aware policies and let security evolve in lockstep with the bots.