devopsy.kinsta.cloud

Tag: ai

  • 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.

  • Explanation First, Then Code Conversion: A Practical Guide to Mainframe Optimization

    Explanation First, Then Code Conversion: A Practical Guide to Mainframe Optimization

    Before you even think about code conversion, take a closer look at what you have—and let generative AI (GenAI) help you explain it. Here’s how to modernize your mainframe smarter, not just faster.

    The Real Challenge: Understanding Decades-Old Practices and Code

    If you’ve worked with mainframes for any length of time, you’ve seen it before: someone in the boardroom gets excited about “digital transformation,” reads a story about AI rewriting COBOL overnight, and suddenly there’s an urgent call to “move everything to the cloud.” But here’s the thing—mainframes aren’t relics, and the problem isn’t the platform. It’s the technical debt we’ve accumulated and the assumptions we make when we talk about modernization.

    Mainframes are, in fact, among the most modern, reliable, and secure platforms in existence. The real challenge lies in the decades-old practices, spaghetti code, and institutional knowledge gaps that have built up over time. And that’s what makes the dilemma of COBOL-to-Java conversion so tricky: what should move, what should stay, and what’s the smartest path forward?

    Let’s walk through a more balanced—and practical—approach to mainframe modernization, one starting with understanding and values explanation over blind translation, harnessing the power of GenAI to make the journey faster and safer for everyone involved.

    Why Mainframes Are Still Mission-Critical

    Despite what the “legacy” label might suggest, mainframes remain the gold standard for reliability, security, and transaction volume. Banks, insurance companies, healthcare providers, and governments depend on them every single day. They process billions of transactions, scale on demand, and deliver “five-nines” uptime that most cloud platforms can only dream of.

    But let’s be honest: the way many mainframe applications have evolved—layer upon layer of updates, urgent patches, and undocumented quick fixes—has made them harder to manage. The problem isn’t COBOL, the language is fine and easy to learn and work with; the problem is what we’ve done with the COBOL, its original architecture and the technical debt created by years of business-driven expediency.

    The Code Conversion Dilemma: Move, Modernize or Leave Alone?

    When it comes to mainframe modernization, there’s a natural temptation to see “COBOL-to-Java” as the one-way ticket to a brighter future. After all, Java skills are plentiful, Java tools are modern, and the cloud-native world loves Java. But that doesn’t mean every mainframe application should—or even can—be converted wholesale.

    Some applications thrive on the mainframe. They’re stable, rarely change, and benefit from the platform’s unique strengths. If they’re meeting business needs and running reliably, trying to move them off the mainframe may introduce more risk than reward.

    On the flip side, some workloads absolutely need to change fast, integrate with modern APIs, or scale horizontally. Here, code conversion or migration can unlock flexibility and accelerate digital transformation. The trick is knowing which is which—and having the discipline to act with intention, not impulse.

    Don’t Start with Translation—Start with Understanding

    Here’s where too many projects go off the rails: jumping straight to code conversion without first understanding what the code actually does. Mainframe systems often resemble a decades-long game of telephone—patched by generations of developers, with business logic buried under mountains of procedural code. Sometimes, the original authors have long since retired, and the documentation is cryptic (if it exists at all).

    Before You Touch a Line of Code, You Need a Map.

    That starts with inventorying your applications and their dependencies. What modules do you have? How do they interact? Which business processes do they support? And—crucially—which parts of the codebase are actually still in use?

    Visualization tools can help, letting you “x-ray” your environment to see data flows, dependencies, and forgotten dead code. But even with great tooling, you’ll need to extract and document the business logic—the real “why” behind every routine and module.

    Code Explanation vs. Code Translation: Why It Matters

    Let’s make a key distinction:

    • Code Explanation is about making legacy code understandable—turning cryptic COBOL into plain English so current and future teams know exactly what’s happening and why.
    • Code Translation is about rewriting that code into a modern language—COBOL to Java, for example.

    While translation grabs headlines, explanation is where the real magic happens. It’s about knowledge transfer: bridging the gap between decades of lost documentation and the future of your IT workforce. Without a clear explanation, translation risks turning one tangled mess into another—just in a different language.

    Documentation and visualization are vital here. Good explanation—whether created by human experts, AI-powered tools, or both—enables:

    • Faster onboarding of new developers
    • Fewer bugs and less risk during conversion
    • Easier future enhancements and troubleshooting

    Refactor Before You Rewrite

    Here’s a pro tip that can save months (and sanity):
    Don’t just translate COBOL to Java line by line. If you do, you’ll wind up with Java that’s just as convoluted as your old COBOL—only now it’s harder to debug because your Java team didn’t write it.

    Instead, treat this as a once-in-a-generation chance to refactor before the conversion. Clean up logic, modularize code, eliminate dead weight, and clarify intent before you begin translation. You’ll thank yourself later when your new Java application is actually maintainable.

    Generative AI: Accelerating (But Not Replacing) Human Expertise

    Generative AI is changing the game, especially in code explanation and (to a degree) translation. Stories like Morgan Stanley’s headline-grabbing AI-powered modernization show the promise—and the reality—of what’s possible.

    But here’s the big lesson: AI can’t replace the need for human expertise and business context. It is a tool that can automate some tasks to save time. Even the best AI can get you to a “working” translation, but human developers must validate, refactor, and optimize the results for efficiency, security, and compliance. 

    Where GenAI shines:

    • Automated code explanation: AI models can rapidly generate plain-language descriptions for modules, making lost business logic visible again.
    • Code visualization: AI-powered tools can map dependencies, call graphs, and data flows, giving teams an actionable blueprint.
    • Accelerated translation (with guardrails): AI can handle the bulk translation, but it’s up to the team to review, refactor, and ensure the result is “Java as a Java developer would write it.”

    Crucially, GenAI brings flexibility. Some teams may use custom-trained models to reflect their unique codebase and business logic; others may rely on curated public LLMs or on-prem solutions for compliance. The smartest organizations use a mix—always keeping humans in the loop.

    Finding the Balance: What Stays, What Goes?

    The “all or nothing” mindset—either move everything off the mainframe or keep it all as-is—just doesn’t hold up. The most successful organizations assess each workload on its own merit:

    • Stays on mainframe: Ultra-high reliability, security, or compliance needs; rare updates; existing skills available.
    • Moves to modern platform: Needs rapid iteration, cloud integration, or agility; technical debt is high; Java or modern language skills are abundant.

    Remember: the goal isn’t to chase trends, but to optimize for your organization’s real-world needs.

    A Checklist for Smarter Modernization

    Based on what works for leading enterprises (and what’s tripped up even the best teams), here’s a practical checklist for mainframe code conversion success:

    1. Inventory all applications and their dependencies—don’t leave room for surprises.
    2. Visualize code and data flows; identify dead code to retire.
    3. Extract and document business logic in plain English—use GenAI to help, but validate with experts.
    4. Refactor for clarity and maintainability before any translation begins.
    5. Assess security, compliance, and audit requirements for both source and target environments.
    6. Pilot automated translation on low-risk modules; learn and adjust before tackling mission-critical systems.
    7. Test rigorously: unit, regression, and performance tests are non-negotiable.
    8. Train your teams on new tools and languages—make the developers comfortable with them so they are part of their daily work.
    9. Tune for long-term maintainability and performance in the new environment.
    10. Govern the entire process, from policy to documentation updates.
    11. Engage business stakeholders early and often—business context is essential for prioritization.
    12. Iterate and improve—modernization isn’t a “one and done” project.

    The Human Factor: Still the Secret Ingredient

    No matter how advanced your tools, human expertise and business insight are irreplaceable. AI can speed up understanding and translation, but only people can validate, contextualize, and steer modernization in the right direction. Involve your domain experts, engage the business, and treat modernization as a team sport.

    Explanation First, Then Transformation

    Mainframe modernization isn’t about abandoning a “legacy”—it’s about transforming your organization’s most critical assets for the future. Start with explanation and understanding. Use GenAI to illuminate what’s hidden, bridge knowledge gaps, and accelerate the journey. But keep your eyes on the real goal: delivering business value, reducing risk, and empowering the next generation of technologists.

    Don’t let buzzwords or bandwagons rush you into a code conversion project. With the right preparation—and a healthy dose of human judgment—you’ll find the balance that works for your business, now and for years to come.

    Want to share your modernization story or compare notes? Let’s keep the conversation going. Mainframe isn’t just part of the past—it’s a vital platform for the future, and we get to shape what comes next.

  • 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.