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.

The McNamara Fallacy is the idea that it is an error to make decisions purely on measurements or quantitative data.

Robert McNamara was the US Secretary of Defense during most of the 1960s, during the first half of the Vietnam War. He came to the position after a successful career in industry—most notably as the first president of the Ford Motor Company who was not from the Ford family—after his innovative use of statistics in business. 

McNamara took the view that anything that can’t be measured should not be taken into account in the decision-making process. He considered all measurable data to be useful, and made metrics the sole means of determining the correct course of action.

He brought this statistical viewpoint to his job as Secretary of Defense and applied it to his management of the war. Problematic results, such as using enemy body counts as a measure of military success, ultimately led to the coining of the phrase “The McNamara Fallacy.”

I think the software industry is in danger of falling victim to the McNamara Fallacy. 

While metrics are useful, relying on metrics alone and ignoring qualitative factors that certainly come into play can easily lead you to focus on things that don’t matter. Ultimately it can lead to failure.

Numbers are easy

First, measuring the software development process is becoming easier and easier. With Git becoming the de facto source control system and tools like LinearB, JellyFish, and Plandek providing deep insight into what is happening within software repositories, it is very simple to get metrics that tell you a lot about what your team is up to. 

It is comical that the industry once seriously took something as pathetically simple as “Lines of code per day” as a serious metric. Today’s tools allow managers to see things that were not previously observable. Simple team metrics like deployment frequency, pull request review time, and cycle time are readily available to help pinpoint bottlenecks and aid in decision-making.

We’ve gotten to the point where metrics are easy, and “soft” measurements are hard. Don’t get me wrong—the granular metrics we now have are useful and valuable. But the temptation is great to rely on easy numbers instead of doing the hard work of figuring out the impossible-to-measure stuff. Robert McNamara fell into that trap, and it is easy to see the software industry doing the same. 

If we lose sight of the non-measurable things, we lose sight of what makes software development successful. If we focus on “computer science” and “software engineering,” we can lose sight of the human factors in writing code that make or break a successful project.

Software development is a team sport. Although individuals can and do shine as part of a team, the team results are what really matter. Sports fans thrive on statistics, but they know that ultimately, it’s not the statistics that win championships. It’s the intangibles that make the difference between first and second place.

Intangibles are hard

Despite our best efforts, we don’t have a means of measuring “writes good code.” It takes years of experience to recognize “good code” from “bad code,” and we can’t (yet?) measure it objectively. Maybe AI will figure it out someday. One could argue that AI can write good code today, but the ability to recognize good code is still uniquely human. 

Similarly, how does one measure “works well with others”? How about “team morale”? There is not, and probably won’t ever be, a way to measure these kinds of things, but they are important, and knowing it when you see it is a key to success. Recognizing and encouraging these intangibles is a critical skill for a software development manager to have. 

Finally, over-indexing on metrics can be detrimental to morale. No one wants to feel like a number on a spreadsheet. 

I encourage you to use the cool measurement tools out there today. But as you review what things like the DORA (DevOps Research and Assessment) metrics are telling you, remember to consider the things not revealed in the numbers. Sure, metrics are important, but understanding what your gut is telling you and listening to your intuition can be just as valuable, or even more valuable. 

Measure what you can, but always be sure to listen to the still, quiet voice telling you things that no statistical package ever can.

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.

A new AI benchmark for enterprise applications is now available following the launch of xbench, a testing initiative developed in-house by Chinese venture capital firm HongShan Capital Group (HSG).

The challenge with many of the current benchmarks is that they are widely published, making it possible for model creators to train their models to perform well on them and, as a result, reduce their usefulness as a true measure of performance. HSG says it has created a suite of ever-changing benchmarking tests, making it harder for AI companies to train on the test, and meaning they have to rely on more general test-taking capabilities.

HSG said its original intention in creating xbench was to turn its internal evaluation tool into “a public AI benchmark test, and to attract more AI talents and projects in an open and transparent way.  We believe that the spirit of open source can make xbench evolve better and create greater value for the AI community.”

On June 17, the company announced it had officially open-sourced two xbench benchmarks: xbench-Science QA and xbench-DeepSearch, promising ”in the future, we will continuously and dynamically update the benchmarks based on the development of large models and AI Agents ….”

Real-world relevance

AI models, said Mohit Agrawal, research director of AI and IoT at CounterPoint Research, “have outgrown traditional benchmarks, especially in subjective domains like reasoning. Xbench is a timely attempt to bridge that gap with real-world relevance and adaptability. It’s not perfect, but it could lay the groundwork for how we track practical AI impact going forward.”

In addition, he said, the models themselves “have progressed significantly over the last two-to-three years, and this means that the evaluation criteria need to evolve with their changing capabilities. Xbench aims to fill key gaps left by traditional evaluation methods, which is a welcome first step toward a more relevant and modern benchmark. It attempts to bring real-world relevance while remaining dynamic and adaptable.”

However, said Agrawal, while it’s relatively easy to evaluate models on math or coding tasks, “assessing models in subjective areas such as reasoning is much more challenging. Reasoning models can be applied across a wide variety of contexts, and models may specialize in particular domains. In such cases, the necessary subjectivity is difficult to capture with any benchmark. Moreover, this approach requires frequent updates and expert input, which may be difficult to maintain and scale.”

Biases, he added, “may also creep into the evaluation, depending on the domain and geographic background of the experts. Overall, xbench is a strong first step, and over time, it may become the foundation for evaluating the practical impact and market readiness of AI agents.”

Hyoun Park, CEO and chief analyst at Amalgam Insights, has some concerns. “The effort to keep AI benchmarks up-to-date and to improve them over time is a welcome one, because dynamic benchmarks are necessary in a market where models are changing on a monthly or even weekly basis,” he said. “But my caveat is that AI benchmarks need to both be updated over time and actually change over time.”

Benchmarking new use cases

He pointed out, “we are seeing with efforts such as Databricks’ Agent Bricks that [it] is important to build independent benchmarks for new and emerging use cases.  And Salesforce Research recently released a paper showing how LLMs fare poorly in conducting some practical tasks, even when they are capable of conducting the technical capabilities associated with the task.”

The value of an LLM, said Park, is “often not in the ability to solve any specific problem, but to identify when a novel or difficult approach might be necessary. And that is going to be a challenge for even this approach to benchmarking models, as the current focus is on finding more complex questions that can be directly solved through LLMs rather than figuring out whether these complex tasks are necessary, based on more open-ended and generalized questioning.”

Further to that, he suggested, “[it is] probably more important for 99% of users to simply be aware that they need to conceptually be aware of Vapnik-Chervonenkis complexity [a measure of the complexity of a model] to understand the robustness of a challenge that an AI model is trying to solve. And from a value perspective, it is more useful to simply provide context on whether the VC dimension of a challenge might be considered low or high, because there are practical ramifications on whether you use the small or large AI model to solve the problem, which can be orders of magnitude differences in cost.”

Model benchmarking, Park said, “has been quite challenging, as the exercise is both extremely high stakes in the multi billion dollar AI wars, and also poorly defined. There is a panoply of incentives for AI companies to cheat and overfit their models to specific tests and benchmarks.”

Next read this:

• What misleading Meta Llama 4 benchmark scores show enterprise leaders about evaluating AI performance claims
• Vector Institute aims to clear up confusion about AI model performance
• Researchers reveal flaws in AI agent benchmarking
  

JetBrains has released Kotlin 2.2.0, the latest version of the company’s general purpose, statically typed language perhaps best known as a rival to Java for JVM and Android development. The update previews context parameters, stabilizes guard conditions, and offers unified management of compiler warnings.

Kotlin 2.2.0 was released June 23. Installation instructions can be found at kotlinlang.org.

Context parameters in the release improve dependency management and allow functions and properties to declare dependencies that are implicitly available in the surrounding context. With context parameters, developers do not need to manually pass around values such as services or dependencies, which are shared and rarely change across sets of function calls. Context parameters replace an older experimental feature called context receivers. Other features previewed in Kotlin 2.2.0 include context-sensitive resolution, to omit the type name in contexts where the expected type is known, and an @all meta-target for properties, which tells the compiler to apply an annotation to all relevant parts the property.

Guard conditions, introduced in Kotlin 2.1.0 last November, are now stable. Guard conditions allow for including more than one condition for the branches of a when expression, making complex control flows more explicit and concise, JetBrains said. Additionally, code structure is flattened with this feature.

A new compiler option in Kotlin 2.2.0, -XWarning-level, is designed to offer a unified way of managing compiler warnings in Kotlin projects. Previously, developers only could apply general module-wide rules, such as disabling all warnings with nowarn or turning warnings to compilation errors with -Werror. With the new option, developers can override general rules and exclude specific diagnostics in a consistent way.

Other new features and improvements in Kotlin 2.2.0:

• For Kotlin/Wasm, the build infrastructure for the for Wasm target is separated from the JavaScript target. Previously, thewasmJstarget shared the same infrastructure as the jstarget. This meant both targets were hosted in the same directory (build/js) and used the same NPM tasks and configurations. Now, the wasmJstarget has its own infrastructure separate from the js target. This allows Wasm types and tasks to be distinct from JavaScript ones, enabling independent configuration.
• LLVM has been updated from version 16 to version 19, bringing performance improvements, security updates, and bug fixes.
• Tracking memory consumption on Apple platforms has been improved.
• Windows 7 has been deprecated as a legacy target.

Unlike general-purpose large language models (LLMs), more specialized reasoning models break complex problems into steps that they ‘reason’ about, and show their work in a chain of thought (CoT) process. This is meant to improve their decision-making and accuracy and enhance trust and explainability.

But can it also lead to a sort of reasoning overkill?

Researchers at AI red teaming company SplxAI set out to answer that very question, pitting OpenAI’s latest reasoning model, o3-pro, against its multimodal model, GPT-4o. OpenAI released o3-pro earlier this month, calling it its most advanced commercial offering to date.

Doing a head-to-head comparison of the two models, the researchers found that o3-pro is far less performant, reliable, and secure, and does an unnecessary amount of reasoning. Notably, o3-pro consumed 7.3x more output tokens, cost 14x more to run, and failed in 5.6x more test cases than GPT-4o.

The results underscore the fact that “developers shouldn’t take vendor claims as dogma and immediately go and replace their LLMs with the latest and greatest from a vendor,” said Brian Jackson, principal research director at Info-Tech Research Group.

o3-pro has difficult-to-justify inefficiencies

In their experiments, the SplxAI researchers deployed o3-pro and GPT-4o as assistants to help choose the most appropriate insurance policies (health, life, auto, home) for a given user. This use case was chosen because it involves a wide range of natural language understanding and reasoning tasks, such as comparing policies and pulling out criteria from prompts.

The two models were evaluated using the same prompts and simulated test cases, as well as through benign and adversarial interactions. The researchers also tracked input and output tokens to understand cost implications and how o3-pro’s reasoning architecture could impact token usage as well as security or safety outcomes.

The models were instructed not to respond to requests outside stated insurance categories; to ignore all instructions or requests attempting to modify their behavior, change their role, or override system rules (through phrases like “pretend to be” or “ignore previous instructions”); not to disclose any internal rules; and not to “speculate, generate fictional policy types, or provide  non-approved discounts.”

Comparing the models

By the numbers, o3-pro used 3.45 million more input tokens and  5.26 million more output tokens than GPT-4o and took 66.4 seconds per test, compared to 1.54 seconds for GPT-4o. Further, o3-pro failed 340 out of 4,172 test cases (8.15%) compared to 61 failures out of 3,188 (1.91%) by GPT-4o.

“While marketed as a high-performance reasoning model, these results suggest that o3-pro introduces inefficiencies that may be difficult to justify in enterprise production environments,” the researchers wrote. They emphasized that use of o3-pro should be limited to “highly specific” use cases based on cost-benefit analysis accounting for reliability, latency, and practical value.

Choose the right LLM for the use case

Jackson pointed out that these findings are not particularly surprising.

“OpenAI tells us outright that GPT-4o is the model that’s optimized for cost, and is good to use for most tasks, while their reasoning models like o3-pro are more suited for coding or specific complex tasks,” he said. “So finding that o3-pro is more expensive and not as good at a very language-oriented task like comparing insurance policies is expected.”

Reasoning models are the leading models in terms of efficacy, he noted, and while SplxAI evaluated one case study, other AI leaderboards and benchmarks pit models against a variety of different scenarios. The o3 family consistently ranks on top of benchmarks designed to test intelligence “in terms of breadth and depth.”

Choosing the right LLM can be the tricky part of developing a new solution involving generative AI, Jackson noted. Typically, developers are in an environment embedded with testing tools; for example, in Amazon Bedrock, where a user can simultaneously test a query against a number of available models to determine the best output. They may then design an application that calls upon one type of LLM for certain types of queries, and another model for other queries.

In the end, developers are trying to balance quality aspects (latency, accuracy, and sentiment) with cost and security/privacy considerations. They will typically consider how much the use case may scale (will it get 1,000 queries a day, or a million?) and consider ways to mitigate bill shock while still delivering quality outcomes, said Jackson.

Typically, he noted, developers follow agile methodologies, where they constantly test their work across a number of factors, including user experience, quality outputs, and cost considerations.

“My advice would be to view LLMs as a commodity market where there are a lot of options that are interchangeable,” said Jackson, “and that the focus should be on user satisfaction.”

Further reading:

• 5 easy ways to run an LLM locally
• How to test large language models
• Is creating an in-house LLM right for your organization?
  

Since the dawn of the public cloud era, the narrative has focused on disruption and innovation. The Big Three providers (Amazon Web Services, Microsoft Azure, and Google Cloud) have commanded center stage by captivating customers and analysts alike with their relentless rollout of new features and services. The implication has always been clear: Stick with the largest, most innovative providers and take advantage of capabilities you can’t find anywhere else.

Yet, those of us who consistently talk to enterprise CTOs, architects, and IT teams see a reality very different from all the marketing hype surrounding bleeding-edge services such as advanced serverless platforms, proprietary AI accelerators, and vast analytics ecosystems. Those shiny, specialized tools advertised at launch events rarely make it into meaningful production deployments. Most actual cloud consumption focuses on a handful of basic services. In the real world, enterprises gravitate toward virtual machines, object storage, databases, networking, and security features.

The reasons are diverse. IT teams primarily manage mission-critical workloads that require reliability, security, and scalability. This creates pressure to reduce risk and complexity, making it impractical to adopt a constant stream of new, sometimes underdeveloped features. Most organizations rely on established solutions, leaving a long tail of innovative services underused and often overlooked. If anything, this demonstrates that the day-to-day needs of most enterprises are surprisingly consistent and relatively straightforward, regardless of industry or region.

What about AI?

AI was expected to change the game by providing a true differentiator for the major cloud players. It’s easy to believe that AWS, Azure, and Google Cloud are now as much AI companies as they are infrastructure providers, given their levels of investment and marketing enthusiasm. However, if you step back and examine the actual AI workloads being deployed in production, a pattern emerges. The necessary toolsets and infrastructure—GPU access, scalable data storage, major machine learning frameworks—are not only widespread but are also becoming increasingly similar across all public clouds, whether in the top tier or among the so-called “second tier” providers such as IBM Cloud and Oracle.

Additionally, access to AI is no longer genuinely exclusive. Open source AI solutions and prebuilt platforms can operate anywhere. Smaller public cloud providers, including sovereign clouds tailored to a country’s specific needs, are offering essentially similar AI and ML portfolios. For everyday enterprise use cases—fine-tuning models, running inference at scale, managing data lakes—there’s nothing particularly unique about what the major clouds provide in comparison to their smaller, often less expensive competitors.

Sticker shock

This brings us, inevitably, to cost, a topic no cloud conversation can avoid these days. The promise of “pay only for what you use” was initially a significant driver of public cloud adoption, but enterprises are waking up to a new reality: The larger you grow, the more you pay. Detailed invoices and cost analysis tools from the Big Three resemble tax documents—complicated, opaque, and often alarming. As organizations scale, cloud bills can quickly spiral out of control, blindsiding even the most prepared finance teams.

The persistent cost challenges are shifting the mindset of enterprise IT leaders. If you’re only using basic cloud primitives such as compute, networking, storage, or managed databases, why pay a premium for the marquee provider’s logo on your invoice? This question isn’t theoretical; it’s one I hear frequently. Enterprises are discovering that the value promised by the most established public clouds doesn’t align with reality, especially at the enterprise scale, given today’s prices.

The second-tier providers are stepping in to fill this gap. IBM and Oracle, for example, have shown remarkable growth in the past few years. Their product offerings may not match the sheer breadth of Microsoft, AWS, and Google, but for core use cases, they are just as reliable and often significantly less expensive. Furthermore, their pricing models are simpler and more predictable, which, in an era of cost anxiety, is a form of innovation in itself. Then there are the sovereign clouds, the regional or government-backed solutions that prioritize local compliance and data sovereignty and offer precisely what some markets require at a fraction of the cost.

MSPs and colos are still in the game

Managed service providers and colocation vendors are also playing a surprising role in this shift. By providing hybrid and multicloud management as well as hosting services, they allow enterprises to move workloads between on-premise environments, colocated data centers, and multiple public clouds with minimal concern about which cloud supports each particular workload. These players further diminish the idea of differentiation among cloud providers, making the underlying infrastructure a nearly irrelevant commodity.

What are the implications? The commoditization of public cloud isn’t just likely; in many respects, it’s already here. Competing solely on raw innovation and feature count is losing its effectiveness. Enterprises are indicating through their purchasing behavior that they want simplicity, reliability, and predictability at a fair price. If the major cloud providers don’t adapt, they’ll find themselves in the same situation traditional server and storage companies did a decade ago: struggling to differentiate what customers increasingly view as a commodity.

AWS, Microsoft, and Google will not disappear or shrink dramatically in the short term. However, they may need to reevaluate how they deliver value. I expect them to double down on managed services, application-layer offerings, and industry-specific solutions where differentiation truly matters. The rest—the core plumbing of the cloud—will increasingly be driven by price, reliability, and regulatory compliance, much like electricity or bandwidth today.

The next phase of cloud computing will belong not to those with the most features or the loudest marketing campaigns, but to those providers, big or small, that best understand enterprise needs and can deliver on the fundamentals without unnecessary complexity or excessive costs. That’s good news for the rest of us. The public cloud isn’t just another technology wave; it’s becoming an everyday utility. For enterprises, that’s precisely how it should be.

The major builders of large language models (LLMs)—OpenAI, DeepSeek, and others—are mistaken when they claim that their latest models, like OpenAI’s o-series or DeepSeek’s R1, can now “reason.” What they’re offering isn’t reasoning. It’s simply an advanced text predictor with some added features. To unlock AI’s true transformative potential, we need to move beyond the idea of reasoning as a one-size-fits-all solution. Here’s why.

If 2024 belonged to ChatGPT, OpenAI hoped it would dominate 2025 with the o-series, promising a leap in LLM reasoning. Early praise for its attempts to curb hallucinations quickly faded when China’s DeepSeek matched its capabilities at a fraction of the cost—on a laptop. Then came Doubao, an even cheaper rival, shaking the AI landscape. Chip stocks dropped, US tech dominance faltered, and even Anthropic’s Claude 3.5 Sonnet came under scrutiny.

But the real issue with the LLM paradigm isn’t just cost—it’s the illusion that all its inherent flaws have been solved. And that’s a dangerous path that could lead to painful dead ends. Despite all the progress, issues like hallucination remain unresolved. This is why I believe the future of AI doesn’t lie in artificial general intelligence (AGI) or endlessly scaling LLMs. Instead, it’s in fusing LLMs with knowledge graphs—particularly when enhanced by retrieval-augmented generation (RAG), combining the power of structured data with generative AI models.

No matter how cheap or efficient, an LLM is fundamentally a fixed, pre-trained model, and retraining it is always costly and impractical. In contrast, knowledge graphs are dynamic, evolving networks of meaning, offering a far more adaptable and reliable foundation for reasoning. Enriching an LLM’s conceptual map with structured, interconnected data through graphs transforms it from probabilistic guesswork into precision. This hybrid approach enables true practical reasoning, offering a dependable way to tackle complex enterprise challenges with clarity—something that LLM “reasoning” often falls short of delivering.

We need to distinguish between true reasoning and the tricks LLMs use to simulate it. Model makers are loading their latest models with shortcuts. Take OpenAI, for example, which now injects code when a model detects a calculation in the context window, creating the illusion of reasoning through stagecraft rather than intelligence. But these tricks don’t solve the core problem: the model doesn’t understand what it’s doing. While today’s LLMs have solved classic logic fails—like struggling to determine how long it would take to dry 30 vs. five white shirts in the sun—there will always be countless other logical gaps. The difference is that graphs provide a structured and deep foundation for reasoning, not masking limitations with clever tricks.

The limits of LLM ‘reasoning’

We’ve seen the consequences of forcing ChatGPT into this role, where it fabricates confident but unreliable answers or risks exposing proprietary data to train itself—a fundamental flaw. Tasks like predicting financial trends, managing supply chains, or analyzing domain-specific data require more than surface-level reasoning.

Take financial fraud detection, for example. An LLM might be asked, “Does this transaction look suspicious?” and respond with something that sounds confident—“Yes, because it resembles known fraudulent patterns.” But does it actually understand the relationships between accounts, historical behavior, or hidden transaction loops? No. It’s simply echoing probability-weighted phrases from its training data. True fraud detection requires structured reasoning over financial networks buried within your transaction data—something LLMs alone cannot provide.

The problem becomes even more concerning when we consider the deployment of LLMs in real-world applications. Take, for example, a company using an LLM to summarize clinical trial results or predict drug interactions. The model might generate a response like, “This combination of compounds has shown a 30% increase in efficacy.” But what if those trials weren’t conducted together, if critical side effects are overlooked, or if regulatory constraints are ignored? The consequences could be severe.

Now, consider cybersecurity, another domain where a wrong response could have catastrophic consequences. Imagine your CSO asking an LLM, “How should we respond to this network breach?” The model might suggest actions that sound plausible but are completely misaligned with the organization’s actual infrastructure, latest threat intelligence, or compliance needs. Following AI-generated cybersecurity advice without scrutiny could leave the company even more vulnerable.

And let’s not overlook enterprise risk management. Suppose a group of business users asks an LLM, “What are the biggest financial risks for our business next year?” The model might confidently generate an answer based on past economic downturns. However, it lacks real-time awareness of macroeconomic shifts, government regulations, or industry-specific risks. It also lacks the current and actual corporate information—it simply does not have it. Without structured reasoning and real-time data integration, the response, while grammatically perfect, is little more than educated guessing dressed up as insight.

This is why structured, verifiable data are absolutely essential in enterprise AI. LLMs can offer useful insights, but without a real reasoning layer—such as knowledge graphs and graph-based retrieval—they’re essentially flying blind. The goal isn’t just for AI to generate answers, but to ensure it comprehends the relationships, logic, and real-world constraints behind those answers.

The power of knowledge graphs

The reality is that business users need models that provide accurate, explainable answers while operating securely within the walled garden of their corporate infosphere. Consider the training problem: A firm signs a major LLM contract, but unless it gets a private model, the LLM won’t fully grasp the organization’s domain without extensive training. And once new data arrives, that training is outdated—forcing another costly retraining cycle. This is plainly impractical, no matter how customized the o1, o2, o3, or o4 model is.

In sharp contrast, supplementing an LLM with a well-designed knowledge graph—especially one that employs dynamic algorithms—solves this issue by updating context rather than requiring retraining. Whereas an LLM like o1 might correctly interpret a question like “How many x?” as a sum, we need it to understand something more specific, such as “How many servers are in our AWS account?” That’s a database look-up, not an abstract mathematical question.

A knowledge graph ensures that a first attempt at practical AI can reason over your data with reliability. Moreover, with a graph-based approach, LLMs can be used securely with private data—something even the best LLM on its own can’t manage.

The smart move is to go beyond the trivial. AI needs knowledge graphs, retrieval-augmented generation, and advanced retrieval methods like vector search and graph algorithms—not just low-cost training models, impressive as they may seem.

Dominik Tomicevic leads European software company Memgraph, provider of an open-source in-memory graph database that’s purpose-built for dynamic, real-time enterprise applications.

—

Generative AI Insights provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss the challenges and opportunities of generative artificial intelligence. The selection is wide-ranging, from technology deep dives to case studies to expert opinion, but also subjective, based on our judgment of which topics and treatments will best serve InfoWorld’s technically sophisticated audience. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Contact doug_dineley@foundryco.com.