devopsy.kinsta.cloud

Category: Features

  • Spacelift Adds On-Premises Edition of Infrastructure Management Platform

    Spacelift Adds On-Premises Edition of Infrastructure Management Platform

    Spacelift has made available an on-premises edition of a platform for automating the provisioning and management of IT infrastructure that previously was only accessible via a software-as-a-service application.

    Company CEO Pawel Hytry said the on-premises edition of the platform satisfies both the requirements of highly regulated industries and the emergence of sovereign cloud requirements that stipulate data must remain within a specific geographic region.

    Regardless of whether this edition of Spacelift is deployed in a local data center or in a cloud service that ensures IT infrastructure is restricted to a single availability zone, the Spacelift observability platform can now be deployed in a way that satisfies any compliance requirement, he added.

    It’s not clear how many organizations that previously relied on a SaaS edition of the platform might be required to shift toward an on-premises edition because of sovereign cloud requirements that have risen in the wake of recent globe trade tensions. Organizations in Europe have now become especially sensitive to dependence on IT infrastructure that might reside in the U.S. out of fear that the U.S. government might impose additional restrictions in the form of, for example, a tariff on digital services.

    It’s also unclear how many providers of SaaS platforms might need to address similar sovereign cloud requirements, but it’s evident IT teams will soon have a lot more deployment options to consider.

    In the meantime, Spacelift is making a case for a platform that makes it easier to enforce best practices across the infrastructure-as-code tools that application developers routinely use to provision IT infrastructure. The challenge organizations are encountering is that much of that infrastructure is misconfigured in ways that enable cybercriminals to exploit vulnerabilities.

    Unfortunately, a recent Spacelift survey found that only 14% of respondents have fully implemented infrastructure automation best practices. The bulk of organizations, in fact, have simply created various islands of automation that they then attempt to manually integrate using multiple scripts, noted Hytry.

    Hopefully, with the rise of platform engineering, more of the management of infrastructure will become automated. A recent survey conducted by Futurum Research finds that adoption of platform engineering as a methodology for building and deploying applications at scale is gaining significant traction, with more than a quarter of respondents (26%) having mastered platform engineering, compared to 41% who are still working toward applying platform engineering across multiple projects. Another 24% are still working toward operationalizing a set of best practices for platform engineering, while 7% are just getting started.

    Roughly half of platform engineering teams provide cloud/multi-cloud management (52%) and dev/test/production environment support (48%). DevOps toolchains (43%), standard platform configurations (42%), and containers/Kubernetes (41%) support are also prevalent.

    Regardless of the approach to IT infrastructure automation, the need to unify the management of platforms has become a more pressing issue. Each platform an organization deploys tends to increase the total cost of IT simply because an additional team of IT professionals is usually required to manage it. Hopefully, as more artificial intelligence (AI) is applied to the management of IT infrastructure, the ability to scale those teams will significantly increase in the months and years ahead.

  • Secure Code Warrior Defines Security Rules for AI Coding

    Secure Code Warrior Defines Security Rules for AI Coding

    Secure Code Warrior has made available a set of security rules for application developers using artificial intelligence (AI) tools to generate code.

    Company CTO Matias Madou said the AI Security Rules made available on GitHub are intended to encourage developers to review code generated by AI for security issues that these tools may inadvertently introduce. Most AI tools were trained using samples of code that were randomly collected from across the web. As such, they can introduce vulnerabilities simply because they were trained using code that contains similar flaws, noted Madou.

    Additionally, the AI Security Rules encourage developers to establish guardrails that steer AI away from risky patterns and common security missteps, such as insecure authentication flows or failure to use parameterized queries.

    Previously, Secure Code Warrior has made available AI security training courses for application developers that Madou said will continue to be expanded.

    In general, AI coding tools have, from a cybersecurity perspective, plusses and minuses. AI coding tools are, for example, unlikely to introduce a SQL Injection vulnerability. In fact, there may come a day when this particular vulnerability is completely eliminated as AI coding tools become more widely used, noted Madou. However, AI coding tools also introduce other potential security concerns, including hallucinations.

    It’s not clear to what degree developers are relying on AI tools to generate code, but 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 organizations are exploring multiple paths to employing artificial intelligence (AI) capabilities across the software development lifecycle (SDLC). 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.

    In effect, there is now a battle underway between incumbent providers of tools and startup rivals for the hearts and minds of software engineers.

    Regardless of how code is written, an application developer remains accountable for its quality. The challenge is that over time there is often a tendency to trust the output of an AI coding tool too much. Inevitably, the code generated might not only contain vulnerabilities but might also be deeply flawed in ways that might prevent an application from running at all. Just as challenging, AI coding tools might not be of much help when updating existing application environments simply because they might not have enough context to generate code that will work, noted Madou.

    On the other hand, there are many developers that only have a rudimentary appreciation for security issues. AI coding tools in those instances can significantly improve the quality of the code that might otherwise have been created by an application developer.

    There is, of course, no going back. AI coding tools are here to stay. The real issue is putting the guardrails in place that minimize any security vulnerabilities or other types of flaws that might compromise the security of an application.

  • Chronosphere Streamlines Management of Log Data to Reduce Costs

    Chronosphere Streamlines Management of Log Data to Reduce Costs

    Chronosphere today added additional capabilities to its log management platform that enable DevOps teams to both reduce costs and surface more actionable insights.

    Alok Bhide, head of product innovation for Chronosphere, said Chronosphere Logs 2.0 provides DevOps teams with more granular control over how log data is collected and stored. The overall goal is to make it simpler for DevOps teams to not only leverage analytics to identify which log data is actually being used but also more easily correlate it with metrics, events and traces, he added.

    Additionally, Chronosphere has added a Logs Quotas tool that enables DevOps teams to enforce budget restrictions on individual teams all the way down to specific datasets.

    Most DevOps teams are already being overwhelmed by the amount of telemetry data being collected, an issue that will only become more challenging to manage as more cloud-native and artificial intelligence (AI) applications are deployed in production environments.

    There is, of course, no shortage of observability platforms, but as IT environments become more complex, the need for tools that go well beyond simple monitoring of pre-defined metrics to troubleshoot applications has become a lot more pressing. The challenge is observability platforms collect data at levels of scale that from a cost perspective quickly add up. As a result, managing telemetry data has become a significant challenge. Unfortunately, most DevOps teams are not going to be able to hire someone to optimally manage the flow telemetry data. Instead, that needs to be a core capability of the observability platform.

    Less clear in the longer term is to what degree observability will become a task assigned to an artificial intelligence (AI) agent rather than a DevOps engineer. There is no doubt DevOps engineers will need to review the findings of an AI agent that has investigated an incident, but much of the tedious effort required to sort through metric, events, logs and traces should become increasingly automated. Each DevOps engineering team will then need to decide how comfortable they are allowing another set of AI agents to automatically remediate issues as they are uncovered, noted Bhide.

    In the meantime, organizations have never been more dependent on software than they are today, but even as the number of applications being deployed increases, the size of the DevOps teams tasked with maintaining them continues to remain relatively stagnant. In fact, in an AI era where more applications are expected to be deployed in the next few years than the entire last decade, supporting all those applications will require an ability to investigate and, if necessary, remediate anomalies within minutes of being discovered. Legacy monitoring tools were never intended to provide forensics insights in near real time.

    Of course, convincing business leaders to invest in observability platforms can be a challenge. DevOps teams need to be certain that the cost of storing massive amounts of telemetry does not outweigh the benefits. After all, no matter how many issues an observability prevents, someone in the finance team will still be closely monitoring the cost of a platform that over time only continues to grow.

  • Atlassian Adds CLI Option to AI Agent for Building Software

    Atlassian Adds CLI Option to AI Agent for Building Software

    Atlassian has added a command line interface (CLI) option to provide application developers with a familiar construct for invoking Rovo Dev, its artificial intelligence (AI) agent for building software

    Part of a portfolio of Rovo Software Agents that Atlassian now makes available in beta, Rovo Dev completes and debugs code, creates tests, surfaces insights and explanations of code bases, makes suggestions to improve code and generates documentation. It is also integrated with Jira project management software and Confluence collaboration tools provided by Atlassian.

    Using a set of software engineering (SWE) benchmarks maintained by researchers at Princeton and Stanford, Rovo Dev achieved a 41.98% resolve rate across 2,294 tasks.

    It can also be integrated via a Model Context Protocol (MCP) Server to access external data sources capable of providing more context that might be needed to complete a specific task.

    Shuyin Zhao, vice president of product for Atlassian, said the goal is to provide a single agent capable of performing a wide range of tasks versus requiring developers to create workflows that require them to orchestrate multiple agents to build and deploy software. The more memory that can be allocated to an AI agent the more it is able to preserve context, she added.

    Longer term, as the reasoning capabilities provided by large language models (LLMs) continue to expand, the scope of complex tasks that can be assigned to that AI agent will also increase, noted Zhao.

    Eventually, many developers will find they will be spending more time reading and evaluating code rather than writing it themselves, she added.

    It’s not clear how widely AI tools are being adopted by software developers and engineers, but a Futurum Group survey found 41% of respondents expect generative AI tools and platforms will be used to generate, review and test code. The one thing that is certain is more developers than ever are using these tools to write code, but how much of that code is making it into production environments is unknown. In some instances, an AI tool might enable a developer to write better code than they can on their own. In other instances, it might create vulnerabilities or recommend using software packages that simply don’t exist.

    Additionally, even as more code is generated, the existing DevOps pipelines might not be robust enough to deploy software at higher levels of scale than what is already being achieved.

    None of that means AI agents won’t be incorporated into DevOps workflows, but it does mean there is still a considerable amount of effort required to re-engineer those processes in a way that is optimized for AI agents rather than human application developers.

    In the meantime, however, DevOps teams would be well-advised to start creating a list of tasks they are willing to delegate to AI agents, assuming there is some level of supervision. Otherwise, it’s all but inevitable that AI agents might generate the same issues that human developers create, albeit just at a different level of scale. The issue then becomes making sure the right governance policies are in place to prevent as many of those issues from arising in the first place.

  • AWS Extends Cloud Security Reach to Include DevSecOps Tools to Scan Code

    AWS Extends Cloud Security Reach to Include DevSecOps Tools to Scan Code

    Amazon Web Services (AWS) this week made Amazon Inspector, a code scanning tool for surfacing vulnerabilities that is designed to be natively integrated with GitHub and GitLab platforms, generally available.

    Announced at the AWS re:Inforce 2025 conference, Amazon Inspector combines a static application security testing (SAST) tool for analyzing application source-code with a software composition analysis (SCA) tool for evaluating third-party dependencies and an ability to scan infrastructure as code (IaC) for valid definitions.

    Findings from these scans are then surfaced both in the Amazon Inspector console and within the source code management platform as fast feedback for the developers.

    Mitch Ashley, vice president and practice lead for software lifecycle engineering at The Futurum Group, said the expansion of the DevSecOps capabilities provided by AWS into code, dependencies, and IaC enable a critical ‘shift left’ for cloud security, fundamentally embedding vulnerability management earlier into the development lifecycle. That unified approach addresses a long-standing challenge for DevOps teams by accelerating feedback and fostering truly secure-by-design applications, he added.

    Additionally, AWS also revealed it has made available under an open source license a software package, dubbed @verifiedpermissions/authorization-clients-js, that enables developers to implement authorization in Express.js web application APIs in minutes. That approach reduces the custom authorization code that developers would have previously needed to create on their own.

    Finally, AWS demonstrated how it is internally using Amazon Q Developer, an artificial intelligence (AI) agent framework, to identify vulnerabilities in code as it is being developed.

    George Argyros, applied science manager of AWS, told conference attendees Amazon Q Developer makes it possible to “squash bugs” early in the application development process in a way that ultimately serves to improve the quality of the code being created. The overall goal is review code at the time a pull request is made and then surface recommendations to mitigate any issue, with Amazon Q Developer also being used to create and test any patch required.

    It’s not clear how widely the DevSecOps tool and platform being provided by AWS have been adopted, but it’s clear the cloud services provider is now moving well beyond securing infrastructure. It’s still the responsibility of organizations to secure the applications deployed on the cloud, but AWS is making the tools and services needed to achieve that goal more accessible.

    Hopefully, there will even come a day soon when application development teams are routinely using AI tools to prevent vulnerabilities and misconfigurations from being created in the first place.

    In the meantime, however, DevOps teams need to be sure to review the code being generated by AI tools that have been trained using examples of code that is of varying quality. In one instance, that code might be better than what some developers might write on their own. In other cases, segments of code with known vulnerabilities might have been copied multiple times over. In fact, about the only thing that is for certain is that there will soon be more code than ever to scan and review as developers continue to lean on AI tools to create code that they are becoming less inclined to write themselves.

  • New Relic Adds Support for Model Context Protocol to Observability Platform

    New Relic Adds Support for Model Context Protocol to Observability Platform

    New Relic this week added support for the Model Context Protocol (MCP) to its observability platform to surface insights into artificial intelligence (AI) agents and applications.

    Originally developed by Anthropic, MCP is rapidly becoming a de facto application programming interface (API) for enabling interoperability between AI agents and other sources of data.

    New Relic has now incorporated MCP with its application performance monitoring to surface insights into AI agents and applications alongside its ability to monitor and observe legacy applications.

    Previously, New Relic had added an ability to observe large language models (LLMs), but via MCP it’s now able to extend the reach of that capability to AI agents and applications that access those LLMs. That capability makes it possible to visualize specific usage and patterns of the entire lifecycle of an MCP request, including invoked tools, call sequences and execution durations.

    Additionally, DevOps teams can identify which prompts are being invoked and what choices were made by an AI agent along with surfacing latency, errors and other MCP performance issues.

    New Relic AI Monitoring MCP support is now available in Python Agent version 10.13.0, with additional languages coming soon.

    In general, New Relic reports it has seen a steady 30% growth in usage of its AI monitoring tools quarter-over-quarter for the past year. The company has also seen a 92% increase in the number of unique AI models being used. However, the ChatGPT models provided by OpenAI accounted for 86% of all the LLM tokens being generated.

    Nic Benders, chief technical strategist for New Relic, said that level of activity suggests that OpenAI is well on its way to becoming a de facto standard, even as the number of AI models being made available continues to rapidly increase.

    It’s not immediately clear why one LLM might be preferred over another but OpenAI, in addition to making a steady stream of investments, has successfully generated a significant amount of brand recognition. That helps make OpenAI one of the first platforms that most organizations are going to look to when building an AI application, said Benders.

    However, there are use cases, such as coding, that lend themselves, for the moment at least, better to coding, he added.

    Less clear is the degree to which the various AI models that are available will gain enough traction to warrant the ongoing level of investment required to sustain them. IT teams should carefully consider what foundations they want to build and deploy AI applications on for the long term, noted Benders.

    Additionally, not every AI application requires the latest, and most expensive, LLM, said Benders. The cost of previous generations of AI models has declined considerably as more advanced models have become available. Many applications, however, may not require access to a more advanced model, especially when a previous generation will enable a developer to automate a task at a much lower cost.

    Ultimately, observability platforms will play a critical role in enabling organizations to track which AI models are being used for which use cases. The challenge now is understanding not only which ones are gaining traction among application developers, but just as importantly, the symbiotic relationship that exists between AI models and the IT infrastructure upon which they depend.