devopsy.kinsta.cloud

Tag: enterprise

Enterprise Smart Contracts Have a Cryptography Problem. EY Just Built a Way Around It

The business case for smart contracts is building fast. Major financial institutions are using programmable, code-based agreements to underpin financial workflows, supply chain operations, and tokenization initiatives. Developers are being asked to prove the value.

But there’s a problem most organizations don’t fully see until they’re already stuck: Privacy.

Public blockchains are transparent by design. Every transaction is visible. That’s the feature that makes them trustworthy—and the reason enterprises can’t simply deploy business logic on one without first addressing confidentiality. If your competitors can see your contract terms, you don’t have a business case. You have a liability.

“B2B transactions operate with a degree of confidentiality,” says Clare Adelgren, EY Global Blockchain Leader. “If businesses are going to transact on a public blockchain, they need privacy—but they need privacy in a very distinct flavor.”

The flavor she’s describing is zero-knowledge cryptography. It’s a technique that lets one party prove a statement is true without revealing the underlying data. In a smart contract context, it means you can execute and verify business logic on a public chain without exposing your commercial terms to anyone who shouldn’t see them.

The problem is that zero-knowledge proofs are hard. Not hard, the way learning Solidity is hard — PhD-level mathematics hard.

The Skill Set Doesn’t Exist in Most Teams

“You need both in the room,” Adelgren says, referring to blockchain developers and cryptographers. “Those people, that talent, aren’t always available.” The typical enterprise engineering team—even a strong one—doesn’t include zero-knowledge specialists. And without them, building privacy-preserving smart contracts from scratch takes weeks. That’s assuming developers already know their way around Solidity and public blockchain infrastructure. Most don’t start from that baseline either.

The deeper issue is that you can’t build a business case without a proof of concept. And you can’t build a proof of concept if the privacy layer requires expertise your team doesn’t have. That’s the bottleneck: not interest, not tooling budget, not blockchain fundamentals. It’s a ceiling of cryptography skills that stops experimentation before it starts.

EY has been working on this problem for 10 years. The firm started investing in blockchain privacy research during the early days of crypto, with a dedicated R&D team of PhD mathematicians based in London. The result is two open-source tools now in the public domain: Nightfall, a zero-knowledge rollup for private token transfers on Ethereum, and Starlight, a ZK proof compiler that converts standard Solidity smart contracts into privacy-preserving applications.

Both are technically available to any developer who wants them. But “available” and “accessible” are different things.

“The coding is there for Starlight, but it’s very complex,” Adelgren says. “You need to understand it, integrate it into your flow, set up the environments, and run the proofing systems. That would probably take several weeks—depending on the complexity of your contract.”

The Sandbox Removes the Setup

In March 2026, EY launched the EY Blockchain Privacy Sandbox: A web-based environment that puts Starlight’s capabilities in front of developers without the configuration overhead. No local installation. No environment setup. Developers bring an existing Solidity contract, annotate the fields they want to keep private, and run the transpiler. Outcomes: a privacy-enabled version of the contract, with API endpoints included and ready for integration.

“You suddenly don’t need to worry too much about the complexity of the math that sits behind the zero knowledge,” Adelgren says. “You can play in the sandbox, see how it’s working, and start building your business case.”

The result is a working proof of concept in under an hour. That matters because the POC is the point. This isn’t a production environment—it’s a validation tool. The goal is to let teams quickly understand what privacy-preserving smart contracts actually look like before committing engineering resources to a deeper build. What’s visible, what’s hidden, how the logic behaves, where the access controls live—those questions get answered in the sandbox before they become expensive to answer later.

Interest in ZK technology is accelerating. The global zero-knowledge proof market was estimated at roughly $1.3 billion in 2024 and is projected to reach approximately $7.6 billion by 2033, growing at a 22.1% compound annual growth rate, according to Grand View Research. The banking and financial services sector accounts for the largest share of that demand, which tracks with where enterprise smart contract interest is concentrated right now.

Where the Real Use Cases Are

Tokenization is the most mature entry point. Adelgren says EY already has clients doing it, and the tooling to support it is ready. Supply chain and financial workflow use cases are further out, partly because the transaction volume requirements are more demanding, and scalability in privacy-preserving systems is still developing.

She’s candid about it: “We’re still in the early days.” EY’s Nightfall technology can process blocks of transactions in anywhere from 6 to 20 minutes—workable for some use cases, not all. The path forward involves parallel processing and componentized infrastructure designed to scale as the architecture matures. Cost per transaction has already fallen significantly over the past five years, and she expects that trend to continue.

For engineering leaders who want to start experimenting, Adelgren’s advice is straightforward: Don’t wait for a blockchain specialist. Get experienced full-stack developers familiar with Solidity—AI coding tools can help close that gap quickly. For the zero-knowledge layer, use tooling like the Privacy Sandbox to run experiments rather than building from scratch.

The broader shift is worth paying attention to. About 12 months ago, something changed in the blockchain landscape. Crypto remains, but a more foundational layer is emerging: blockchain as a trust infrastructure for financial systems. Stablecoin adoption, tokenization, and programmable finance are advancing faster than most engineering teams realize.

“Don’t lose sight of what some of these big transformational changes are that are happening in the environment around you,” Adelgren says. “The job of a developer is changing a lot at the moment. And it’s super exciting.”

Developers who want to explore the sandbox can access it at blockchain.ey.com.

July 9, 2026
GitHub Removes PAT Requirement for Agentic Workflows

GitHub has quietly removed one of the more annoying friction points in agentic automation — and the security implications are worth paying attention to.

GitHub Agentic Workflows can now use GitHub Actions’ built-in GITHUB_TOKEN instead of a personal access token (PAT). That means developers no longer need to create, store, or rotate a PAT to run agentic workflows, eliminating both the operational hassle and the security risks that come with managing long-lived tokens at scale.

It’s a small config change. The security payoff is not small.

Why PATs Were a Problem

Personal access tokens have always carried risk. They’re long-lived, often broadly scoped, and easy to forget about. In an agentic context — where workflows run autonomously, touching repositories, triggering CI/CD pipelines, and interacting with sensitive resources — a leaked or misconfigured PAT can create serious exposure.

A recent arXiv paper flagged “agentic workflow injection” as an emerging attack vector, in which untrusted repository content is passed into agent prompts or downstream workflow logic. When a PAT with wide permissions is sitting in that environment, a compromised workflow becomes a much bigger problem.

The shift to GITHUB_TOKEN scopes things down by default. The token is short-lived, tied to the specific workflow run, and constrained by the permissions you define in the workflow file itself.

How the New Billing Model Works

The change also affects how AI usage gets tracked and billed. When an agentic workflow runs in an organization-owned repository using the Actions token, AI credits are billed directly to the organization rather than to an individual user. To enable this, organizations need to turn on the “Allow use of Copilot CLI billed to the organization” Copilot policy — which is on by default if the existing Copilot CLI policy is already enabled.

Developers configure this by adding copilot-requests: Write to the permissions section in the frontmatter of the agentic workflow markdown file, then recompiling and pushing the updated lockfile. Organizations also have access to cost management tools within GitHub Agentic Workflows to monitor, cap, and attribute token usage per workflow run.

That’s a meaningful shift for enterprise teams. It moves AI spend from individual developer accounts into organizational budgets, where it’s easier to monitor and control.

What GitHub Agentic Workflows Actually Do

GitHub Agentic Workflows let teams automate reasoning-based tasks — issue triage, CI failure analysis, documentation updates — using coding agents inside GitHub Actions. Workflows are defined in natural language Markdown files, which GitHub compiles into standard Actions YAML. Because they run as standard Actions, they reuse existing runner groups and policy constraints.

Agents run with read-only permissions by default. Safe outputs are applied via separate jobs with scoped write tokens, and a threat-detection job scans all proposed changes before they’re applied. The Agent Workflow Firewall blocks outbound traffic except to explicitly allowlisted domains.

The security model is layered, which matters for teams that need to run autonomous workflows across sensitive codebases.

Early adopters like Carvana are using the platform to automate work across multiple repositories, while Marks & Spencer has built a catalog of reusable workflows covering security, quality, and delivery that teams can adopt across any repo.

“Replacing personal access tokens with run-scoped Actions tokens moves agent authorization off individual developers and into the organization’s control plane,” said Mitch Ashley, VP and practice lead for software lifecycle engineering at The Futurum Group. “Agent authority is decoupled from any one person’s identity and bound to the run that exercises it. Platform teams now govern that authority at the level of each workflow run, defining and auditing what a run can touch and where its spend lands. The autonomy they grant agents is bounded by how precisely they scope and observe those permissions.”

The Bigger Picture

The PAT elimination is part of a broader push to make agentic workflows production-ready, not just experimental. Teams have been cautious about giving AI agents write access to repositories, and for good reason. But the combination of scoped tokens, sandboxed execution, and approval gates changes the risk calculus.

The challenge was never getting an agent to open a pull request — it was trusting the output enough to merge it. GitHub is building the controls that give teams the confidence to find out.

The feature is available across all Copilot plans, from Copilot Free through Copilot Enterprise. Teams already using GitHub Agentic Workflows should upgrade to the latest version of the CLI (gh extension upgrade aw) to access the new authentication option.

June 15, 2026
AI Is Here to Stay. The Real Challenge Is Operating It Securely
AI-generated code is already in production. Whether we are comfortable with that or not is beside the point. In the OpenStack project, which I have helped steward for more than 15 years, we are seeing developers submit patches built with AI assistance, and sometimes patches composed almost entirely by AI tools. Some of those contributions have already landed in the past release cycle. This is happening in one of the most rigorously governed open source projects in the world. It is happening everywhere else, too.

The code generation itself is not the problem. AI is genuinely good at producing computer programs because the structure of code is sufficiently predictable and syntactically constrained to play to the technology’s strengths. The problem is what happens next. Every AI-generated patch still needs to be reviewed for correctness, security, and long-term maintainability. And when code is easier to produce, more code gets proposed, which puts enormous pressure on the human reviewers who are the last line of defense before that code ships.

When AI Agents Break Traditional Trust Models

The volume of AI-generated code is only part of the “defense” challenge. The bigger disruption is AI agents: these software systems that act autonomously on your behalf are loosely directed by humans at the outset and then left to execute. Unfortunately, in our haste to adopt AI, we are quickly and casually granting these agents permissions we would never grant to a human assistant. Think about the trust models we’ve built over decades around the principle of least privilege. We’ve learned the hard way to establish robust fail-safe measures, such as requiring two keys to launch critical operations and multiple signatures for approval workflows. And now AI agents have come along, and we’re suddenly granting full access to our email, our databases, our production environments, and saying to these AI agents, “Sure, go ahead!” When something goes wrong, we discover the damage after the fact.

The point is that the shiny features of these AI tools are well ahead of their security features. The containment, the auditing, the ability to roll back what an agent did, and the ability to grant granular permissions rather than a wildcard to do anything: these capabilities remain underdeveloped. There is a wide-open field of innovation needed here.

So what do we do about it? We apply the same engineering discipline that has made complex software systems reliable for decades, and we evolve it for an AI-driven world. The open source ecosystem already offers the building blocks. I’d like to share two examples.

Project Gating: How CI/CD Keeps AI-Generated Code in Check

The first is Zuul, an open source system designed to properly gate code changes. Zuul was originally built for developing OpenStack in 2012 and is now used by organizations including BMW, Volvo, and Workday. Zuul was created to embed good software engineering practices directly into CI pipelines. It does not simply run tests after code is merged. It tests the future state of the codebase by running proposed changes together with their dependencies across multiple repositories before anything is allowed to land. If a change would break something downstream, Zuul catches it before it reaches the main branch.

Zuul’s approach was already valuable when humans wrote all the code, and it is essential now. As AI tools accelerate the volume of proposed changes, gating systems like Zuul ensure that the pace of contribution does not outrun the integrity of the system. The more code we produce with AI, the more we need automated enforcement of the practices that keep software manageable, secure, and functional. You cannot scale human review indefinitely, but you can build the most critical checks directly into your delivery pipeline.

This is already working in practice. Monty Taylor, one of the original architects of OpenStack’s CI infrastructure, has been building with a team of AI coding agents since late 2025 using the same toolchain and workflow he has used for fifteen years. All changes go through code review in Gerrit, where AI review agents leave their feedback just like any other contributor. Zuul gates every commit regardless of who or what wrote it. Production deploys happen automatically after gated integration tests pass. As Monty put it in a recent blog post: “Agents deleting databases isn’t an agent problem, it’s a system problem.” The problems AI agents bring are not new. What matters is whether you have the systems in place to catch them.

Hardware Isolation for AI Workloads: Why Containers Alone Are Not Enough

The second example is Kata Containers, an open source project launched in 2017 to provide “the speed of containers, the security of VMs.” Kata Containers provides hardware-level isolation for container workloads. Whereas standard container runtimes share the host kernel (which means a workload that escapes its limited boundaries can move laterally across the system), Kata Containers runs each workload inside a lightweight virtual machine, giving it its own dedicated, simplified kernel. What’s great about using Kata Containers is that the performance trade-off is minimal, but the security gains are significant.

This matters enormously for AI workloads. Today, organizations recognize that their proprietary data is one of their most valuable assets, and they are using AI to process it to inform business decisions. In multi-tenant environments, you do not want the data being processed by one AI agent to leak to another, and you do not want the infrastructure provider to access your precious data either. Kata provides protection of the host from the workload, and, through confidential computing, protection of the workload from the host. Both directions matter when the data being processed is, as people like to say, the new gold.

The industry momentum behind this approach is hard to ignore. NVIDIA runs its container-based AI inference workloads inside Kata Containers whenever they operate in multi-tenant environments. Google recently launched Agent Sandbox, a Kubernetes-native framework for isolating AI agent workloads, and it integrates directly with Kata for VM-backed isolation. The Kubernetes community has adopted Agent Sandbox as a CNCF project. When organizations at this scale converge on the same architectural pattern, it is worth paying attention.

What Enterprise Teams Should Do Now

There is one more dimension to operating AI securely that is worth underscoring. Both Zuul and Kata Containers are developed under open, neutral governance, in which no single company controls the roadmap. That matters for any infrastructure investment, but especially for the tools you trust to validate and contain your AI workloads. If you are making a significant investment in running your code production pipeline through a gating system or running your AI agents inside an isolation framework, you do not want that investment to depend on a single vendor that might change its licensing, its pricing, or its strategic direction. We have seen exactly that happen repeatedly in recent years, sometimes resulting in tenfold price increases for locked-in customers. Collaboratively governed open source removes that risk.

For organizations confronting these challenges today, a few starting points stand out:
- Enforce the principle of least privilege with your AI agents the same way you would with human users; do not give them blanket access to systems and data just because the configuration is easier that way.
- Adopt tooling like Zuul that builds software engineering discipline directly into your pipelines, so that quality checks do not depend on human bandwidth alone.
- Run AI workloads under stronger isolation—using agent sandboxing and Kata Containers, for example—particularly in multi-tenant environments like public clouds, or when processing sensitive or regulated data.
- Keep good backups and disaster recovery processes. AI agents will make mistakes at least as frequently as human operators, and the ability to restore systems to a known good state will be more important tomorrow than it is today.
AI is already reshaping how software is built and operated; that train has left the station. Our onus is to build the infrastructure to operate it securely. The open source tools exist. The engineering principles exist. What is required now is the discipline to apply them and to continue developing them collaboratively in the open.
June 13, 2026
Morgan Stanley Open Sources CALM: The Architecture as Code Solution Transforming Enterprise DevOps

Enterprise software development has long been plagued by a fundamental disconnect: the gap between architectural intent and actual implementation. Static diagrams gather dust while code evolves, compliance reviews create month-long bottlenecks, and architectural decisions become lost knowledge scattered across documentation that nobody reads. Morgan Stanley felt this pain acutely until they decided to solve it with code.

On August 15, 2025, Morgan Stanley open-sourced CALM (Common Architecture Language Model) v1.0 through FINOS, marking a pivotal moment for the DevOps community. This isn’t just another tool release; it’s a battle-tested solution that has already streamlined over 1,400 internal deployments at Morgan Stanley and accelerated production timelines by months.

The Problem: Architecture’s DevOps Bottleneck

“Architecture is a critical part of the software development lifecycle,” explains Trevor Brosnan, Morgan Stanley’s global head of technology strategy, architecture, and modernization. “Architecture decisions are complex to change, so getting it right the first time is imperative.”

Traditional architecture documentation creates friction in modern DevOps pipelines. Teams spend weeks navigating security reviews, compliance checks, and architectural approvals that should be automated. Morgan Stanley’s engineers grew weary of these software development holdups, recognizing the problem went deeper than code, all the way to the basic building blocks of applications.

The banking giant’s solution emerged from a simple yet powerful insight: if infrastructure can be code, and configuration can be code, why can’t architecture be code too?

CALM: Architecture as Code Reimagined

CALM enables software architects to define, validate, and visualize system architectures in a standardized, machine-readable format, bridging the gap between architectural intent and implementation. Built on a JSON Meta Schema, CALM transforms architectural designs into executable specifications that both humans and machines can understand.

The framework structures architecture into three primary components: nodes (services, databases, networks), relationships (how components interact), and metadata (additional context and constraints). This modular approach allows architects to model everything from high-level system overviews to detailed microservices architectures.

Distinguished Engineer Matthew Bain explains that CALM “translates the design of an application into code, automating and continuously updating design diagrams, applying security and compliance controls along the way.”

Real-World Impact: From Months to Minutes

The numbers tell the story. CALM has already supported more than 1,400 internal deployments at Morgan Stanley, significantly speeding up the process of getting apps from development into production and shortening review processes by months. More broadly across the industry, CALM is already being used to document architectures of existing systems, enable pattern-based automated security approvals, and has underpinned well over 2,000 application deployments.

The secret lies in automation. Instead of manually shepherding applications through compliance reviews, CALM enables pattern-based approvals. “If you don’t want to use CALM and you want to go and use something that’s not a standardized pattern, you’re going to have to involve all the risk people,” notes Jim Gough, distinguished engineer and API platform lead architect.

This approach transforms the economics of enterprise software delivery. Pre-approved architectural patterns become reusable assets, enabling teams to deploy confidently without reinventing security and compliance wheels.

DevOps Integration: CI/CD for Architecture

CALM’s true power emerges in its seamless integration with modern DevOps workflows. The framework treats architectural definitions like any other code asset, version-controlled, testable, and automatable. Teams can validate architectural compliance in their CI/CD pipelines, catching design issues before they reach production.

The CALM CLI provides immediate feedback on architectural decisions, enabling real-time validation during development. This shifts compliance left in the development lifecycle, transforming potential deployment roadblocks into preventable design issues.

Key benefits for DevOps teams include machine-readable architecture definitions that eliminate manual interpretation errors, version control for architectural changes that provides clear change history, and real-time feedback on compliance violations that prevent downstream issues.

Beyond Financial Services

While CALM emerged from Morgan Stanley’s financial services requirements, its applications extend far beyond banking. Any organization dealing with complex system architectures, regulatory compliance, or lengthy approval processes can benefit from architecture as code.

The framework addresses universal DevOps challenges: maintaining consistency across distributed teams, automating compliance and security reviews, accelerating deployment cycles, and creating reusable architectural patterns that encode organizational best practices.

As one FINOS contributor noted, “This one is a no-brainer for everyone. You can have validation of your architecture from your security team faster, which means you move faster to production, which is good for the business.”

“Morgan Stanley’s open-sourcing of CALM represents a genuine innovation that turns architecture into a machine-readable, dynamic asset rather than a static liability,” according to Mitch Ashley, VP and Practice Lead Software Lifecycle Engineering, The Futurum Group. “This move bridges a critical gap in enterprise DevOps by enabling automated security and compliance validation. In large, complex organizations, architecture-as-code could become the key to unlocking the next phase of agentic AI, where autonomous systems can now interpret and enforce architectural integrity.”

Getting Started with CALM

CALM is available now through FINOS as an open-source project. The framework includes a CLI for generating, validating, and visualizing architectures, along with comprehensive documentation and examples. Organizations can start small by codifying existing architectural patterns before expanding to full architecture-as-code workflows.

The timing couldn’t be better. As enterprises accelerate digital transformation initiatives, the need for scalable, automated architectural governance has never been greater. CALM provides the missing link between architectural intent and operational reality, enabling DevOps teams to move fast without breaking compliance.

Morgan Stanley’s decision to open-source this battle-tested solution represents more than corporate goodwill—it’s recognition that architecture as code benefits the entire industry. When deployment cycles accelerate and compliance becomes automated, everyone wins.

The question isn’t whether your organization needs architecture as code—it’s whether you’ll lead the transformation or follow it.

August 25, 2025
What Vibe Coding Means for the Enterprise: Fast Code, Real Considerations

AI coding assistants are rapidly changing how developers write software, with Gartner predicting that 75% of enterprise developers will be using them by 2028. This monumental shift is redefining the developer’s role — evolving it from code writer to system guide, validator and integrator.

At the center of this transformation is a buzz-worthy practice we all know as “vibe coding”: using AI to translate high-level ideas into working code quickly. It’s a powerful method for rapid experimentation, but as it moves from experimentation to the enterprise, it brings significant risks. The opportunity to accelerate innovation is here, but to seize it, enterprises must learn to harness the vibe without sacrificing quality and security.

What is Vibe Coding?

Vibe coding is the use of AI tools to rapidly assemble proofs of concept (POCs) or non-business-critical applications. Its primary focus is speed — getting something to work fast — meaning that code quality, security and maintainability often take a backseat. This approach allows for incredible velocity in prototyping and lowers the barrier to software development for quick experimentation.

However, when unmanaged in an enterprise setting, the fast-and-loose practices of vibe coding can lead to a rapid accumulation of technical debt, overlooked security vulnerabilities and integration failures with complex systems, creating a ticking time bomb in the codebase.

This approach is fundamentally different from what we might call structured “AI-assisted development,” where AI plays a substantial role but within an established, disciplined process. In this model, the developer acts as an architect and reviewer, guiding the AI to generate code that is then meticulously validated, secured and tested to meet stringent quality standards.

The Shifting Role of the Developer

Whether vibe coding or using AI coding assistants, more and more of the line-by-line generation is being done by AI. This does not replace developers, though; it elevates them. Developers now guide AI, evaluate its output, and ensure the resulting code fits coherently within larger, more complex systems. With AI generating code much faster than a human can, the developer’s verification workload has expanded dramatically. Their focus shifts from rote typing to meticulous design, rigorous validation and long-term maintainability.

This evolution demands a new set of skills. Prompt design, AI output validation, systems integration and deep architectural thinking are becoming paramount. Developers must become expert code designers, capable of understanding the nuances and potential pitfalls of AI-generated code and ensuring it aligns with established architectural patterns and business requirements.

Instead of replacing developers, AI tools are augmenting their abilities. According to a Stack Overflow survey, developers are already using AI to improve efficiency by 58% and productivity by 81%. This trend of augmentation over replacement is reflected in strong job growth projections from the U.S. Bureau of Labor Statistics, which forecasts a 25% increase in developer roles between 2022 and 2032.

The Risks of Vibe Coding at Scale

When vibe coding is adopted without guardrails, it introduces substantial risks that can undermine the very productivity gains it promises. A major concern is the lack of a deep understanding of AI-generated code. If the human developer doesn’t comprehend the why behind the code, it becomes a black box. This is a critical issue not just for human maintainers but also for other AI tools that need context to work effectively. It can also lead to “code rot” — code generated without human oversight that lacks structure, contains hidden vulnerabilities, and is nearly impossible to maintain.

This lack of understanding creates a significant danger of introducing unvetted or insecure code into production. The financial impact of bad code is staggering: It’s estimated that poor-quality software costs the U.S. economy $2.41 trillion annually, with accumulated technical debt at around $1.52 trillion. Beyond code quality, enterprises must also address potential conflicts with legacy systems. New AI-generated code must integrate seamlessly with millions of lines of existing code, or it could cripple core business operations. Compounding these technical challenges is the issue of ownership. A lack of clear standards can result in ambiguity, making it essential to adopt a “you break it, you own it” mentality, where developers take full responsibility for all code they commit.

How Enterprises Can Adapt and Thrive

To harness the power of AI while mitigating its risks, enterprises must integrate it into a culture of structure and ownership. This begins with the foundational principle of accountability: developers must take full responsibility for the code they manage, whether they wrote it or an AI generated it. If it’s in their commit, it’s their responsibility.

This responsibility is upheld through reinforced human oversight, as AI is not infallible. Vigilant code reviews by disciplined teams are paramount for scrutinizing AI output and ensuring architectural integrity. This process must be supported by comprehensive documentation that explains not just what the code does, but why it is structured in a particular way. To make this oversight effective, developers should be equipped with robust tools that enforce coding standards and help find hard-to-detect issues that AI can easily miss. Automated tests and scans must be run consistently, including mandatory unit tests written in advance, and not by the same AI that produced the code. Finally, all these practices should operate within a framework of clear guardrails, where developers strive for simplicity and remove the unnecessary code often generated by AI.

Build Wisely

Vibe coding offers a tantalizing glimpse into a future of accelerated innovation. Its ability to boost speed and creativity is real, but this is only true when it is backed by sound engineering principles and an unwavering commitment to quality and security.

Enterprises should absolutely encourage AI experimentation. However, this must be done after establishing clear workflows, standards, and accountability measures — a mindset of “vibe, then verify.” Without these foundations, the short-term gains of vibe coding will be washed away by a downstream tidal wave of technical debt, security breaches, and system failures.

The future of software development is not one without developers. It is a future where developers are elevated and more critical than ever — serving as the ultimate guardians of quality, security and architectural integrity.

So, by all means, use AI. Try it. But build wisely.

August 7, 2025
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.

July 9, 2025
Breaking Through – Beating Mainframe Delivery Bottlenecks
The mainframe powers large – and vital – elements of the global economy. Mainframe DevOps and new innovations offer the potential for delivering greater value, faster. Yet market data suggests significant challenges in achieving it. What can be done to beat the bottlenecks in mainframe delivery?

The Mainframe: Powering the Future of Enterprise Computing

The mainframe market comprises thousands of well-known, successful organizations and institutions worldwide. These organizations span the financial services, insurance, retail, logistics, transportation, and government sectors, among others, serving millions of clients. Their IT infrastructure is among the most active, processing billions of transactions as they support vast areas of the global economy.

The core business systems of these organizations rely on the IBM mainframe, which is considered by reputation to be the most powerful and resilient machine available.

To learn more about the mainframe market and the opportunities—and challenges—it faces today, PopUp Mainframe recently commissioned a survey, conducted in 2025 by market researchers Vanson Bourne.

The survey revealed overwhelming loyalty to the mainframe platform and a positive outlook regarding the opportunities Linux provides on the mainframe by using the specialist processor IFL. The market responses showed a clear commitment to the mainframe, now and into the future:
- 98% rely on the IBM mainframe to run their organizations
- 94% confirm their potential to leverage additional workload capacity on specialist/Linux environments on Z
- 97% seek to increase the use of specialist mainframe processors
The Challenges Ahead

The same survey, though, highlighted areas of concern. Organizations face significant operational challenges across the mainframe delivery process. Nearly all respondents encountered difficulties during development and testing phases using the mainframe. Concerns over the availability of mainframe environments were widespread, while a third of respondents required four or more teams to complete mainframe deliveries. Additionally, 80% cited staffing and tooling limitations as hindrances to business operations.

The research further emphasized five strategic areas where the mainframe environment struggles to meet aspirations: cost efficiency, flexibility, speed of delivery, risk management, and sustainability. More than 80% of respondents indicated that improvements were needed in each area.

Addressing the Bottlenecks

PopUp Mainframe offers an innovative solution to these bottlenecks and their strategic impacts. It’s instantly available mainframe environment supports development, testing, training, and other typical mainframe activities, accessible with the click of a button. Functionally equivalent to mainframe z/OS, it runs on the customer’s choice of hardware, enhancing availability and usefulness.

PopUp addresses key bottlenecks head-on: in an ideal mainframe scenario, everyone involved in the SDLC—analysts, programmers, QA staff, business users, administrators, DBAs—logs into the mainframe to perform their tasks in sequence. However, in reality operational complexities and restrictions often hamper innovation and impede mainframe delivery. PopUp Mainframe addresses these complexities and provides instantaneous resources for those who need them by enabling dev, test, and training activities in a compatible, virtual mainframe environment.

Cornerstone Capabilities

PopUp Mainframe ensures compatibility with the mainframe z/OS environment it replicates. Key product highlights include:
- Integration with mainframe environments and tools, including IBM, BMC, third-party, and open-source DevOps tools.
- Full compatibility with z/OS applications.
- Support for data compliance and regulation using advanced masking technology, with the option to keep data on the mainframe.
- Easy access and availability, with environments up and running in minutes, supporting IT sustainability goals.
- Universal usability, accommodating both ISPF access and GUI IDE tools simultaneously.
PopUp Mainframe acts as a virtual mainframe environment, designed to support each organization’s unique selection of tooling for mainframe application delivery processes. To do so, the product will integrate with a wide variety of popular mainframe toolchain elements. For example, PopUp Mainframe supports mainframe DevOps setups using VS Code or IDZ as the developer IDE, and open-source tools like Galasa and COBOL Check for unit testing, with orchestration tools such as GitHub managing these processes.

Fully flexible and scalable, the solution allows organizations to deploy as many PopUp Mainframe instances as needed. Two editions of the PopUp Mainframe product are available: Z edition (Linux on Z or LinuxOne installation) and X edition (x86 on premise or cloud installation).

Revolutionary Results

The opportunity for improvement by using PopUp Mainframe is both instantaneous and significant: one client demonstrated the solution’s efficacy by completing a POC in a single afternoon. Another client significantly improved delivery speed by several hundred percent. Other observed outcomes show PopUp Mainframe has helped clients meet several strategic goals:
- Accelerate development and testing while protecting production MIPS.
- Initiate development, testing, training, and R&D projects flexibly and quickly.
- Quadruple mainframe deliveries through efficient resource usage.
- Ensure data compliance in mainframe testing by keeping data on Z.
- Enhance sustainability and reduce emissions by deactivating unused environments.
Futurum Research Perspective

“Hosting critical time- and availability-sensitive business functionality on the mainframe remains a vital part of IT in the enterprise and much of the public sector,” said Guy Currier, Analyst, The Futurum Group. “But change management on the mainframe can be slow and inefficient, especially as business complexity and regulatory pressures increase. Innovative technologies such as PopUp Mainframe offer mainframe teams opportunities to accelerate the delivery velocity of their business-critical systems.”

Learn More

Watch our recent devopsy.kinsta.cloud webinar on demand to learn more about this topic. We will also be presenting at the forthcoming Tech Field Day Extra at SHARE Cleveland 2025 on August 19-20.

For further information, datasheets, and release highlights, visit the PopUp Mainframe website.
June 25, 2025
Best of 2024: Oracle Looks to Increase Pace of Java Innovation

With the latest release of Java, it should become simpler for DevOps teams that build and deploy applications with the most widely used programming language in the enterprise to innovate faster.

Georges Saab, senior vice president, Oracle Java Platform, said Java 22 is unique in the history of Java in that it is specifically designed to enable developers to invoke capabilities that are available in beta and preview while still working with the other functions supported in the venerable programming language. The overall goal is to increase the pace of innovation in environments based on Java applications, he added.

The latest edition of the Java Development Kit (JDK), for example, provides access in preview to capabilities developed under a Project Amber initiative that makes it simpler to express strings that include values computed at runtime while also improving the security of programs that compose strings from user-provided values and pass them to other systems.

Meanwhile, a Project Loom initiative, also available in preview, streamlines error handling and cancellation in a way that improves observability using an application programming interface (API) that enables structured concurrency, while a Scoped Values capability provides a way to share immutable data within and across threads.

A Project Panama initiative adds a Vector API that promises to compile instructions at runtime when, for example, making use of retrieval-augmented generation (RAG) techniques to extend artificial intelligence (AI) models.

In terms of additional capabilities that are now generally supported, Java 22 adds an API to enable Java programs to safely interoperate with code and data running in memory outside of the Java runtime.

Most importantly, from an application performance perspective, the latest iteration of the language streamlines garbage collection processes in memory to reduce the number of times a Java application might otherwise need to be paused.

Despite the number of alternative programming languages that exist, the bulk of enterprise-class applications continue to be built in Java. While many developers are at least familiar with multiple programming languages, most tend to favor one primary programming language. Java developers, especially, have shown little inclination to abandon the language even as other programming languages, such as JavaScript, have emerged that are either simpler to use or, as in the case of Rust, may provide more robust security capabilities.

Less clear is at what rate developers are upgrading to the latest iteration. In some cases, developers are still making use of version 8, 11 or, more recently, 17. It may be a while before the bulk of Java developers are ready to make the jump to Java 22. In addition, DevOps teams will then need to decide when there is enough critical mass to warrant upgrading runtime environments to support another iteration of Java.

One way or another, either via an edition of Java provided by Oracle or another vendor, the programming language isn’t likely to be supplanted any time soon. The challenge now is providing support not just for the various versions of Java that might be running but, inevitably, all the other software artifacts written in various languages that are now also routinely moving through DevOps pipelines.

January 3, 2025
Oracle Looks to Increase Pace of Java Innovation

With the latest release of Java, it should become simpler for DevOps teams that build and deploy applications with the most widely used programming language in the enterprise to innovate faster.

Georges Saab, senior vice president, Oracle Java Platform, said Java 22 is unique in the history of Java in that it is specifically designed to enable developers to invoke capabilities that are available in beta and preview while still working with the other functions supported in the venerable programming language. The overall goal is to increase the pace of innovation in environments based on Java applications, he added.

The latest edition of the Java Development Kit (JDK), for example, provides access in preview to capabilities developed under a Project Amber initiative that makes it simpler to express strings that include values computed at runtime while also improving the security of programs that compose strings from user-provided values and pass them to other systems.

Meanwhile, a Project Loom initiative, also available in preview, streamlines error handling and cancellation in a way that improves observability using an application programming interface (API) that enables structured concurrency, while a Scoped Values capability provides a way to share immutable data within and across threads.

A Project Panama initiative adds a Vector API that promises to compile instructions at runtime when, for example, making use of retrieval-augmented generation (RAG) techniques to extend artificial intelligence (AI) models.

In terms of additional capabilities that are now generally supported, Java 22 adds an API to enable Java programs to safely interoperate with code and data running in memory outside of the Java runtime.

Most importantly, from an application performance perspective, the latest iteration of the language streamlines garbage collection processes in memory to reduce the number of times a Java application might otherwise need to be paused.

Despite the number of alternative programming languages that exist, the bulk of enterprise-class applications continue to be built in Java. While many developers are at least familiar with multiple programming languages, most tend to favor one primary programming language. Java developers, especially, have shown little inclination to abandon the language even as other programming languages, such as JavaScript, have emerged that are either simpler to use or, as in the case of Rust, may provide more robust security capabilities.

Less clear is at what rate developers are upgrading to the latest iteration. In some cases, developers are still making use of version 8, 11 or, more recently, 17. It may be a while before the bulk of Java developers are ready to make the jump to Java 22. In addition, DevOps teams will then need to decide when there is enough critical mass to warrant upgrading runtime environments to support another iteration of Java.

One way or another, either via an edition of Java provided by Oracle or another vendor, the programming language isn’t likely to be supplanted any time soon. The challenge now is providing support not just for the various versions of Java that might be running but, inevitably, all the other software artifacts written in various languages that are now also routinely moving through DevOps pipelines.

March 26, 2024
6 Transformative Mainframe Predictions for 2024

The success of organizations in today’s digital economy demands speed — the ability to quickly respond to market trends with new applications and services, instant access to critical data, and resolution of issues even before they affect service. As we move into the new year, the adoption and adaptation of emerging technologies on the mainframe will enable enterprises to embrace changing market forces, turning them into a competitive advantage.

Below are six predictions of how mainframe organizations will leverage new technologies to advance the platform in 2024.

Prediction: AI/ML Adoption Grows

The roles of artificial intelligence (AI) and machine learning (ML) and their adoption across the mainframe, from application development to monitoring to data management, will continue to grow.

The generative AI revolution is real and here to stay. In the coming year, organizations will continue to explore best-use cases for its integration into mainframe management. Development teams will leverage key AI-recommended insights into automated workflows and code generation, improving developer productivity. Database administrators (DBAs) will look to automate data management processes to efficiently handle the demand for the diverse datasets required by generative AI tools, and mainframe operations teams will increase their reliance on AI-driven predictive analytics and root cause analysis.

As adoption increases and experience is gained, organizations will work past their AI trust issues and begin to harness the power of automation to become a fully autonomous digital enterprise. At the same time, there will be a growing need to govern AIOps and MLOps to ensure the validity and accuracy of ongoing model development.

Prediction: DevEx Comes to the Forefront of Companies’ Innovation Strategies

With the long-awaited shift of mainframe workforces from those with decades of experience to a new generation of stewards now in full effect, organizations will find a new imperative to attract and retain top talent by providing developers with familiar tools and development environments.

Professionals who have recently graduated from college or are moving from other platforms bring with them an expectation of integrated and automated DevOps practices. The move towards enterprise-wide DevOps and continuous integration and continuous deployment (CI/CD) pipelines will continue, with many companies also looking to employ cross-platform tooling. By giving developers the freedom to use their integrated development environment (IDE) of choice, organizations can decrease onboarding time and get new mainframe developers up to speed faster, enabling them to understand code and its function quickly and easily, and creating a seamless, frictionless way to make changes, debug, and deploy.

Prediction: Database DevOps Bridges the Gap Between DBAs and Developers

Changing customer demand and the need for agility will accelerate the drive for developers to seamlessly access and manage data sources. The demand for an agile development environment that extends from applications to databases will increase the inclusion of database DevOps in CI/CD pipelines, including version-controlled database schemas and data, automated database provisioning, and database testing as part of the pipeline.

By embracing agile practices, such as incremental database changes and rolling deployments, organizations will bridge the gap between DBAs and developers and ensure that mainframe databases evolve alongside application code. This cohesive approach will enhance collaboration, reduce conflicts, and expedite application development, positioning mainframes as agile and adaptable components within the rapidly changing IT landscape.

Prediction: Democratizing Mainframe Data

The move ― and the need ― to democratize mainframe data, making it available to AI/ML analytics engines, will gain momentum.

Organizations have matured their data lakes and gained valuable insights from data housed on distributed and cloud platforms, but the efforts needed to extract and transform mainframe data stored on tape and virtual tape libraries (VTL) has left volumes of business-critical data behind. By operationalizing mainframe integration with the cloud, organizations can make it easier and faster to access mainframe data and transform it into open formats, making it accessible to analytics engines and AI/ML applications.

The ability to realize the hidden potential of data they already store will make cloud-based storage of mainframe data a prerequisite for enterprises looking to digitally transform their businesses and gain competitive advantage.

Prediction: Object Storage Becomes Critical for Security

Mainframe-dependent organizations will seek to integrate hybrid cloud object storage to fortify mainframe data protection against escalating cyberthreats and ransomware attacks.

In 2024, cyberthreats will almost certainly increase in number and sophistication. The European Union’s Digital Operational Resilience Act (DORA) seeks to ensure that organizations remain vigilant and protect their systems and their customers’ data against increasing threats.

With DORA set to come into effect in January 2025, and further regulations and guidelines on the horizon, managing mainframe data across diverse locations while prioritizing immutable data copies will be imperative. Organizations will pivot towards proactive strategies, aligning their mainframe infrastructure with hybrid cloud solutions to meet evolving compliance standards and shield against the growing sophistication of cyberthreats.

Prediction: Innovation Takes the Lead

Organizations will adopt ruthless prioritization, shifting focus from maintaining services and applications to building new ones for the future.

Having seen firsthand the success of ongoing mainframe modernization efforts, organizations will place a new focus on building skills and specialties that align with future goals and product roadmaps, putting them in a position to capitalize on coming trends and giving them the ability to quickly respond to changing market forces with innovative new products and services.

As companies mature their approaches to AI on the mainframe, many will turn to building “applied AI” teams tasked with developing proactive solutions to better analyze data and forecast trends. In short, organizations will think logically about how to embrace AI rather than being embraced by it.

In 2024, mainframe organizations will accelerate the adoption of emerging technologies like AI and the cloud to increase the adaptability, resilience, and efficiency of the platform while situating it for even greater success in the future. The mainframe will continue to be a platform of innovation, integrating with new technologies and practices borrowed from other platforms to further the evolution of a hybrid IT environment that meets and exceeds the demands of the modern digital economy.

The role of AI, the impact of data governance regulations, the mainframe skills gap, affordability, and interoperability requirements are all brewing a perfect storm around the mainframe that will mark 2024 as a year of significant transformation that will define the leaders from the laggards.

February 19, 2024