I started using the Internet in the early 1990s, when it was mostly used by government officials and academics. Everyone was pretty friendly, and more importantly, everyone was themselves. There was even a system called the finger protocol, where you could look up (“finger”) other users on the network to learn their full names and email addresses and see if they were currently logged on.

Back then, users of the Internet were all out in the open. The notion of being anonymous didn’t occur to anyone. Needless to say, it was a very different Internet then.

At that time, most online discussions took place on Usenet using the grossly underrated and mostly forgotten NNTP protocol. NNTP allowed for easy-to-read, threaded conversations. Folks were pretty congenial because everyone was clear about who they were. But it wasn’t long before I ran into a guy who used the name Lord Khronos. This struck me as rather odd, but hey, if you want to use a silly name, okay.

The original Internet troll

But Lord Khronos was, not to put too fine a point on it, a jerk. He was combative, rude, and generally unpleasant to deal with. To make matters worse, no one knew who he was. He might very well have been the first Internet troll. 

And of course, he could get away with behaving badly because of his anonymity. Being anonymous let him feel free to be a jerk. People already tend to say things online that they would never say in person. Adding the layer of anonymity only makes that problem worse. If I use my real name and say something rude to a colleague online, I will have to deal with the consequences, maybe even face-to-face. But if I’m anonymous, I can say what I want without fear of any social reprisal. Hence, we get the ubiquitous Internet trolls. 

Now, a person certainly has the right to be anonymous. Many people have good reason to protect their identities online. Being anonymous does give one a certain freedom to say what might otherwise be very difficult to say.

But mostly, being anonymous just allows someone to be a rank jackass. 

Yet the problem extends beyond people being merely obnoxious. The cost to society is much greater. With the rise of AI, it is possible to use anonymity to create manufactured personas that can and do spread lies and misinformation. Nation states can and do try using false personas to influence public opinion on a large scale. Anyone can create thousands (or even millions) of accounts on social media and use automation and AI to rapidly produce a “grassroots” movement for a cause.  

And it has occurred to me that all of this happens because anonymity is free. In the world of social media, the incentives are plainly backwards. If you want to be anonymous, be a jerk, spread propaganda, and generally make others’ lives miserable, you can do it for free. But if you want to speak as yourself with a verified account, you have to pay for the privilege. 

Tax the jackasses

I want to suggest a simple fix. I’m no expert on the economics of the social media marketplace, but it seems clear to me that the incentives would be better aligned if the social media platforms charged for anonymity. If you want to create an account that does not use your real identity, then you should have to pay—even just a modest amount. Otherwise, you have to use your real name and identity.

Now, I realize this presents some problems, the most obvious of which is how one might go about proving that you are who you say you are, and how the platforms might avoid people presenting fake credentials. But plenty of services verify identity today—banks, crypto exchanges, government portals—so it’s not out of the question.

Maybe everyone should pay either way. I don’t know how it might work. There are many players with strong incentives—advertisers, influencers, politicians—who are invested in the status quo. I’m not saying overcoming the resistance will be easy or even possible. 

I do know that when the marginal cost of creating another anonymous account on Twitter is basically zero, we will inevitably get a whole lot of anonymous accounts on Twitter. Spam is a huge problem on the Internet because sending out a hundred million emails costs almost nothing. A Twitter account is no different.

Don’t get me wrong, I love a good shitposting account. Some of the wittiest and funniest content online is produced by anonymous users. But most of the bad, nasty, nefarious, dubious, dangerous, and destructive content on the Internet comes from the systematic use of online anonymity. 

Raising the cost of being a jackass and making people pay for anonymity on social platforms could shift the balance of incentives in a better direction. And maybe give civility and truth a fighting chance.

When you install Python packages into a given instance of Python, the default behavior is for the package’s files to be copied into the target installation. But sometimes you don’t want to copy the files—sometimes, you want to link to them, so any installed version of the package can be updated by simply editing the linked source.

This behavior is called an editable install, and it’s a powerful way to make use of a package at the same time you’re editing it. Any changes to the source for the package are instantly reflected everywhere it is installed.

Using editable installs to keep projects in sync

Here’s a common scenario: Let’s say you have a Python project named pythingy somewhere on your system—say, /usr/projects/pythingy or D:/dev/pythingy. You use pythingy as a utility in various other Python projects, but you’re also constantly working on and making changes to pything. It’s a pain to install and update copies of pythingy into multiple virtual environments every time you make a change.

What you really want is to have every virtual environment where you use pythingy just reference the original source directory for pythingy. When you make a change to the original source code, every linked copy is also updated, because they’re just pointers to the original.

Editable installs let you do exactly this.

To install a Python package in editable mode, all you need to do is use the -e flag, and pass the path to the package’s directory:

pip install -e /usr/projects/pythingy

The installation process should be no different. What will change is how the project is referenced when you use pip list on any environment where the project has been installed:

(.venv) PS D:\Dev\pythingy> pip list
Package  Version Editable project location
-------- ------- ---------------------------------
pip      25.1.1
pythingy 0.1     D:\dev\pythingy

The Editable project location path will indicate where the original source is for the installed project. (Unless you have editable-installed packages, you won’t see this column when you run pip list.)

The best part is, you do not need to run pip install --update on the package when you make changes—though there are a couple of exceptions we’ll discuss shortly.

Editable-installing a package into its virtual environment

Another useful practice when working on a project is to make an editable install of the project into its own virtual environment. To do this, just use pip install -e . from the root of the project’s directory.

Adding the project as an editable install to its own environment environment confers a few useful advantages:

• It replicates the behavior an end user has with the project. If we have pythingy installed into its own environment as an editable install, we can test aspects of the project that only show up when it’s been installed—such as entry point scripts (e.g., a pythingy shell command to invoke the package).
• You don’t have to use relative imports in the project itself. If pythingy is present in the namespace for the virtual environment where you’re working on it, you can use pythingy as a top-level namespace to import from. Aside from being unambiguous about where the import’s coming from, it avoids all the difficult-to-debug side-effects that crop up with relative imports. And again, it replicates the behavior the user will have when they install the project into a virtual environment.

Limitations of editable installs

Editable installs do have a few limitations worth keeping in mind.

It’s not recommended to use a remote endpoint (e.g., a remote git repository) for the source of your editable install. In other words, don’t do something like pip install -e git+https://github.com/foo/bar. If you want to use a remote git repo as a source, clone it locally, run pip install -e /path/to/clone, and keep the cloned copy in sync with its remote source.

Additionally, changing the source of an editable install does not automatically re-trigger any build actions for the source. This generally manifests with two key features: entry point scripts, which allow you to launch a Python package with a command from the shell; and Python extension modules, which are compiled (typically from C source). If your edits of the package source change either of these things, you need to re-run the installation process and re-trigger the build step before they’ll be updated: pip install -e -U /path/to/source.

The Zig programming language continues its gradual advance into the world of systems programming. Even though it has yet to hit version 1.0, Zig is already in use with several production projects and attracts admirers with its slew of good ideas and commitment to quality.

Started by Andrew Kelley in 2015, Zig is a very active project and now seems to be reaching critical mass. Its rather momentous ambition is to become the heir to the C programming language, which has reigned for decades as the go-to portable low-level language.

This article is a high-level introduction to Zig, including its design goals, memory and error handling, conditional compilation, interoperability with C and C++, and a feature update for the latest version as of this writing.

Could Zig replace C?

Zig is described as a “low-level systems language,” but what is low-level? Systems language is also fairly ambiguous terminology. I asked Loris Cro, VP of community at the Zig Software Foundation, how he describes Zig. He said, “I define Zig as a general-purpose programming language because, while it’s an obvious good fit for systems programming, it’s also suited for programming embedded devices, targeting WebAssembly, writing games, and even most tasks that would normally be handled by higher-level languages.”

Zig may be easiest to understand as it relates to C; that is, as a general-purpose, non-garbage-collected, and portable language with pointers. Today, virtually all programming infrastructure rests on C in various ways, including being the foundation of other programming languages like Java, JavaScript, and Python. If Zig were to be adopted broadly as an archetypal replacement for C, it could have enormous benefits. Just imagine the ripple effect of an industry-wide evolution to a language that is like C, but safer, faster, less buggy, and easier to maintain.

Zig’s design goals and syntax

Zig is a “close to the metal” language in that it allows developers to work directly with system memory, a requirement for writing code that can be maximally optimized to its task. Direct memory allocation is a characteristic shared by the C family, Rust, and other low-level systems languages. Zig offers similar capabilities but aims to improve on them in several ways.

Zig seeks to be a simpler systems-oriented language than its predecessors and make it easier to write safe, correct code. It also aims for a better developer experience by smoothing the sharp edges found in writing C-like software. On the first review, Zig’s features might not come across as earth-shattering. But in overall effect, it is a safer platform that developers are finding easier to master and use.

Currently, Zig is being used to implement the Bun.js JavaScript runtime as an alternative to Node.js. Bun’s creator Jarred Sumner told me “Zig is sort of similar to writing C, but with better memory-safety features in debug mode and modern features like defer (similar to Go’s) and arbitrary code can be executed at compile time via comptime. It has very few keywords so it’s a lot easier to learn than C++ or Rust.”

Zig is also used as the language for the TigerBeetle database. TigerBeetle’s rationale for choosing Zig describes Zig as “a DSL for machine code” whose compile-time features make it “very easy to directly express what you want the computer to do.” In essence, Zig lets you describe what the machine is doing very explicitly, with a minimum of extra syntax, without losing expressiveness.

Zig lacks an interface (or something similar, like Rust’s traits) to define contracts on types, which TigerBeetle acknowledges “comes at the cost of missing declaration-site interfaces.” According to TigerBeetle’s developers, this feature is “less important in a zero-dependency context.” Instead, Zig lets you do a similar kind of generic programming, checked by the compiler at compile time.

Other production projects using Zig include the Ghostyy terminal emulator and Uber, which uses Zig for builds. There are also examples of using Zig to speed up Python.

Zig differs from most other languages in its small feature footprint, which is the outcome of an explicit design goal: Only one obvious way to do things. Zig’s developers take this goal so much to heart that for a time, Zig had no for loop. That design decision has since changed, and Zig now has a fully functional for loop.

Kevin Lynagh, coming from a Rust background, wrote, “The language is so small and consistent that after a few hours of study, I was able to load enough of it into my head to just do my work.” Nathan Craddock, a C developer, echoed the sentiment. Programmers seem to like the focused quality of Zig’s syntax.

How Zig handles memory

A distinctive feature of Zig is that it does not deal with memory allocation directly in the language. There is no malloc keyword like we have in C and C++. Instead, access to the heap is handled explicitly in the standard library. When you need such a feature, you pass in an Allocator object. This has the effect of clearly denoting when memory is being engaged by libraries while abstracting how it should be addressed. Instead, your client code determines what kind of allocator is appropriate.

Making memory access an obvious library characteristic is meant to avoid hidden allocations, which is a boon to resource-limited and real-time environments. Memory is lifted out of the language syntax, where it can appear anywhere, and its handling is made more explicit.

Allowing client code to specify what type of allocator it passes into an API means the code gets to choose based on the environment it is targeting. That means library code becomes more obvious and reusable. An application can determine when exactly a library it is using will access memory, and hand it the type of allocator—embedded, server, WebAssembly, etc.—that is most appropriate for the runtime.

As an example, the Zig standard library ships with a basic allocator called a page allocator, which requests memory from the operating system by issuing: const allocator = std.heap.page_allocator;. See the Zig documentation for more about available allocators.

Zig also includes safety features for avoiding buffer overflows, and it ships with a debug allocator that detects memory leaks.

Conditional compilation in Zig

Zig uses conditional compilation, which eliminates the need for a preprocessor as found in C. Therefore, Zig does not have macros like C and C++. From a design standpoint, Zig’s development team views the need for a preprocessor as indicative of a language limitation that was crudely patched over.

Instead of macros, Zig’s compiler determines what code can be evaluated at compilation time. For example, an if statement will eliminate its dead branch at compile time if possible. Instead of using #define to create a compile-time constant, Zig will determine if the const value can be treated that way and just do it. This not only makes code easier to read, write, and think about but also opens up the opportunity for optimization.

As Erik Engheim writes, Zig makes compile-time computing a central feature instead of an afterthought. This allows Zig developers “to write generic code and do meta-programming without having any explicit support for generics or templates.”

A distinctive Zig feature is the comptime keyword. This allows for executing code at compile time, which lets developers enforce types against generics, among other things.

Interoperability with C and C++

Zig supports a high degree of interoperability with C and C++. As stated in the Zig docs: “Any language that does not have the ability to interact with C code risks obscurity.”

Zig can compile C and C++. It also ships with libc libraries for many platforms. It can build these without linking to external libc libraries. See this Reddit thread for a detailed discussion of Zig’s relationship to libc.

For an in-depth discussion of Zig’s C compiler capability, see Andrew Kelley’s blog post on the topic, which includes a demo of Zig compiling the GCC LuaJIT compiler. The bottom line is that Zig attempts not only to replace C with its own syntax, but actually absorb C into itself as much as possible.

Loris told me that “Zig is a better C/C++ compiler than other C/C++ compilers since it supports cross-compilation out of the box, among other things. Zig can also trivially interoperate with C (you can import C header files directly) and it is overall better than C at using C libraries, thanks to a stronger type system and language features like defer.”

Error handling in Zig

Zig has a unique error-handling system. As part of its “avoid hidden control flow” design philosophy, Zig doesn’t use throw to raise exceptions. The throw function can branch execution in ways that are hard to follow. Instead, if necessary, statements and functions can return an error type, as part of a union type with whatever is returned on the happy path. Code can use the error object to respond accordingly or use the try keyword to pass up the error.

An error union type has the syntax ! . You can see this in action with the simple “Hello, world” example (from the Zig docs):

const std = @import("std");

pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print("Hello, {s}!n", .{"world"});
}

Most of this code is self-explanatory, but the !void syntax is interesting. It says the function can return either void or an error. This means if the main() function runs without error, it will return nothing; but if it does error out, it will return an error object describing the error condition.

You can see how client code can use an error object in the line where the try keyword appears. Since stdout.print can return an error, the try expression here means the error will be passed up to the main() function’s return value.

Zig toolchain and testing

Zig also includes a build tool. As an example, we could build and run the above program with the commands shown here (this is again from the Zig docs):

$ zig build-exe hello.zig
$ ./hello
Hello, world!

Zig’s build tool works in a cross-platform way and replaces tools like make and cmake.

As of 2025, Zig’s build system includes an integrated package manager with a standard configuration file, build.zig.zon. It uses Zig Object Notation (ZON), the .zon file format, which you can learn more about here. ZON is like Zig’s take on JSON.

The standard command line is often sufficient for Zig programs, but the package manager lets you address situations where you might need to provide a package to be consumed by third parties, build many things, or where the build process contains many steps.

Evolving beyond LLVM

Zig originally was built on top of the LLVM toolset but has since moved to make LLVM an optional component. This helps to make the Zig language portable and more amenable to freestanding builds. This update is interesting because it implies the Zig toolchain is moving toward using Zig itself for much of the back-end infrastructure, what Zig’s developers are calling self-hosted Zig.

This means that where once Zig was largely a front-end language syntax to the LLVM, it is now an entire stack of tools that can take that front end and use different options for outputting the implementation to target systems. Most of those target operating systems have Zig back ends that are not dependent on LLVM, although you can still use LLVM and in some cases, C compatibility may still require it.

The tendency today is to use self-hosted for development, for the faster build times, then move to the LLVM for the most optimized runtime production build.

State of Zig

Zig has an active Discord community and a lively GitHub ecosystem. The in-house documentation is pretty thorough. Zig users have produced a good amount of third-party material, as well.

Zig is still a relatively young project, in version 0.14.0 at the time of writing. The slow pace of development reflects the team’s devotion to quality. Several real-world projects are already using Zig in production. On the topic of production readiness, Loris said, “Zig is not yet at v1.0, so things like webdev are still in their infancy, but the only usage that I would consider not recommending Zig for is data wrangling, for which I think a dynamic language like Python or Julia would be more practical.”

It’s worth noting that web development still might not be the first thing you think of for Zig, but its Zine static site generator has matured considerably and is now hosting the Zig website. Zig also supports several web-related projects.

You can watch the progress towards the 1.0 release in this GitHub issue. There is no target release date, but many of the issues appear to be more on the order of niceties than critical fixes.

For now, the Zig team appears to be taking its time with the 1.0 release, which may drop in 2025 or later—but none of that stops us from building all sorts of things with the language today. Zig’s activity, goals, and uptake by the developer community make it a compelling project to watch.

Download the July 2025 issue of the Enterprise Spotlight from the editors of CIO, Computerworld, CSO, InfoWorld, and Network World.

For years, the dominant cloud narrative emphasized the scalability, flexibility, and ostensibly lower costs of public cloud solutions, compelling thousands of organizations to migrate their operations to these platforms.

Today, however, there is a clear pivot back toward private clouds, as enterprises recognize the benefits of a hybrid approach that combines public and private cloud infrastructures. According to recent survey data, this “cloud reset” is being driven by cost pressures, security concerns, and the advanced capabilities of modern private cloud platforms, which increasingly outperform public clouds in specific scenarios such as artificial intelligence and other next-generation applications. The resurgence of private cloud adoption is undeniable, and for many organizations, it is central to their broader IT modernization efforts.

The latest global survey from Broadcom, which polled 1,800 IT leaders, reveals a striking new reality: The tired old dichotomy of “cloud good, private bad” has collapsed, and the private cloud is not only alive and well but is emerging as the secret weapon for enterprises looking to optimize performance, control costs, and fuel the next great wave of innovation—especially in AI.

Hybrid is the destination, not a transition

One of the most striking findings from the survey is the sheer scale of hybrid adoption. An overwhelming 93% of enterprises report that they are intentionally balancing private and public cloud resources. According to the data, only 15% of enterprises prefer a pure public cloud model, and just 10% lean toward a private-only approach. The vast majority are adopting hybrid cloud for flexibility, resilience, and cost optimization.

Why the change of heart? Truth is, the limitations that hindered early private clouds—complexity, scalability, inadequate automation, and cumbersome developer experiences—have mostly been addressed. Today’s private clouds offer full-stack automation, self-service provisioning, modern devops pipelines, and on-demand elasticity that rivals the major public cloud providers.

This reinvention of the private cloud allows enterprises to utilize hybrid models not merely as a compromise, but as a true, best-of-both-worlds solution. Companies are placing workloads where they make the most sense, often spinning up AI, analytics, and high-compute infrastructure in private clouds to ensure complete control, lower latency, and adherence to security regimes.

Repatriation involves more than cost

Perhaps the most newsworthy trend in 2025 is the repatriation of workloads or shifting workloads back from public to private environments. Nearly 70% of enterprises surveyed say they’re considering this move, and a full one-third have already taken action. However, this is not a wholesale retreat from public cloud but rather a nuanced rebalancing to ensure that workloads are placed in the environment that offers the best balance of performance, cost efficiency, and risk.

Pragmatists realize that not every workload is ideally suited for a hyperscale public environment. As organizations have matured, they have gained a clearer understanding of their application portfolios. They are leveraging this knowledge to repatriate resource-intensive and data-sensitive operations such as databases and storage to be managed more cost-effectively and securely in a private cloud.

Another eye-opener: 84% of respondents say they’re now running both traditional and cloud-native applications in their private clouds. This demonstrates that modern private clouds have shed the stigma of being “legacy.” Companies are building greenfield workloads on their internal platforms, benefiting from innovations previously available only in the public cloud.

Security and governance

The old narrative that moving to the cloud would automatically simplify security has collapsed under the weight of real-world complexity and regulatory requirements. The survey indicates that security and compliance are the top drivers for repatriation, outpacing even cost. Private clouds no longer represent a trade-off between control and visibility. With the rise of advanced automation, zero-trust architectures, and AI-driven monitoring, private environments now offer enterprise-grade security and compliance alongside all the operational benefits of the cloud.

More than 90% of survey respondents trust the private cloud as their preferred model for tough security and compliance requirements. This is a significant vote of confidence in the maturity of today’s private platforms and a signal that regulatory demands—especially for data sovereignty and AI governance—are shaping cloud strategy in a manner that leverages the strengths of private infrastructure.

Be realistic about trade-offs

Although the resurgence of private cloud is reshaping enterprise strategies in 2025, it’s important to recognize that these platforms have drawbacks. Even with significant technological advances, private clouds often involve complexities that can become a substantial burden, particularly for organizations that lack extensive in-house expertise. Designing, deploying, and maintaining a robust private cloud requires specialized skills in infrastructure automation, security, software-defined networking, and resource orchestration. For companies without a well-established IT team, the learning curve can be steep, and operational missteps may result in inefficiency, downtime, or security breaches.

Another challenge is scalability. Public cloud environments excel at elastic, no-hassle scaling. You can spin up a thousand new instances or add petabytes of storage with just a few clicks. In contrast, even the most modern private clouds are ultimately constrained by the physical and financial limits of the organization’s own data centers. Rapid or unpredictable growth in workload demand can be challenging to meet without significant capital investments and careful planning, potentially hindering business agility at critical moments.

Cost management, ironically, can also become tricky with private clouds. Although they can be more cost-effective than public cloud for predictable, steady-state, or security-sensitive workloads, they require significant up-front investment in hardware, real estate, and staffing. Unlike the public cloud’s pay-as-you-go model, private clouds demand ongoing capital and operational expenditure. If organizations overbuild or underutilize these resources, they can end up paying more than they would for flexible, consumption-based public cloud services.

The ultimate responsibility for security and compliance rests entirely with the organization. Private cloud solutions can mitigate certain risks associated with multitenancy and data sovereignty, but they also eliminate the safety net of a cloud provider’s built-in tools, certifications, and threat monitoring. Maintaining a strong and flexible security posture requires ongoing, resource-intensive efforts, and the consequences of any breach or compliance issue are immediate and direct.

What’s clear from Broadcom’s report is that the private cloud has undergone a dramatic transformation. The changes extend far beyond simple incremental improvements; we’re witnessing enterprises both large and small leverage modern private clouds as their cost-efficient, secure home base for digital innovation. I’ve noticed this trend emerging in the past few years, and it is becoming clearer every day.

It’s no longer a question of private or public; rather, it’s about how to effectively utilize both. Today’s leading IT organizations are intentionally designing hybrid environments to maximize flexibility and drive strategy. The smart money is on those who recognize the private cloud for what it has become: a truly modern platform, purpose-built for the enterprise and prepared to support the next chapter of cloud-driven growth.

One of the most frustrating experiences for IT leaders is receiving a cloud invoice with costs well above expectations. It’s not as bad as a security issue or a major incident in a critical business system, but spiking cloud costs can have a similar impact. IT leaders are tasked with finding the root cause of the cost increase, explaining the issues to finance, and realigning the IT team to get costs back on track with the budget. It’s even more challenging when increasing cloud costs cause an unexpected budget variance that requires approval.

Devops teams that do not monitor cloud costs risk having to modify their architectures and automations to offset unexpected cloud costs. To avoid this, more IT teams are taking a proactive approach, using finops tools and assigning responsibilities to monitor costs and find optimization opportunities.   

Finops best practices include centralizing reporting, benchmarking cloud infrastructure, and forecasting peak usage periods. Cloud cost reduction opportunities include automating provisioning, standardizing build patterns with infrastructure as code (IaC), optimizing virtual desktops, and improving incident response.

“Finops facilitates quicker, data-driven decisions on cloud investments, which increases business agility in addition to cost savings,” says Ananth Kumar, product and engineering leadership at ManageEngine. “It guarantees that teams match spending with priorities by fostering an environment of accountability and cooperation across engineering, finance, and operations.”

Devops teams are aware of the impacts of shift-left practices in the development process. We’ve realized the importance of incorporating QA into software development, especially when establishing a continuous testing strategy and robust CI/CD pipelines. Many organizations have rebranded devops to devsecops as a call to shift-left security practices, transforming them from an afterthought to a non-negotiable devops principle.

Now many are feeling the pressure to shift left on finops practices and avoid the technical debt of unmanaged cloud costs. I asked tech leaders to share their advice for organization shifting left on finops.

Improve developer experience and reduce costs

When compute environments are not cost-efficient, it leads to cost overruns. It also creates rework for development teams to optimize architectures and invest in automation. For organizations with many developers, one opportunity is to review the infrastructure and provisioning on development environments.

“Cloud development environments (CDEs) empower developers by providing codified, cloud-based workspaces that improve resource control and cost optimization,” says Rob Whiteley, CEO of Coder. “Integrating CDEs with finops accomplishes the goal of shifting left and creating a powerful framework for balancing performance, resource management, and financial accountability.”

CDE benefits go beyond cost savings. Consistent environments improve quality and help avoid the common problem of, “Well, the code worked in my dev environment.” They also make onboarding new developers easier and offer other developer experience benefits. 

Optimize environments to avoid cloud cost debt

Beyond development environments are the testing, staging, production, and other cloud environments. Some environments may have stable usage patterns, while others can be optimized for patterns such as no usage, typical usage, and peak usage. Fiscally responsible devops organizations build finops policies directly into IaC and use cloud providers’ finops reporting to optimize cost-inefficient architectures.

“Cost controls should be a part of the company’s IaC strategy when deploying code to production by utilizing cost control capabilities within services from Azure, AWS, Google Cloud, or other clouds that can place soft and hard limits on spend,” says Josh Mason, CTO of RecordPoint. “IaC code should include configuring these limits as part of deployment, so they are guaranteed and are not a follow-on operational activity. This proactive approach is preferred over reactively applying controls after a finops incident, such as an overage.”

Another requirement to avoid cloud cost debt is developing the rules and automation to respond to underutilization, unexpected cloud usage spikes, and unexpected cost increases.

“IT teams at many organizations pay for services, storage, or computation that they never use,” says Kumar of ManageEngine. “Reports show the location and timing of these cloud usage spikes, which might occur most often during event-based workloads, large-scale data transfers, or CI/CD runs. IT teams should use the insights to resize instances, scale down unused resources, and set sensible limits on auto-scaling.”

Capture cloud costs with their business value

Building cost awareness in devops requires asking an upfront question when spinning up new cloud environments. Developers and data scientists should ask if the forecasted cloud and other costs align with the targeted business value. When cloud costs do increase because of growing utilization, it’s important to relate the cost escalation to whether there’s been a corresponding increase in business value.

The FinOps Foundation recommends that SaaS and cloud-driven commercial organizations measure cloud unit economics. The basic measure calculates the difference between marginal cost and marginal revenue and determines where cloud operations break even and begin to generate a profit. Other companies can use these concepts to correlate business value and cost and make smarter cloud architecture and automation decisions.

Joshua Bauman, head of cloud operations at Apptio, an IBM company, says, “Having unit cost metrics inside IaC platforms helps devops focus on the cost-per-unit measure, as this drives efficiency, profit, and ultimately smarter architecture decisions while exposing the data in the same place where deployment occurs.”

So, when invoices come in and there’s a spike in cloud costs, reviewing the delivered business value and unit costs can help explain the increase and avoid sending devops teams into rapid response mode.

Bauman adds, “If you’re just looking at cloud costs and they double, you’ll only see increased expenses. But when tracking both costs and business outcomes, you’ll see that you are optimizing and making the right design decisions that contribute to greater success.”

Promote finops beyond cost savings

Establishing finops disciplines can deliver business value beyond cost savings and making financially smart cloud architecture decisions. IT operations leaders overseeing significant cloud infrastructures are developing finops practices as a cost and operations management service.

“Mature finops practices can discover security holes, such as unexpected instance classes spinning up in non-standard regions before security telemetry can, and cut through the noise that typically overwhelms security systems to provide a clearer and more direct signal of potential issues,” says Kyle Campos, CPTO  of CloudBolt. “When seamlessly integrated into devsecops practices, finops telemetry not only reveals spend risk, but also shines a light on broader engineering and business risk.”

Mason of RecordPoint adds, “A large increase in spending could indicate a security incident through large-scale attacks against endpoints, or a large leakage of data showing up as spikes in egress costs. Broadly providing visibility into costs creates a culture of accountability and ownership in proactively managing resources.”

One key change to shift-left finops is making costs transparent to development teams and capturing cloud optimizations as a form of technical debt.

“Engineers especially can get tunnel vision on delivering features and the art of code, and cost modeling should happen as a part of design, at the start of a project, not at the end,” says Mason of RecordPoint. “Companies generally limit the staff with access to and knowledge of cloud cost data, which is a mistake. Companies should strive to spread awareness of costs, educating users of services with the highest cost impacts, so that more people recognize opportunities to optimize or eliminate spend.”

By the time the invoice with a spike in cloud costs comes, the only recourse IT leaders may have is to negotiate with the cloud provider and address cloud cost debt. Proactive organizations are shifting left finops practices to development and operations responsibilities. Finops disciplines help align cloud investments with business value. Key elements include ensuring cloud costs are factored into architecture decisions, prioritizing automations to tune the infrastructure based on demand, and creating alerts highlighting unexpected cost changes. 

For more than a decade “cloud” has really meant three names: Amazon, Microsoft, and Google. Yet 2025 is proving that the market is no longer a closed club. Cloudflare and Oracle, two companies with wildly different histories, are pressing legitimate advantages that could chip away at hyperscaler dominance. One is winning developers’ hearts with a global edge and a friction-free toolchain; the other is turning decades of enterprise data gravity into an AI-driven growth engine. Neither company is necessarily known as a cloud company, yet both point to a future where cloud choice widens far beyond the Big Three.

Cloudflare pursues the developer experience

Cloudflare, long known for speeding up and securing websites, is steadily expanding into full-fledged cloud services. Cloudflare’s brand-new Cloudflare Containers beta is the capstone on an increasingly complete developer platform. This new offering lets developers run containerized applications across Cloudflare’s global edge network, tightly integrated with Cloudflare Workers (its serverless platform). The goal is to make deploying containers as effortless as deploying a Cloudflare Worker. In fact, Cloudflare boasts that you can define a container in just a few lines of code and deploy it with the same wrangler deploy command used for Workers. No complex infrastructure setup needed.

It’s a big deal, because it continues Cloudflare’s focus on developer experience, positioning itself as the cloud platform that abstracts away the painful parts of infrastructure. This is what AWS set out to do years ago by removing the “undifferentiated heavy lifting of managing infrastructure,” but Cloudflare arguably takes this further precisely by doing less. Rather than offering every conceivable service and then requiring developers to navigate that complexity, Cloudflare has kept its platform lean in favor of simplicity. As one analysis notes, “While AWS lets developers spin up virtual servers and hundreds of products, Cloudflare launches products that make developers’ lives simpler.”

Cloudflare’s strength also derives from its origin story as a global network. The company has servers in more than 330 cities worldwide, placing 95% of the world’s internet-connected population within 50 milliseconds of a Cloudflare data center. This expansive edge infrastructure means that applications built on Cloudflare can deliver low-latency responses to users practically anywhere. For developers, it’s like having a worldwide data center footprint by default. You write your code or container once, deploy it, and Cloudflare’s network automatically runs it close to users. There’s no need to manually choose regions or worry about geographic scaling, a stark contrast to the manual configuration often required on AWS or Azure.

Cloudflare’s unified product portfolio also differs from the big clouds’ approach. In the past few years, Cloudflare has added a number of primitives that cover the needs of full-stack applications: Workers (lightweight serverless functions), durable objects and KV storage for state, R2 object storage (an S3 competitor), D1 database (SQL database in beta), pub/sub and queues for messaging, and now containers for heavier workloads. These pieces interoperate seamlessly. A developer can, for example, serve a static front-end via Cloudflare Pages, use Workers for API logic, store data in Cloudflare KV or D1, and invoke a Container for any component that needs a traditional runtime or third-party library. Indeed, Cloudflare’s platform now supports building an entire application—compute and data—on its network. This is starkly different from AWS, for example, which has long prided itself on the sheer number of services it offers, which can be as bewildering for developers as enticing.

Even so, Cloudflare still has gaps it needs to address to take on AWS, Azure, and Google. Cloudflare’s product suite, while growing, is still limited compared to AWS’s hundreds of services. Developers with very specific needs (advanced data warehousing, proprietary AI services, IoT device management, etc.) might not find equivalents on Cloudflare. Also, Cloudflare’s database offerings (D1, Durable Objects) are new and not as battle-tested or feature-rich as AWS’s databases. If your app needs a full-text search engine, big data analytics, or a petabyte-scale data lake, Cloudflare’s platform may not be the answer yet. In short, Cloudflare covers the basics but not every niche; it will need to broaden its services to capture more workloads.

But that’s nitpicking. Last quarter Cloudflare announced it had closed a $100 million deal with a customer building on its developer platform. Clearly there’s huge demand for what Cloudflare already offers: developer simplicity at dramatic scale.

Huge demand also seems true for Cloudflare’s polar opposite, Oracle, which is finding growing success for very different reasons.

Oracle gets serious about cloud

While Cloudflare started with web developers and edge computing, Oracle Cloud Infrastructure (OCI) started by targeting its traditional enterprise base. As I’ve written, recent results suggest this strategy is paying off: Oracle’s revenue has been on the rise thanks to surging cloud infrastructure and AI demand. In its latest earnings, Oracle surprised Wall Street with an 11% jump in revenue and its stock had its best week since 2001. Oracle achieved this by leaning into what it does best, databases and enterprise applications, and making them cloud- and AI-centric. Rather than trying to beat the likes of OpenAI or Google at general AI, Oracle is offering companies a way to bring AI to their own data securely within Oracle’s cloud. The new Oracle Database 23ai integrates machine learning capabilities directly into the database, allowing enterprises to get insights from their private data without shipping it off to a third-party service.

In a strange twist, Oracle has become an open choice for cloud workloads precisely by being a bit less “Oracle-esque” than it traditionally has been. Oracle embraced multicloud in a way few expected, making its database available on AWS, Google Cloud, and Azure rather than insisting all workloads must run on Oracle’s own OCI data centers. By being flexible, Oracle made its technology more attractive to cloud-hesitant customers, and in so doing, it has become a trusted partner to help otherwise cloud-resistant companies move critical workloads to the cloud.

Oracle also kept pouring money into its cloud infrastructure, investing billions to rapidly expand data center capacity after years of underinvestment. All these efforts have started to change Oracle’s image from a cloud laggard to a viable option, especially for companies that already use Oracle software. However, Oracle’s cloud push lacks a crucial element for long-term success: developer adoption. Years ago I pointed out that Oracle built a cloud for its existing enterprise customers, not for the next generation of developers. This remains a challenge, one that is almost exactly the opposite of Cloudflare’s challenges.

In today’s world, developers are often the new kingmakers who determine which platforms gain traction. A bank’s CIO might green-light an Oracle cloud contract, but the developers in that bank are the ones who pick the tools to build the next innovative app. If those developers aren’t thinking about Oracle, Oracle could miss out on the new workloads that aren’t already tied into its ecosystem. Oracle seems to recognize this and has started taking steps to woo developers. It has introduced a free tier on OCI and more transparent and straightforward pricing to let a dev with a credit card get started easily—something AWS mastered early on.

Two roads converge in the cloud

The Oracle story offers a lesson for Cloudflare: It’s not enough to have great tech or an incumbent advantage; you must win the hearts and minds of developers to sustain momentum. Oracle’s enterprise-centric cloud found new life by focusing on its strengths (data, AI, security) and that’s driving revenue, but its future will hinge on attracting the next generation of developers to build on OCI.

Cloudflare, conversely, has from the beginning been very developer-focused, cultivating enthusiasm among web and application developers. In some sense, Cloudflare and Oracle are coming at the cloud opportunity from opposite ends: Cloudflare has developer love and needs to prove itself in enterprise scenarios, while Oracle has enterprise credibility and needs to spark developer love. Both could carve out significant niches in the cloud market if they execute well. There’s room in the $100-billion cloud industry for alternative players, especially as companies pursue multicloud strategies and developers seek the best tool for each job.

AWS, Azure, and GCP still dominate by revenue and service depth, but hegemony breeds complacency. Cloudflare’s edge simplicity and Oracle’s AI-centric data strategy force the Big Three to double down on developer experience and multicloud openness. If there’s one lesson here, it’s that cloud advantage is increasingly about where your strengths naturally align with developer pain. For Cloudflare it’s hiding the ops. For Oracle it’s letting enterprises mine the gold already sitting in their databases. In 2025, those strengths are powerful enough to reshape the cloud leaderboard—and that’s great news for developers.

Generative AI has officially entered the infrastructure as code (IaC) trenches. What started as a bottom-up phenomenon — developers using ChatGPT and Copilot to avoid Googling Terraform syntax or getting bogged down in endless StackExchange threads — has grown into something more complex and widespread. Today, organizations are embracing AI as a tool not just for writing configs, but for shaping infrastructure decisions, integrating with observability, and even catching deployment errors.  

But the story isn’t just one of acceleration. As AI-generated IaC becomes more common as part of the AI data center, so do the pitfalls — from silent misconfigurations to public-facing APIs no one meant to expose. 

Rise of the machines 

Let’s start with what you can probably guess: Developers have been using generative AI tools to write IaC config code for some time now. In many places, especially early on, this was a bottom-up movement driven individual developers. “A lot of developers I know, especially those who aren’t IaC experts, are leaning on ChatGPT or Copilot to generate Terraform or Ansible configs,” says Siri Varma Vegiraju, Security Tech Lead at Microsoft. “It’s fast, and it helps people avoid looking up every AWS resource syntax or module.”  

That speed and accessibility come from the way AI has lowered the bar to writing configuration code. Ivan Novikov, CEO of Wallarm, puts it this way: “AI reduces the threshold for devs to write configs without deep knowledge. Before AI, writing production-ready Kubernetes or Terraform config was for SREs, DevOps, infra teams. Now, any backend dev can open ChatGPT and ask ‘make me a Helm chart for my API with autoscaling and ingress.’ And AI will do it.” 

This democratization of IaC also means that a lot of experimentation happens without much oversight. “Many developers quietly use ChatGPT/Copilot to draft IaC templates, especially for unfamiliar cloud services,” says Fergal Glynn, chief marketing officer and AI security advocate of Mindgard. “While this speeds up tasks, unreviewed AI code risks security gaps (e.g., overly permissive rules).” 

“In many companies,” Milankumar Rana says, software engineer advisor and senior cloud engineer at FedEx, “such usage began informally — engineers ‘on the sly’ asking ChatGPT how to create a resource block or fix an obscure provider error. However, we are now observing a more structured approach to adoption.” 

That shift is being driven by larger organizations that see potential in AI-assisted IaC but want it embedded within guardrails. As Glynn puts it, “Larger orgs use AI-augmented platforms (e.g., Torque’s Environment-as-Code) with guardrails to prevent errors. Startups and devops teams often experiment first, while enterprises prioritize governance frameworks.” 

When enterprises get on board with AI 

As the use of generative AI expands in infrastructure engineering, many organizations are responding by developing internal tools to guide and govern that usage. Nimisha Mehta, Senior DevOps Engineer at Confluent, notes that “AI-forward tech organizations adopt various tools such as IDEs with AI plugins, and even invest time and money into building bespoke systems and tools to integrate LLMs with their specific environments.” 

One increasingly common approach is to create internal AI “playgrounds ”— sandbox environments that allow teams to test configurations without risking production infrastructure. “Sandboxes allow developers to experiment with IaC templates, validate outputs to catch errors before deployment,” says Mindgard’s Glynn. “By balancing innovations with oversight, these playgrounds can minimize risks, such as security gaps, while encouraging controlled adoption of AI infrastructure-as-code workflows.” 

Sometimes, organizations are driven to develop such internal tools specifically in response to chaotic early AI-generated IaC efforts. Ori Yemini, CTO and co-founder of ControlMonkey, describes one such case: “A customer used ChatGPT to bulk-generate Terraform files for around 80 microservices. It worked, until they realized none of the generated code adhered to their tagging policies, module conventions, or team-based permissions. Their drift detection flagged hundreds of deltas against their baseline. The code ‘worked’ technically, but operationally it created chaos.” 

The solution? A tailored internal tool that wrapped the LLM in organizational context. “They shifted toward a controlled approach: using an internal wrapper around the LLM with prompts that inject organization-specific context, like required tags, naming conventions, and known module repositories. This drastically reduced both drift and rework,” Yemini says. 

Promises and pitfalls of gen AI and IaC

At its best, generative AI acts as a powerful accelerant for infrastructure work. “We’re seeing a quiet but significant shift in how engineering teams approach Infrastructure as Code,” says ControlMonkey’s Yemini. “It’s not just about writing a quick Terraform snippet anymore, it’s about accelerating infrastructure decisions in environments that are growing more complex by the day.” FedEx’s Rana echoes this, noting that “what used to take hours of cross-referencing documentation is now often accelerated by a single well-phrased cue.” He points to common use cases like creating reusable Terraform modules, converting shell scripts into Ansible playbooks, and scaffolding TypeScript for Pulumi code. 

The benefits go beyond code generation. AI is starting to integrate with observability systems to help manage infrastructure in real time. Microsoft’s Vegiraju notes, “More advanced setups are experimenting with feeding telemetry into AI systems that can suggest or even automatically apply IaC-based fixes. For example, if a service is repeatedly scaling out due to CPU exhaustion, the AI might propose a config tweak to increase CPU limits or change autoscaling thresholds.” While these are mostly proof-of-concept efforts in telemetry-heavy environments, they signal a direction where AI becomes more than just a code-writing assistant. 

Confluent’s Mehta points to similar developments on the operational side, extolling the troubleshooting prowess of agentic AI. “Say you have a network packet that flows through several layers in the networking stack, she says. “AI is great at eliminating options to pinpoint the root cause of the issue.” She sees this as a precursor to more autonomous, self-healing systems, though notes they’re still in early stages. 

But for all its promise, AI still lacks a basic quality that human engineers rely on: context. “Although AI is great at writing IaC and YAML manifests,” Mehta says, “its biggest current shortfall is not having visibility on how distributed production-grade infrastructure is actually set up in the real world.” Agentic tools are starting to address this by integrating more directly with infrastructure, but, she notes, “they don’t scale to thousands of compute clusters.” 

Wallarm’s Novikov is even more blunt: “Prompts don’t carry full context about your infra and settings. Your infra is big. You have dozens of services, secrets, RBAC rules, sidecars, CI/CD flows, policies, naming rules, and many things in Terraform state. AI doesn’t know all that. When you ask ‘write config for API X,’ it works in a vacuum.” 

That vacuum can result in mistakes that are difficult to spot but potentially damaging. “AI-generated configs can be syntactically right but semantically wrong,” says Microsoft’s Vegiraju. He offers a simple example of Terraform config code written by AI based on a simple prompt: 

resource "azurerm_storage_account" "example" { 

  name                     = "examplestorageacct1"  

  public_network_access_enabled = true 

} 

That configuration will deploy successfully — but also opens the storage account to the public internet. “Without strict network rules or identity-based access controls, this could lead to unauthorized access or data exfiltration,” he says. “In over 90% of real-world scenarios, public network access should be disabled.” 

Security oversights like that are far from theoretical. “Configs often miss security best practices,” says Novikov. “No rate limits, wide network exposure (0.0.0.0/0), missing resource limits, open CORS, and no auth on internal APIs.” In one real-world case, a fintech developer used AI to generate ingress for an internal API. “They forgot to add IP whitelisting. The API went public, got scanned in 20 minutes, and attackers found an old debug route.” 

A cautious look ahead at AI and infrastructure 

As generative AI becomes more embedded in infrastructure workflows, its role is evolving. “One pattern we’re noticing across several mid-to-large scale orgs is this: AI is being used as a ‘first draft generator,’ but increasingly also as a decision-support tool,” says ControlMonkey’s Yemini. “Engineers aren’t just asking, ‘How do I write this AWS security group?’ they’re asking, ‘What’s the cleanest way to structure this VPC for future scale?’” He notes that these questions aren’t confined to early design stages —t hey come up mid-sprint, when real-world blockers hit. “From our perspective, the most successful orgs treat generative AI like an untrained junior engineer: useful for accelerating tasks, but requiring validation, structure, and access to internal standards.” 

That need for human oversight was a recurring theme with everyone we spoke to. Microsoft’s Vegiraju puts it simply: “Engineers should first understand the code coming out of the LLM before using it.” At Confluent, Mehta emphasizes the importance of safeguards: “We need guardrails built into the system to prevent accidental breaking changes, be it due to human error or due to AI-generated changes.” She points to GitOps systems and peer-reviewed version control as ways to build accountability into the workflow. 

Mindgard’s Glynn sees a similar pattern emerging. “Models like WISDOM-ANSIBLE generate Ansible playbooks just by providing natural language prompts,” he says, “but AI-generated YAML/Chef files do require manual tweaks for edge cases.” Enterprises may use these tools to enforce compliance — for instance, automatically adding HIPAA settings — but they still review outputs for accuracy before deployment. 

Without that diligence, the risks can compound quickly. Wallarm’s Novikov recounts a troubling trend: “One large SaaS org told us 30% of their IaC is now AI-generated. But they also see three times more config misfires in CI/CD than last year—wrong secrets, open ports, wrong S3 policies, unprotected APIs.” That company now uses tools like Checkov, tfsec, and custom Wallarm rules to catch misconfigurations after the fact. But the root cause is often speed outpacing safety. “One junior dev told us: ‘I just paste the prompt, review the YAML looks ok, and push.’ That’s where issues sneak in.” 

The tools are getting better — yet the need for caution is still there. “AI is so powerful,” Novikov says. “But when it comes to PaaS and APIs, it’s risky if used blindly. Without proper policy checks, context awareness, and testing, AI-generated configs become new security debt.” 

“You use AI for infra?” he says. “Cool. Just don’t trust it too much.” 

The amount of data in modern systems has skyrocketed beyond what traditional security tools can handle. As organizations embrace AI to boost productivity, security teams face mounting pressure to protect sensitive information across sprawling cloud infrastructures and applications. The velocity of data creation, combined with complex multicloud environments, makes traditional security approaches insufficient. AI systems introduce additional complexity—they require broad data access to function effectively, yet this same access creates new attack vectors. Security teams must now secure not just the data itself, but also how AI systems interact with and process that data.

The Codefinger attack from earlier this year demonstrates this risk. This ransomware attack targeted users of Amazon S3 buckets, encrypting files using AWS’s own server-side encryption capabilities. The attackers exploited AWS’s built-in features, demanding payment in exchange for decryption keys. This attack highlighted a critical weakness – attackers weaponizing cloud platforms’ native security features against their users.

The significance of the Codefinger attack extends beyond its technical sophistication. By leveraging victims’ own infrastructure, attackers can execute breaches more efficiently and at lower cost, suggesting similar attacks will become more frequent.

What steps can organizations take to protect themselves? Data security and governance require precise visibility and control. Organizations need to know what sensitive data they possess and strictly manage how it can be accessed. In the case of Codefinger, companies can execute the following three technical steps immediately.

Audit identities with SSE-C privileges

The first step is to audit identities (human and non-human) that can use SSE-C, and compare that list to a master list of authorized users to SSE-C. Start by removing highly privileged identities that have been inactive for over thirty days. Eliminate unnecessary SSE-C privileges from identities that don’t require them. The key permissions required for ransom via SSE-C are s3:GetObject and s3:PutObject. After cleaning up these permissions, segregate those left with SSE-C privileges and make sure they do not have access to disable object versioning, destroy backups, destroy existing logs, or disable logging. Monitor for the following permissions being co-mingled with SSE-C permissions:

Deletion of logs

• s3:DeleteBucket – Allows deletion of log containing bucket
• s3:DeleteObject – Allows deletion of specific objects in a bucket

Deletion of backups

• s3:DeleteObjectVersion – Allows deletion of specific versions of objects
• backup:DeleteRecoveryPoint – Allows deletion of AWS Backup S3 recovery points

Object versioning

• s3:PutBucketVersioning – Allows enabling or suspending versioning

Logging and audit configuration

• s3:PutBucketLogging – Allows enabling, disabling, or altering bucket logging configurations
• s3:GetBucketLogging – Provides visibility into the current logging configuration
• s3:PutBucketPolicy – Allows modification of bucket policies, which could disable logging indirectly or prevent access logging from being written
• s3:PutBucketAcl – Allows modification of bucket access control lists (ACLs), potentially disrupting access logging

This audit of inactive or unauthorized users that already have access to your data first and delegating specific permissions to the identities left is a vital part of this threat mitigation process. By this point, you should be able to see all authorized permissions that are provided to both human and non-human identities clearly before moving forward with any other steps.

Log data events in Amazon S3

The second step is to log data events in S3, using either CloudTrail Data Events or S3 Server Access Logs. AWS omits S3 GETs and PUTs by default, limiting attack investigation capabilities. A way around this is to enable data event logging in S3 through CloudTrail Data Events or S3 Serve Access Logs.

CloudTrail Data Events offer greater detail than S3 Serve Access Logs. However, they are billed per data event volume, so costs can rise quickly for buckets with high change rates. S3 Server Access Logs are not billed for log generation, but only for storage.

Whichever log destination bucket you choose, make sure it is in a secure location and that you are enacting object versioning to make it easier to recover files from the last known good state.

Take a risk-based approach to data security

Last, and most critically, organizations need to discover and classify every piece of data in order to understand which assets are to be acted on and when. Taking a comprehensive scan and ensuring accurate classification of your structured, semi-structured, and unstructured data can help identify risk that is imminent versus risk that can be de-prioritized. Beyond ransomware protection, identity management and data exposure controls are equally important for responsible AI deployment. Organizations rapidly adopting generative AI often overlook the scope of access these systems have to sensitive data. Ensuring that AI systems can only reason over authorized and properly secured versions of corporate data is paramount, especially as the regulatory landscape continues to evolve. This comprehensive approach to data security addresses both traditional threats and emerging AI-related risks.

Unprecedented threats require new security standards and controls

The security community faces unprecedented threats requiring coordinated action between private industry and government agencies. Recent attacks highlight severe gaps in data protection standards, especially around AI systems. AI accelerates business operations but introduces new risks. Sensitive data can leak into AI models during training and out of sensitive models during inference; once a model is trained, governing its outputs is non deterministic. These AI security challenges directly relate to the identity and data controls discussed above. Without sufficient access management and data classification, organizations cannot prevent unauthorized data from entering AI training pipelines and being exposed through inference.

The current changing regulatory environment adds complexity. Recent changes to cybersecurity executive orders have disrupted established collaboration frameworks between government and industry. This policy shift impacts how organizations develop secure AI systems and address vulnerabilities in our national security infrastructure. One thing is certain: The threats we face—from nation-state actors to increasingly sophisticated cybercriminal groups—won’t wait for political consensus. Just as with ransomware protection, organizations must take proactive steps to secure their AI systems regardless of regulatory uncertainty.

Forward-thinking enterprises and technology providers must act now to strengthen their security controls. Building protection mechanisms after AI systems are deployed costs significantly more and will leave organizations exposed. The same methodical approach to identity governance and data classification that protects against threats like Codefinger provides the foundation for secure AI implementation. The security measures implemented today will determine how well organizations can defend against tomorrow’s threats.

Pranava Adduri is CTO of Bedrock Security.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com. 

Google has released version 2 of its Python client library to query the Data Commons platform, which organizes the world’s publicly available statistical data. The library supports custom instances, among other capabilities.

Announced June 26, the Data Commons Python library can be used to explore the Data Common knowledge graph and retrieve statistical data from more than 200 datasets. Available domains include demographics, economy, education, environment, energy, health, and housing. Developers can use the library’s custom instances to programmatically query any public or private instance, whether hosted locally or on the Google Cloud Platform. Developers can use custom instances to seamlessly integrate proprietary datasets with the Data Commons knowledge graph, according to Google.

Based on the V2 REST API, the Data Commons Python library in version 2 supports Pandas dataframe APIs as an integral module, with a single installation package allowing seamless use with other API endpoints in the same client, Google says. API key management and other stateful operations are built into the client class. Integration with Pydantic libraries improves type safety, serialization, and validation. Additionally, multiple response formats are supported, including JSON and Python dictionaries. With the library, developers can map entities from other datasets to entities in Data Commons. The Data Commons Python API client library is hosted on GitHub and available on pypi.org.

This week in Python brings us a toe-to-toe showdown between two Rust-powered Python type checking tools. We also have a gentle introduction to type hinting, a look at the perils—and promises—ahead for a free-threaded, no-GIL Python, and a shocking exposé (okay, just kidding) of the latest malware attacks targeting machine learning developers, this time delivered via PyPI.

Top picks for Python readers on InfoWorld

Pyrefly and Ty: Two new Rust-powered Python type-checking tools compared
These tools are so new they barely have the shrinkwrap off, but even at this stage, they stand apart from each other and the rest of the pack—and not just because they’re fast.

’Fearless concurrency’ in future versions of free-threaded Python
A free-threaded, no-GIL Python promises real concurrency, at long last. But what side-effects will come with that freedom? And how can we start fixing them now?

Get started with Python type hints
Intimidated by Python’s new-ish type hinting powers? Learn how to use type hints where and when you need them. In the long run, you’ll be rewarded with better IDE suggestions and more readable Python.

More good reads and Python updates elsewhere

Malicious PyPI package targets Chimera users to steal AWS tokens, CI/CD secrets
Machine learning developers were the targets for this latest example of malware distributed via the Python package ecosystem.

The free-threaded Python compatibility checker
Does your favorite third-party library run properly under the free-threaded Python builds? This handy online tool lets you search packages by name and find out. You can also check the status of the top 1,000 PyPI packages in an at-a-glance infographic.

PyPDFForm: Free, open source PDF form processing in Python
Quit filling in PDF forms by hand! This library automates filling form fields in PDFs and saves the results to new PDFs. It also lets you programmatically inspect the existing fields in a PDF for other processing.

WinUp: A better way to make Qt6 desktop apps in Python
Most desktop GUI frameworks for Python win no awards for being easy to use or aesthetically appealing. WinUp is different, letting you use simple, declarative code to describe your UI layout and behaviors, leverage many common prebuilt components, and even work with system functions like the camera or notifications tray.

Slightly off topic: Build a tiny programming language and compiler from scratch
There are many crash courses in creating a toy programming language, but this one gets points for being cross-platform, LLVM-powered, and written in straightforward C++. Bonus points to anyone who writes a Rust port!

A certain Fortune 500 financial institution decided to fully embrace the cloud. Executive memos indicated that all their new initiatives would be “cloud-first.” Teams were encouraged to re-architect everything, including mission-critical transaction processing that had thrived for decades on robust mainframes. The company’s mainframe team, a group of highly skilled professionals, raised concerns. They believed the cloud wasn’t suited for certain high-throughput, low-latency workloads central to their business. However, in the exciting early days of cloud computing, those concerns went unaddressed.

Cracks began to appear a year into the migration. Cloud costs skyrocketed. Performance suffered. Customers complained about slow service during peak hours. The company had to call back its mainframe engineers and roll key workloads back onto the mainframe—this time integrating them more thoughtfully with new cloud-native services. Only then did resilience and customer satisfaction return.

The lesson? Never dismiss a proven technology (or the experts who manage it) just because a new one is more exciting.

Mainframes are still core components, not relics

Despite industry hype, mainframes are not going anywhere. They quietly support the backbone of our largest banks, governments, and insurance companies. Their reliability, security, and capacity for massive transactions give mainframes an advantage that most public cloud platforms simply can’t match for certain workloads.

Big players like IBM and Broadcom understand this well. They continue to invest in mainframe modernization—think APIs, containerization, and cloud integration features. Mainframes aren’t just legacy; they’re evolving. The people who keep these systems running aren’t museum curators—they’re essential to smooth operations and safety, especially for enterprises with decades of institutional knowledge embedded in these platforms.

Unfortunately, in many organizations the cloud is seen as the solution to every problem. This oversimplification positions mainframes and their operators as old-fashioned—a risky mindset for any business with real-time processing demands or compliance requirements that cloud alone can’t meet.

Hybrid excellence: Mainframes and cloud together

The question isn’t whether the cloud is important. It absolutely is. The cloud unlocks agility and scalability that businesses could not have dreamed of 20 years ago. However, there’s a deeper truth: Not every workload belongs in the cloud, and not every system on a mainframe should remain there forever. Strategic organizations ask deeper questions: Which environment provides the best outcome for each task? Where are our strengths, and how can we combine them for improved business results?

Forward-thinking IT leaders are demonstrating that hybrid IT is the future. Mainframes are now being made “first-class cloud citizens,” participating directly in cloud-driven devops workflows and data exchanges. IBM and Broadcom are enhancing mainframe integration, building bridges with public and private clouds. This means mainframe and cloud professionals must collaborate closely, each contributing their expertise and insight.

The enterprises that thrive in this new era are those that eliminate silos. They capitalize on mainframes for their strengths (transactional integrity, security, scale) while employing the cloud where it excels (agility, global scale, rapid innovation). Only by recognizing the unique benefits of each environment can companies unlock true innovation.

A culture of tech respect and open-mindedness

At the core of this conversation is culture. An innovative IT organization doesn’t pursue technology for its own sake. Instead, it encourages teams to be open-minded, pragmatic, and collaborative. Mainframe engineers have a seat at the architecture table alongside cloud architects, data scientists, and developers. When there’s mutual respect, great ideas flourish. When legacy teams are sidelined, valuable institutional knowledge and operational stability are jeopardized.

A cloud-first mantra must be replaced by a philosophy of “we choose the right tool for the job.” The financial institution in our opening story learned this the hard way. They had to overcome their bias and reconnect with their mainframe experts to avoid further costly missteps.

It’s time to retire the “legacy versus modern” conflict and recognize that any technology’s true value lies in how effectively it serves business goals. Mainframes are part of a hybrid future, evolving alongside the cloud rather than being replaced by it. Mainframe engineers should be acknowledged as key partners in the digital landscape.

Digital transformation isn’t just about technology—it’s about people and perspective. The strongest enterprise cultures recognize and embrace the value of every platform and professional, evaluating each decision based on merit rather than trend. By cultivating an inclusive technology culture that values mainframes, clouds, and the people who excel at either one, enterprises will position themselves for lasting success.

Rust 1.88 has been released, featuring support for writing naked functions, as well as backing for Boolean literals.

The update of the popular fast and safe programming language was announced June 26 by the Rust Release Team. Current Rust users can get Rust 1.88 by running rustup update stable.

Rust 1.88 adds language support for writing naked functions with no compiler-generated epilogue and prologue. This allows full control over the generated assembly for a particular function. The Rust team said this was a more ergonomic alternative to defining functions in a global_asm! block. A naked function is marked with the #[unsafe(naked)]attribute; its body consists of a single naked_asm! call. The team showed an example where a handwritten assembly block defines the entire function body. For naked functions, the compiler does not add any special handling for return values or arguments, unlike non-naked functions. Naked functions are used in low-level settings such as Rust’s compiler-builtins, operating systems, and embedded applications.

With Rust 1.88, the cfg predicate language now backs Boolean literals, true and false, acting as a configuration that is always enabled or disabled. This works in Rust conditional compilation with cfgand cfg_attr attributes, in the built-in cfg! macro, and in Cargo [target] tables in both configuration and manifests, the Rust team said. Previously, empty predicate lists could be used for unconditional configuration, like cfg(all()) for enabled and cfg(any()) for disabled, but cfg(true) and cfg(false) offer a more direct way to say what is meant, the team said.

Also with Rust 1.88, let statements now can be chained (&&) inside if and while conditions, and even intermingle with Boolean expressions. Thusly, there is less distinction between if and if let and between while and while let. The patterns inside the let sub-expressions can be refutable or irrefutable, and bindings are usable in later parts of the chain as well as the body, according to the Rust team.

Finally, the Cargo package manager now automatically runs garbage collection on the cache in its home directory. In explaining this change, the Rust team said that when building, Cargo downloads and caches crates needed as dependencies. Historically, these downloaded files were never cleaned up, leading to an unbounded amount of disk usage in Cargo’s home directory. With Rust 1.88, Cargo introduces a garbage collection mechanism to automatically clean up old files.

Rust 1.88 follows last month’s Rust 1.87 release, which brought accommodations for anonymous pipes and architecture intrinsics.

Running AI workloads on premises has often meant overloading shared infrastructure or relying on complex hybrid setups. In an effort to reduce this friction, Teradata has bundled some of its existing tools into a new AI Factory to help data scientists manage the full AI lifecycle on premises without disrupting core systems or moving to the cloud.

“A lot of IT departments are already fully using their Teradata system for mission-critical workstreams and really don’t want data scientists doing AI exploratory work on that same system,” said Dan Spurling, SVP of product management at Teradata.

Until now, he said, to keep the two apart enterprises would have to use a hybrid solution of Teradata’s existing on-prem hardware and VantageCloud. “But AI Factory simplifies this process,” he said, separating the infrastructures where needed and making it possible to do all of the AI workstream, or at least the most expensive part of it, on premises.

This can give organizations “predicable costs and more control over their data sovereignty,” Spurling said.

AI Factory, which wasn’t previously available on-premises in a single, integrated, and ready-to-run stack, combines the data analytics software provider’s database engine and AI Workbench (consisting of ClearScape Analytics, ModelOps, JupyterHub, AI and ML In-Engine Analytics, Enterprise Vector Store, and support for the Open Table format) with AI microservices such as RAG, retrieval embedding, reranking, and guardrails.

Together, these tools gives enterprises a way to scale AI with an out-of-the-box packaged solution — with governance, performance, and control baked in, said Michael Ni, principal analyst at Constellation Research.

“What stands out is how Teradata integrated ModelOps, vector search, and LLM pipelines into a turnkey platform providing traceability and compliance from experimentation to production,” Ni added.

AI Factory is also developer- friendly, said Moor Insights and Strategy principal analyst Robert Kramer.

“The built-in AI Workbench includes tools such as JupyterHub and ModelOps, which are familiar to data teams and help keep the development process moving. That’s important for customers who want to keep AI projects from getting stuck in setup or compliance bottlenecks,” Kramer said. The predictable pricing model should help customers avoid surprise costs, he said.

Regulatory pressure

Enterprises’ desire to move AI activities on-premises isn’t just driven by questions of cost or control: For some businesses, it’s also about regulatory norms and scrutiny.

“Between stricter data privacy rules, growing concerns over data sovereignty, and unpredictable cloud costs, many enterprises are rethinking what should stay in the cloud and what’s better off staying in-house,” Kramer said. “This is especially true for industries like healthcare, finance, and government, where regulations are tight and data sensitivity is high.”

Other vendors including IBM, Dell, and HPE are looking to help enterprises build AI on-premises, but Kramer said Teradata has an edge, especially with customers who are already using it for data management and want to bring AI into the mix without standing up a bunch of new systems or re-architecting what they already have.

“While others might have gotten there first, Teradata’s offering is built around real integration with enterprise data operations, which can save time and reduce complexity for its existing customers,” he said.

Integration with Nvidia

For AI Factory, Teradata has partnered with Nvidia by using its Nvidia Enterprise AI Factory Validated Design, a full-stack featuring its Blackwell-accelerated computing systems, AI Enterprise software, and networking hardware.

The Nvidia GPUs, though, in this case, have to be owned by the enterprise deploying AI Factory on-premise, Teradata said.

As Constellation Research’s Ni put it, “Nvidia brings the AI muscle, Teradata brings enterprise-grade data and analytics platform.”

Having their Nvidia chips on premises, Kramer said, enables enterprises to run heavier AI workloads such as training or inferencing models without relying on cloud-based GPUs, which can lead to high or unpredictable costs. “To avoid that, what Teradata does is connects to those GPUs using its AI Microservices layer, which helps customers get more out of what they’ve already invested in,” he said.

AI Factory is now generally available.

In today’s data-driven landscape, integrating diverse data sources into a cohesive system is a complex challenge. As an architect, I set out to design a solution that could seamlessly connect on-premises databases, cloud applications and file systems to a centralized data warehouse. Traditional ETL (extract, transform, load) processes often felt rigid and inefficient, struggling to keep pace with the rapid evolution of data ecosystems. My vision was to create an architecture that not only scaled effortlessly but also adapted dynamically to new requirements without constant manual rework. 

The result of this vision is a metadata-driven ETL framework built on Azure Data Factory (ADF). By leveraging metadata to define and drive ETL processes, the system offers unparalleled flexibility and efficiency. In this article, I’ll share the thought process behind this design, the key architectural decisions I made and how I addressed the challenges that arose during its development. 

Recognizing the need for a new approach 

The proliferation of data sources — ranging from relational databases like SQL Server and Oracle to SaaS platforms like Salesforce and file-based systems like SFTP — exposed the limitations of conventional ETL strategies. Each new source typically requires a custom-built pipeline, which quickly became a maintenance burden. Adjusting these pipelines to accommodate shifting requirements was time-consuming and resource-intensive. I realized that a more agile and sustainable approach is essential. 

A metadata-driven design emerged as the ideal solution. By centralizing ETL configurations in a metadata repository, I could abstract the logic of the processes away from the pipelines themselves. This abstraction allowed for the addition of a new data source or modification of an existing flow to be achieved by updating metadata rather than rewriting code. The promise of reduced maintenance and faster adaptability drove me to pursue this direction. 

Crafting the architectural framework 

Laying the groundwork with a metadata schema 

The cornerstone of this architecture is a carefully crafted metadata schema, hosted in an Azure SQL Database. This schema captures all the necessary details to orchestrate the ETL process: connection information, copy operation definitions and configuration settings. I chose Azure SQL Database for its robust relational capabilities, which enable efficient querying and management of intricate metadata relationships. Its tight integration with Azure services, such as ADF, ensures a smooth data flow, while its scalability and high availability meet the demands of a reliable system. 

The schema includes several key tables: 

• Connections: Stores source and destination details, with sensitive data linked to secure references rather than stored directly. 

• CopyOperations: Specifies the types of data transfers, such as database-to-database or file-to-storage. 

• ETLConfig: Defines the specifics of each ETL process, including objects to transfer, execution order and any pre- or post-processing steps. 

This metadata serves as the blueprint, dynamically guiding the entire ETL workflow. 

Orchestrating with a parent pipeline 

Central to the framework is a parent pipeline in ADF, which I designed as the primary orchestrator. This pipeline is parameterized to accept an identifier for a specific ETL flow. When triggered, it calls a stored procedure in the Azure SQL Database, which returns a JSON response detailing the processes to execute. For example, the JSON might outline a sequence of transfers from a database to a data lake, each with its own parameters. 

The parent pipeline then delegates these tasks to specialized child pipelines, passing along the necessary metadata. This design eliminates the need for hardcoding specific flows into the pipeline itself, making it highly adaptable. The decision to use a stored procedure for generating the JSON configuration was intentional — it allows complex logic to reside in the database, keeping the pipeline lean and focused on execution. 

Vikram Garg

Building modularity with child pipelines 

To manage the variety of data sources and destinations, I opted for a modular structure. Each type of data transfer — whether from a database to another database or a file system to cloud storage — is handled by a dedicated child pipeline. These child pipelines are templates and parameterized, meaning they can be reused across different scenarios by simply adjusting the runtime inputs. 

For instance, a child pipeline designed for database-to-database transfers can handle any such operation by receiving the appropriate source and destination details from the metadata. This modularity simplifies expansion: supporting a new transfer type involves creating a new child pipeline template and updating the metadata, rather than redesigning the entire system. 

Prioritizing security 

Security is a non-negotiable aspect of data integration. To safeguard sensitive information like connection credentials, I integrated Azure Key Vault into the framework. The metadata schema references only the keys to these secrets, which are retrieved by the pipelines at runtime. This ensures that sensitive data remains encrypted and inaccessible outside of authorized processes. 

This design not only bolsters security but also streamlines secret management across different environments, such as development and production. It was a deliberate choice to embed security into the architecture from the ground up, ensuring compliance and trust in the system. 

Enabling flexible execution 

The framework is needed to support both scheduled and on-demand ETL processes. To achieve this, I incorporated multiple triggering mechanisms. For scheduled runs, I used Azure Logic Apps, which read timing configurations from the metadata and initiate the parent pipeline accordingly. For on-demand execution, an API endpoint via Azure API Management allows external systems or users to trigger the process as needed. 

I also added event-based triggers, such as monitoring a file drop location for new arrivals and launching the ETL process automatically. This versatility ensures the framework can meet a wide range of operational demands. 

Ensuring reliability with monitoring and logging 

A robust ETL system requires visibility and reliability. I built comprehensive logging into the framework, capturing execution details—start times, end times, statuses and errors — in the Azure SQL Database. For real-time oversight, I integrated Azure Application Insights to monitor pipeline performance. 

To handle failures, I designed a utility pipeline that logs exceptions, sends alerts for critical issues and flags problems for investigation. This proactive monitoring minimizes disruptions and keeps the system running smoothly. 

Empowering users with a simple interface 

To broaden the framework’s usability, I developed a web-based interface hosted on Azure App Service. This UI allows non-technical users to manage metadata — adding new sources, adjusting configurations or setting schedules — without needing to navigate ADF directly. This self-service capability reduces IT dependency and accelerates the integration process. 

Tackling design challenges 

The design process presented several hurdles. One major challenge was ensuring the framework could handle diverse data sources without becoming overly complex. The modular child pipelines addressed this by isolating each operation type, maintaining simplicity while supporting variety. 

Performance was another concern. With large data volumes, I needed to minimize latency and maximize throughput. I employed parallel processing where feasible and optimized data partitioning to enhance efficiency. ADF’s native data movement features further streamlined transfers. 

Scalability posed its own issues. As the number of copy operations grew, I encountered limitations in ADF’s switch case activity, which is capped at 25 cases. To overcome this, I added a categorization layer in the parent pipeline, grouping operations by type and effectively expanding capacity. This solution required careful validation but proved effective. 

Another constraint was ADF’s static integration runtime selection for on-premises sources. Since runtime couldn’t be dynamically chosen, I configured multiple linked services tied to different runtimes, selecting the appropriate one via metadata. It’s a workaround that ensures compatibility with hybrid environments. 

Reflecting on the design journey 

This project underscored several critical insights. Scalability must be baked into the architecture from the start — using metadata as the driver ensures the system can evolve without constant refactoring. Modularity simplifies maintenance and extension, proving its worth as new needs arise. Security, integrated early, builds a foundation of trust. And empowering users with intuitive tools fosters collaboration and efficiency. 

This metadata-driven ETL framework represents a shift in how I approach data integration. Its flexibility, scalability and user-centric design make it a powerful tool for managing complex data ecosystems. For fellow architects, I’d recommend exploring metadata-driven solutions — they require upfront effort but deliver lasting value. My experience with Azure ADF has been a journey of innovation, and I look forward to seeing how this approach evolves. 

This article is published as part of the Foundry Expert Contributor Network. 
Want to join? 

Moving forward with the development of its enterprise Java application platform, the Eclipse Foundation has released Jakarta EE 11 Platform, which promises simpler data access and streamlined testing processes. Java 21 support also is featured.

Rolled out June 26, Jakarta Enterprise Edition 11 homes in on performance and productivity, according to Eclipse. Featured as part of Java EE 11 is Jakarta Data, a new specification designed to simplify data access and improve developer productivity. “Jakarta Data is a new specification that is standardizing the repository pattern for data access,” said Tanja Obradovic, Eclipse Jakarta EE program manager. “It reduces the complexity of the persistence logic that we’re using.”

Core functionality described in the Jakarta Data specification includes BasicRepository, which is a built-in repository supertype for performing basic operations on entities, and CrudRepository, for basic CRUD (create, read, update, and delete) operations, to make database interactions more straightforward and less error-prone. Other parts of the specification include support for both offset and cursor-based pagination and a streamlined query language for Jakarta Data repositories.

The Jakarta EE 11 release builds on previous Core Profile (December 2024) and Web Profile (March 2025) versions and represents a significant advancement in simplifying enterprise Java for cloud-native development, Eclipse said. Microsoft and Red Hat were among the companies that participated in the development of the release. “Our collaboration with esteemed partners IBM, Red Hat, and Oracle has been instrumental in supporting Jakarta EE 11 runtimes on Azure, including Azure Kubernetes Service, Azure Red Hat OpenShift, and App Service,” Microsoft’s Scott Hunter, vice president of product, Azure developer experience, said in a statement.

Jakarta EE 11 has been verified to work with Java 17 and Java 21, both of which are long-term support (LTS) releases of Java SE (Standard Edition). Concurrency enhancements are supported for Java 21 including support for virtual threads, which improves scalability, reduces overhead, and offers significant performance gains, said Eclipse. Future plans call for supporting the upcoming JDK 25 LTS release, due to arrive in September, in Jakarta EE 12, which is targeted for release in 2026.

All Jakarta EE releases are based on the Jakarta EE Platform specification. Streamlined Jakarta EE 11 specifications include a modernized Technology Compatibility Kit (TCK) designed to improve compatibility testing and reduce barriers to adding new tests as the platform evolves, Eclipse said. Managed Beans has been deprecated for removal to achieve a simpler and more modern programming model, while Context and Dependency Injection (CDI) enhancements promise more consistent application behavior. Other streamlined specifications cover Java records support, for broader integration for data integrity and reduced boilerplate code, and the removal of Java SE Security Manager, to enable more modern security practices. Tool upgrades in Jakarta 11 move the platform from Apache Ant and Java Test Harness to JUnit 5 and Apache Maven for enhanced efficiency and relevance, Eclipse said. Updating the TCK to a multi-dependency Maven project boosts compatibility testing and removes barriers to adding new tests.

Jakarta EE Working Group members have certified several products as compatible with Jakarta EE 11. For the Web Profile, the Eclipse GlassFish application server has been certified. For the Core Profile, IBM’s Open Liberty microservices framework, Red Hat’s WildFly application server, the Payara Platform Community Edition, and the Fujitsu Software Enterprise Application Platform have been certified, according to Eclipse. This list is expected to grow rapidly after Jakarta EE 111’s release.

Previously under Oracle’s jurisdiction, Eclipse took over development of enterprise Java in 2017. Enterprise Java previously was known as Java EE. Oracle sought to turn over the project to an open source organization while remaining the steward of standard Java. The predecessor to Jakarta EE 11, Jakarta EE 10, arrived in September 2022.

Much of what we do to keep our online lives secure relies on public-key cryptography and its complex mathematical operations. At the heart of these techniques are sets of one-way functions that generate the public and private keys used to encrypt and decrypt data.

Those mathematical functions are secure because it would take immense amounts of time and computational power to find a private key from a public key, factor very large numbers, and then decrypt data—at least, if you’re using a conventional computer. Some algorithms can be cracked using specialized hardware, but even here cost is still an issue.

Quantum computing and modern cryptography

One technology on the horizon could make the cryptographic basis of our entire online world obsolete almost overnight. Quantum computing uses low-temperature physics to build qubits, structures that can hold all the possible states, and then constructs quantum circuits that embody complex algorithms and quickly collapse probabilities to answer problems that would take many thousands of years with conventional computers.

Quantum computing factorization tools such as Schor’s Algorithm require millions of qubits to factor a single public key, and today’s quantum computers offer a mere handful of qubits. The technology that underpins quantum computing is advancing rapidly, with Microsoft and other companies developing new materials and error correction techniques to deliver stable qubits at scale and at an economically feasible cost.

That doesn’t mean the entire world of computing will be upended overnight. The first at-scale quantum computers are still years away and are likely to initially be used for pure science. As they get easier and cheaper to build, they will be used by governments and by criminals looking to decrypt decades of financial data and other secrets.

Into the post-quantum world

For now we’re safe. We have time to protect our secrets with new encryption algorithms designed to prevent quantum computing-based factorization. These post-quantum encryption algorithms take a symmetric approach to cryptography as opposed to the commonly used asymmetric algorithms that form the basis of much of today’s public-key infrastructures.

The intent is to use new mathematical approaches that are hard for both conventional and quantum computers to solve. Of course, there are downsides: The keys are larger and need more processing time, compute capacity, and memory. For now, post-quantum cryptography is saved for valuable information where there’s economic incentive for bad actors to use quantum computing to decrypt your data.

Part of the transition to post-quantum cryptography is the standardization of new algorithms and making them available in common cryptographic libraries, especially those used by both OS and applications. Microsoft has been working with the National Institute of Standards and Technology (NIST) to standardize these new algorithms and has begun adding them to its base SymCrypt library.

Adding post-quantum cryptography to Windows

Used across Microsoft’s platforms, SymCrypt is a key component of tools such as Windows’ Cryptographic Primitives Library and also offers support on Linux for use in Azure. It now supports the ML-KEM, ML-DSA, and SLH-DSA post-quantum cryptographic algorithms. The field is still evolving, and although you can use these algorithms now, better ones may come along in the future, so be ready to change if necessary.

ML-based algorithms use a Module Lattice (ML) approach, while SLH is a Stateless Hash. ML-KEM was originally known as Kyber and uses a mix of mathematical techniques to increase the complexity of the process used to generate a key pair. Module lattice techniques are based on what are called “lattice problems,” which are hard to solve using computers. In fact, the hardest versions are so complex that even quantum computers will be challenged. It gets even more difficult when combined with an approach called “learning with errors” that adds noise to the process. This combination is why NIST has chosen ML-based algorithms for the FIPS-203 and 204 standards.

Preparing for the future, today

These algorithms are now available for Windows developers using Windows Insider builds as part of its Cryptography API Next-Generation libraries. This first release gives you access to ML-KEM for key encapsulation and ML-DSA for digital signatures. Using these now starts to protect you from what’s known as “harvest now, decrypt later” attacks.

By keeping samples of encrypted data (especially key exchanges) to decrypt when quantum computers become usable, historic data that was secret will be easily recovered, opening trails of financial transactions or government messages that could still have relevant information. Microsoft suggests you mix these new algorithms with existing ones to give you deeper defenses.

You can use a less computationally intensive version of ML-KEM for now while you prepare for a complete shift to newer cryptographic systems and any necessary supporting hardware. It’s likely that post-quantum cryptography will require a new generation of processor instructions or even dedicated accelerators to get the performance users and applications require.

Microsoft is adding support for post-quantum cryptography in its wincrypt tool, which provides APIs for the Windows certificate handling tools. You will be able to use ML-DSA certificates, managing them in the Windows certificate store and checking validity and trust.

Building post-quantum cryptography apps

At the heart of Microsoft’s Windows implementation of post-quantum cryptography is what it calls “Cryptography API: Next Generation” (CNG). CNG is intended to replace the current Windows cryptography APIs, so it makes sense as the home for next-generation cryptosystems like ML-KEM and ML-DSA. It’s a low-level library for use with C or C++. It’s been in development for some time now and is mature enough to use as it offers a flexible set of features to support most common use cases.

Microsoft’s CNG documentation recently added sample C++ code for working with both ML-DSA and ML-KEM. You can use familiar tools like Bcrypt to first load the post-quantum encryption algorithm you want to use from Microsoft’s own implementation (though as always you have the option of using a third-party version).

Generating a key pair uses the same steps as traditional encryption, generating pairs and setting their properties. For example, with ML-DSA, this sets the parameter set that’s being used. Choosing the right one is important, as this affects both the strength of the encryption method and its performance. As always this is a trade-off: The stronger the encryption, the longer it will take to create the key pair or a hash.

The process of generating a key or a hash with a post-quantum algorithm will be much the same as working with any other cryptographic algorithm today. Along with snippets of sample code, Microsoft provides complete modules you can use as the basis of any code you write.

Microsoft’s Linux post-quantum tools

Microsoft isn’t only delivering post-quantum cryptography in Windows, it’s also using SymCrypt as a cryptography provider for OpenSSL on Linux. This is intended to provide FIPS certification, something that it needs for its Azure government cloud services. This is being used to test post-quantum-based Transport Layer Security (TLS) operations using hybrid key exchange.

This is only a first step to robust post-quantum cryptography across the Microsoft platform, as the necessary standards themselves are still in their infancy. More algorithms will be added, with support for Windows TLS as part of its TLS 1.3 implementation. It’s also likely to be used sooner rather than later in Active Directory as part of its certificate services, generating ML-DSA-based certificates.

Microsoft is working on what it calls “crypto agility,” the ability to swap out new algorithms as they develop, and is using hybrid techniques that mix current techniques with post-quantum cryptography to balance both resources and protection while support and algorithms mature.

Post-quantum cryptography isn’t essential yet, but neither can you ignore it. It’s a good idea to try out these new features and see how the new algorithms affect your applications. If certificates and signatures take longer to use and require more resources, it’s important to understand how these latencies will impact your applications and whether you need to consider investing in new hardware now rather than waiting until the last minute.

When working with minimal APIs in ASP.NET Core, you can define routes for the HTTP verbs using mapping methods such as MapGet, MapPut, MapPost, and MapDelete. While these methods allow you to route each request to the correct destination, you should also have a way to validate route parameters ahead of executing the action method. To do this, you can take advantage of route constraints to define patterns based on the API behavior you need.

In an earlier post here, we discussed how to work with route constraints when building controller-based APIs in ASP.NET Core Web API. In this post we will examine how we can work with route constraints when building minimal APIs. To use the code examples provided in this article, you should have Visual Studio 2022 installed in your system. If you don’t already have a copy, you can download Visual Studio 2022 here.

What is a route constraint? Why is it needed?

A route constraint in ASP.NET Core is a guardrail for the URL. It is a mechanism that enables you to determine, in plain terms, whether an incoming request matches predefined criteria and should be processed. Route constraints in ASP.NET Core are used to filter out unwanted requests or prevent invalid data from reaching your controller actions.

You can take advantage of the set of classes available as part of the Microsoft.AspNetCore.Routing.Constraints namespace to define route constraints. You typically combine multiple constraints when defining your application’s routing configuration. For example, you may want to define a route constraint that allows only positive integers in the route parameter. You may also want to enforce a specific length for a route parameter.

By ensuring that only requests that match your specific criteria are actually processed by your action methods, route constraints improve the security and performance of your application. Plus, route constraints provide a cleaner and simpler way to filter requests than having to write boilerplate and complex code. In other words, they also help to make your application easier to maintain.

Create an ASP.NET Core Web API project in Visual Studio 2022

To create an ASP.NET Core Web API project in Visual Studio 2022, follow the steps outlined below.

1. Launch the Visual Studio 2022 IDE.
2. Click on “Create new project.”
3. In the “Create new project” window, select “ASP.NET Core Web API” from the list of templates displayed.
4. Click Next.
5. In the “Configure your new project” window, specify the name and location for the new project. Optionally check the “Place solution and project in the same directory” check box, depending on your preferences.
6. Click Next.
7. In the “Additional Information” window shown next, select “.NET 9.0 (Standard Term Support)” as the framework version and ensure that the “Use controllers” box is unchecked since we’ll be using Minimal APIs in this project.
8. Elsewhere in the “Additional Information” window, leave the “Authentication Type” set to “None” (the default) and make sure the check boxes “Enable Open API Support,” “Configure for HTTPS,” and “Enable container support” remain unchecked. We won’t be using any of those features here.
9. Click Create.

We’ll use this ASP.NET Core Web API project to work with the REPR (request-endpoint-response) design pattern in the sections below.

Applying route constraints in minimal APIs

Route constraints can be applied in either of two ways:

1. Using an inline constraint by specifying a constraint parameter in the MapControllerRoute method.
2. Using a route attribute in the controller or any of its action methods.

Use an inline constraint to apply route constraints

The following code snippet shows how you can apply a route constraint in the MapControllerRoute method.

endpoints.MapControllerRoute(  
name: "default",  
pattern: "controller=Home}/{action=Index}/{id:int?}");  

Use route parameters to apply route constraints

You can leverage route parameter constraints to specify rules for your route parameters using the following syntax.

{parameter:constraint}

The following code snippet illustrates how you can enforce that a parameter must be an integer or match a specific pattern.

app.MapGet("/orders/{id:int}", (int id) => $"Order Id: {id}");

Using route constraints for low-level validations

You can apply route constraints to perform low-level validations in minimal APIs. We’ll examine how this can be achieved in this section.

Applying a route constraint in the MapController method

Let us first use inline constraints to perform the validation. The following code snippet shows how you can use the MapControllerRoute method to apply a route constraint on your endpoint. In this case, the constraint requires that the author Id be an integer.

app.MapControllerRoute(
    name: "onlyInteger",
    pattern: "author/{id:int}",
    defaults: new { controller = "Author", action = "Author Details" });

Similarly, you can specify that the firstname parameter for the /author endpoint must have a length greater than or equal to three, meaning that thefirstname of an author must contain a minimum of three characters. The following code snippet illustrates how you can specify this in your endpoint as a route constraint.

app.MapControllerRoute(
    name: "nameLength",
    pattern: "author/{firstname:minlength(3}",
    defaults: new { controller = "Author", action = "Get Author"});

Applying a route constraint in the MapGet, MapPut, and MapPost methods

Next we’ll examine how we can perform the validation using route parameter constraints. Consider the following C# class named Author.

public class Author
{
    public int AuthorId { get; set; }
    public string FirstName { get; set; } = string.Empty;
    public string LastName { get; set; } = string.Empty;
    public string Address { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
    public string Phone { get; set; } = string.Empty;
}

The following code snippet shows how you can retrieve data from the HTTP GET endpoint route /authors/{authorId:int}.

app.MapGet("/authors/{id:int}", (int id) => $"Author Id: {id}");

Similarly, the following HTTP POST endpoint accepts an author Id and the count of books written by the author and returns a text message.

app.MapPost("/author/{authorId:int:min(1)}/books/{count:int:min(1)}",
    (int authorId, int count) => 
$"Author with Id {authorId} has written {count} books.");

As shown in the preceding code example, both the authorId and the count parameters should have a minimum integer value of 1.

The code snippet below shows how you can use the HTTP PUT endpoint to update the count of books authored by an author identified by authorId, taking advantage of the route parameter constraint illustrated above.

app.MapPut("/author/{authorId:int:min(1)}/books/{count:int:min(1)}",
    (int authorId, int count) => $"Author with Id {authorId} has written {count} books.");

Example of a route constraint in action

Finally, let’s examine how we can specify route constraints when passing objects and primitive data types (char, int, etc.) as parameters. Consider the following HTTP POST endpoint, which adds a new author and the number of books authored to a database.

app.MapPost("/authors/{count:int:min(1)}", (Author author, int count) =>
  Results.Ok($"1 new author record of an author who has written {count} " +
    $"books has been added to the database...")
);

Let’s invoke this endpoint using Postman. We’ll send the following JSON data for our new author in the body of the request.

{
  "authorId": "1",
  "firstName": "Joydip",
  "lastName": "Kanjilal",
  "address": "Hyderabad, India",
  "email": "joydipkanjilal@yahoo.com",
  "phone": "1234567890"
}

Our route constraint requires us also to specify the count of books written by the author in the URL. Further, it requires that the count be a minimum integer value of 1. Figure 1 shows the output in Postman when we pass a count of 5.

Foundry

Let’s see what happens when we violate the route constraint. Figure 2 shows the output in Postman when we pass a count parameter of 0. Note that if we specify a value less than 1 for the count parameter, a HTTP 404 error will be returned in the response.

Foundry

Not for data validation

Keep in mind that you should not use route constraints for input data validation. If your endpoints contain route constraints that validate input data, an invalid input will return a 404 Not Found response, not a 400 Bad Request response. Remember, the purpose of route constraints is to disambiguate similar routes (i.e., to help ASP.NET Core efficiently resolve requests), not to validate the input data for your route.

You can also take advantage of custom route constraints in ASP.NET Core to validate route values and avoid passing unwanted or unnecessary requests to action methods. You can refer to Microsoft’s documentation to learn about all of the supported route constraints.

Google has introduced Gemini CLI, an open-source AI agent that brings Gemini AI capabilities right to a developer’s terminal.

Unveiled June 25, Gemini CLI is a command-line AI workflow tool that connects to a developer’s tools, understands the developer’s code, and accelerates the developer’s workflow. Gemini CLI gives developers a direct path from their prompt to Google’s Gemini AI model, the company said. “Gemini CLI is an agent that runs in your terminal that brings the power of Gemini in a very lightweight way to your terminal,” said Taylor Mullen, Google senior staff software engineer, in a Google briefing on June 24. “We think Gemini CLI is going to fundamentally change how developers interact with AI.”

Gemini CLI can be used for tasks ranging from content generation and problem-solving to task management and deep research. The capabilities of the multimodal reasoning model include code understanding, file manipulation, command execution, and dynamic troubleshooting, Google said. The company said it built Gemini CLI to be extensible, leveraging standards such as Model Context Protocol (MCP), system prompts, and settings for personal and team configuration.

With Gemini CLI, developers can do specific tasks including the following:

• Query and edit large code bases in and beyond Gemini’s 1M token control window.
• Generate new apps from PDFs or sketches, using Gemini’s multimodal capabilities.
• Automate operational tasks, such as querying pull requests or handling complex releases.
• Ground queries using the Google Search tool built into Gemini.
• Use tools and MCP servers to connect new capabilities including media generation with Imagen, Veo, or Lyria.

Offered via an Apache 2.0 license, Gemini CLI has been integrated with Google’s AI coding assistant, Gemini Code Assist. Users of Gemini Code Assist on free, Standard, and Enterprise plans get prompt-driven, AI-powered coding in both Visual Studio Code and Gemini CLI, Google said. Developers can use Gemini CLI free of charge by logging in with a personal Google account to get a free Gemini Code Assist license.

What is most striking about Python’s latest wave of third-party tooling is that they aren’t written in Python. Instead, many of the newer tools for project management, code formatting, and now type checking, are written in Rust.

This isn’t a swipe at Python; every language has its place. But modern language tooling demands a real-time feedback loop that Python can’t always deliver at the speed required. Rust fills that gap. Modern project management tools like uv and code formatters like ruff run fast and lean thanks to Rust.

The newest projects in this space aim to provide type-checking tools for Python that are faster and potentially more powerful than Python-based tools like mypy and pyright.

Ty from Astral (makers of the uv package manager and the ruff code formatter) and Pyrefly from Meta have essentially the same use case: providing high-speed type checking and language services for Python. Both have comparable performance, running many times faster than similar Python-based projects. This article tells you where these new tools stand right now in terms of usability and features.

Pyrefly

Pyrefly is not the first Python type-checking tool from Meta. Previously, the company delivered Pyre, written in OCaml. Pyre has since been retired; Pyrefly, written from scratch in Rust, replaces it.

Run Pyrefly out of the box on an existing Python codebase, and you’ll typically get a flood of errors the first time around. If you use the command pyrefly check --suppress-errors, all the flagged errors will be suppressed in your source via specially interpreted comments. You can then selectively remove those suppressions and run pyrefly check --remove-unused-ignores to clean up the codebase as you go. This allows you to migrate an untyped codebase gradually.

Pyrefly, like all modern Python tooling, uses pyproject.toml to store its project-level configuration data. You can also add per-directory configurations with standalone pyrefly.toml projects that use the same syntax. Or, you can provide directory-specific overrides for options in a single config file.

The list of linted error types is comparable to what mypy and Pyright can handle. Migrating from both tools is easy, as Pyrefly can do it automatically. In Pyright’s case, there’s almost a one-to-one mapping for the error-checking settings, so the change isn’t too jarring.

For a project in its early stages, Pyrefly already feels fleshed out. Detailed documentation, a VS Code extension, and even an online sandbox where you can try it out are all already here. If you are using the uv tool, you can run uvx pyrefly to experiment with it on a codebase without having to install anything. Note that this causes uv to be used as the virtual environment provider for Python, so it may generate spurious errors if you are using a different venv for your project.

Ty

Astral’s ty project is also still in its early stages, and it shows. Its documentation isn’t as fleshed-out as Pyrefly’s, and its feature set is less impressive. To be fair, the project was only recently made public and is admittedly in its early stages.

You can install Ty from pip or run it from uvx. It intelligently detects a source directory in a pyproject.toml-configured project, so it doesn’t mistakenly chew through Python files in your project’s virtual environment. But its configuration options are more minimal than Pyrefly’s; for instance, excluding files from checks is done via .gitignore or other external files rather than from configuration rules.

Ty’s ruleset for checking files seems more condensed than Pyrefly or existing tools, although it covers some cases not found elsewhere. For instance, while it doesn’t check for async errors, Ty does detect if class definitions have conflicting usages of __slots__, although the former seems like a far more common problem than the latter.

Despite being in its early stages, ty already has two key features nailed down. It is compatible with the Language Server Protocol, and it offers a VS Code extension to leverage that. Another plus—one significant enough to call out this early on—is the level of detail in its error reports. Pyrefly’s errors report the line number and type of error, but ty calls out the error akin to what you’d see in modern Python’s contextually detailed error messages.

Conclusion

With the performance playing field about level between the two tools, Pyrefly is the more immediately useful project. Pyrefly offers a broader existing feature set, better documentation, and tooling to allow elegant migration from other type-checkers and onboarding existing codebases. That said, ty is in its early stages, so it’ll be worth circling back to both tools once they are out of their respective alpha and beta phases.