Microsoft’s Windows Copilot Runtime, which allows developers to integrate AI capabilities into Windows, is being fitted with AI-backed APIs for image processing. It will also gain access to Phi 3.5 Silica, a custom-built generative AI model for Copilot+ PCs.

Announced at this week’s Microsoft Ignite conference, the new Windows Copilot Runtime imaging APIs will be powered by on-device models that enable developers and ISVs to integrate AI within Windows applications securely and quickly, Microsoft said. Most of the APIs will be available in January through the Windows App SDK 1.7 experimental 2 Experimental release.

Developers will be able to bring AI capabilities into Windows apps via these APIs:

• Image description, providing a text description of an image.
• Image super resolution, increasing the fidelity of an image as well as upscaling the resolution of an image.
• Image segmentation, enabling the separation of foreground and background of an image, along with removing specific objects or regions within an image. Image editing or video editing apps will be able to incorporate background removal using this API, which is powered by the Segment Anything Model (SAM).
• Object erase, enabling erasing of unwanted objects from an image and blending the erased area with the remainder of the background.
• Optical character recognition (OCR), recognizing and extracting text present within an image.

Phi 3.5 Silica, built from the Phi series of models, will be included in the Windows Copilot Runtime out of the box. It will be custom-built for the Snapdragon X series neural processing unit (NPU) in Copilot+ PCs, enabling text intelligence capabilities such as text summarization, text completion, and text prediction, Microsoft said.

Microsoft has added new security features to Windows Subsystem for Linux (WSL) and the Windows Package Manager (WinGet), including integration with Microsoft Entra ID (formerly Active Directory) for identity-based access control. The goal is to enable IT admins to more effectively manage the deployment and use of these tools in enterprises.

The improvements were announced at the Microsoft Ignite conference.

For WSL, Microsoft Entra ID integration is in private preview. Entra ID integration will provide a “zero trust” experience for users accessing enterprise resources from within a WSL distribution, providing better security around passing Entra tokens and an automatic connection for Linux processes to use underlying Windows authentication, Microsoft said. Further, Intune device compliance integration with WSL, now generally available, provides IT admins with an interface to control WSL distribution and version usage in enterprises through conditional access.

WSL also will have a new distribution architecture to provide a more efficient way for enterprise developers, IT professionals, and users to set up and customize WSL distributions while complying with enterprise security policies. IT professionals can build custom distributions by bundling together necessary applications, binaries, and tools, and distribute them to users. WSL distributions now can be installed through configurable source locations, separate from Microsoft Store. These features are to be previewed in the coming months.

For WinGet, a command line tool that allows users to install Windows apps, Entra ID integration is available in public preview. The integration allows IT professionals to manage WinGet access so that only authorized users within an enterprise can install software onto their devices. Also, WinGet now allows enterprise customers to download line-of-business apps from any WinGet source using the WinGet Download command. WinGet Download is now generally available.

Microsoft is packaging its Azure AI Studio and other updates into a new service — Azure AI Foundry in response to enterprises’ need to develop, run, and manage generative AI applications.

Launched at the company’s annual Ignite conference, Azure AI Foundry is being marketed as a “unified application platform in the age of AI,” akin to the Azure AI Studio, which was released in November last year and made generally available in May this year.

[ Related: Microsoft Ignite 2024 news and insights ]

Azure AI Studio was developed and marketed by Microsoft as a generative AI application development platform with support for model filtering, model benchmarking, prompt engineering, retrieval augmented generation, agent building, AI safety guardrails, and to an extent low-code development.

Azure AI Studio also has speech, vision, and language capabilities to help build apps with support for voice and the ability to read text and images in multiple languages.

However, Azure AI Studio is not to be confused with the Microsoft Copilot Studio, which experts claim is a  “2nd-floor level low-code tool for customizing chatbots.”

What is Azure AI Foundry?

The new Azure AI Foundry service comprises the Azure AI Foundry portal, which was earlier the Azure AI Studio, the Azure AI Foundry software development kit (SDK), Azure AI Agents, and pre-built app templates along with some tools for AI-based application development.

The Azure AI Foundry SDK, in turn, comprises the AI toolchain that makes Azure AI services and capabilities accessible from tools such as GitHub and Visual Studio, the company said in a statement, adding that these tools allow developers to build an application that can be integrated with another program.

Microsoft said it has morphed the Azure AI Studio into the Azure AI Foundry portal along with new updates that help in the development, running, and management of AI-based applications.

Azure AI Foundry would act like a management console, akin to the AWS Management Console that lets enterprise users access different tools including a cost estimator, usage checker, billing console, and other core services offered as part of its cloud services.

Inside the Azure AI Foundry portal, Microsoft said it was introducing a new management center experience that brings subscription information, such as connected resources, access privileges, and quota usage.

“This can save development teams valuable time and facilitate easier security and compliance workflows throughout the entire AI lifecycle,” the company said in a statement.

Other updates include the addition of new specialized industry-specific generative AI models from companies including Bayer, Sight Machine, Rockwell Automation, Saifr/Fidelity Labs, and Paige.ai targeting the healthcare, finance, IT, and the manufacturing sector among others.

What is the new Azure AI Agent service?

The new Azure AI Agent service, which comes packaged with Azure AI Foundry, is an upgrade over the agents available inside Azure AI Studio and falls into the genre of autonomous AI agents that Microsoft showcased last month.

Autonomous AI agents, otherwise known as agentic AI, can perform tasks without human intervention and Microsoft’s new agents, according to the company, are targeted at automating business processes.

However, the company pointed out that the agents will ask its users for a final review or call for them to take action before it completes the process. This process has been put in place to ensure that these autonomous agents operate responsibly, it explained.

In contrast, the agents bundled inside Azure AI Studio were conversational retrieval agents, which is essentially an expansion from the idea of conversational large language models (LLMs) combined with tools, code, embeddings, and vector stores. Other updates that are packaged with Azure AI Foundry includes updates to Azure AI Search, which now includes a generative query engine; migrated features from Azure OpenAI service, simplified navigation, and more detailed documentation.

From automating workflows to unlocking new insights, generative AI models like OpenAI’s GPT-4 are already delivering value in enterprises across every industry. But with this power comes a critical challenge for organizations: How do they secure and manage the expanding ecosystem of AI applications that touch sensitive business data? Generative AI solutions are popping up everywhere—embedded in platforms, integrated into products, and accessible via public tools.

In this article, we introduce a practical framework for categorizing and securing generative AI applications, giving businesses the clarity they need to govern AI interactions, mitigate risk, and stay compliant in today’s rapidly evolving technology landscape.

Types of AI applications and their impact on enterprise security

AI applications differ significantly in how they interact with data and integrate into enterprise environments, making categorization essential for organizations aiming to evaluate risk and enforce governance controls. Broadly, there are three main types of generative AI applications that enterprises need to focus on, each presenting unique challenges and considerations.

Web-based AI tools – Web-based AI products, such as OpenAI’s ChatGPT, Google’s Gemini, and Anthropic’s Claude, are widely accessible via the web and are often used by employees for tasks ranging from content generation to research and summarization. The open and public nature of these tools presents a significant risk: Data shared with them is processed outside the organization’s control, which can lead to the exposure of proprietary or sensitive information. A key question for enterprises is how to monitor and restrict access to these tools, and whether data being shared is adequately controlled. OpenAI’s enterprise features, for instance, provide some security measures for users, but these may not fully mitigate the risks associated with public models.

AI embedded in operating systems – Embedded AI products, such as Microsoft Copilot and the AI features within Google Workspace or Office 365, are tightly integrated into the systems employees already use daily. These embedded tools offer seamless access to AI-powered functionality without needing to switch platforms. However, deep integration poses a challenge for security, as it becomes difficult to delineate safe interactions from interactions that may expose sensitive data. The crucial consideration here is whether data processed by these AI tools adheres to data privacy laws, and what controls are in place to limit access to sensitive information. Microsoft’s Copilot security protocols offer some reassurance but require careful scrutiny in the context of enterprise use.

AI integrated into enterprise products – Integrated AI products, like Salesforce Einstein, Oracle AI, and IBM Watson, tend to be embedded within specialized software tailored for specific business functions, such as customer relationship management or supply chain management. While these proprietary AI models may reduce exposure compared to public tools, organizations still need to understand the data flows within these systems and the security measures in place. The focus here should be on whether the AI model is trained on generalized data or tailored specifically for the organization’s industry, and what guarantees are provided around data security. IBM Watson, for instance, outlines specific measures for securing AI-integrated enterprise products, but enterprises must remain vigilant in evaluating these claims.

Classifying AI applications for risk management

Understanding the three broad categories of AI applications is just the beginning. To effectively manage risk and governance, further classification is essential. By evaluating key characteristics such as the provider, hosting location, data flow, model type, and specificity, enterprises can build a more nuanced approach to securing AI interactions.

A crucial factor in this deeper classification is the provider of the AI model. Public AI models, like OpenAI’s GPT and Google’s Gemini, are accessible to everyone, but with this accessibility comes less control over data security and greater uncertainty around how sensitive information is handled. In contrast, private AI models, often integrated into enterprise solutions, offer more control and customization. However, these private models aren’t without risk. They must still be scrutinized for potential third-party vulnerabilities, as highlighted by PwC in their analysis of AI adoption across industries.

Another key aspect is the hosting location of the AI models—whether they are hosted on premises or in the cloud. Cloud-hosted models, while offering scalability and ease of access, introduce additional challenges around data residency, sovereignty, and compliance. Particularly when these models are hosted in jurisdictions with differing regulatory environments, enterprises need to ensure that their data governance strategies account for these variations. NIST’s AI Risk Management Framework provides valuable guidance on managing these hosting-related risks.

The data storage and flow of an AI application are equally critical considerations. Where the data is stored—whether in a general-purpose cloud or on a secure internal server—can significantly impact an organization’s ability to comply with regulations such as GDPR, CCPA, or industry-specific laws like HIPAA. Understanding the path that data takes from input to processing to storage is key to maintaining compliance and ensuring that sensitive information remains secure. The OECD AI Principles offer useful guidelines for maintaining strong data governance in the context of AI usage.

The model type also must be considered when assessing risk. Public models, such as GPT-4, are powerful but introduce a degree of uncertainty due to their general nature and the open-source nature of the data they are trained on. Private models, tailored specifically for enterprise use, may offer a higher level of control but still require robust monitoring to ensure security. OpenAI’s research on GPT-4, for instance, illustrates both the advancements and potential security challenges associated with public AI models.

Finally, model training has important risk implications. Distinguishing between generalized AI and industry-specific AI can help in assessing the level of inherent risk and regulatory compliance. Generalized AI models, like OpenAI’s GPT, are designed to handle a broad array of tasks, which can make it harder to predict how they will interact with specific types of sensitive data. On the other hand, industry-specific AI models, such as IBM Watson Health, are tailored to meet the particular needs and regulatory requirements of sectors like healthcare or financial services. While these specialized models may come with built-in compliance features, enterprises must still evaluate their suitability for all potential use cases and ensure that protections are comprehensive across the board.

Establishing a governance framework for AI interactions

Classifying AI applications is the foundation for creating a governance structure that ensures AI tools are used safely within an enterprise. Here are five key components to build into this governance framework:

1. Access control: Who in the organization can access different types of AI tools? This includes setting role-based access policies that limit the use of AI applications to authorized personnel.
   Reference: Microsoft Security Best Practices outline strategies for access control in AI environments.
2. Data sensitivity mapping: Align AI applications with data classification frameworks to ensure that sensitive data isn’t being fed into public AI models without the appropriate controls in place.
   Reference: GDPR Compliance Guidelines provide frameworks for data sensitivity mapping.
3. Regulatory compliance: Make sure the organization’s use of AI tools complies with industry-specific regulations (e.g., GDPR, HIPAA) as well as corporate data governance policies.
   Reference: OECD AI Principles offer guidelines for ensuring regulatory compliance in AI deployments.
4. Auditing and monitoring: Continual auditing of AI tool usage is essential for spotting unauthorized access or inappropriate data usage. Monitoring can help identify violations in real-time and allow for corrective action.
   Reference: NIST AI Risk Management Framework emphasizes the importance of auditing and monitoring in AI systems.
5. Incident response planning: Create incident response protocols specifically for AI-related data leaks or security incidents, ensuring rapid containment and investigation when issues arise.
   Reference: AI Incident Database provides examples and guidelines for responding to AI-related security incidents.

Example: Classifying OpenAI GPT and IBM Watson Health

Let’s classify OpenAI ChatGPT and IBM Watson Health for risk management according to the characteristics we outlined above.

Model	OpenAI GPT	IBM Watson Health
Provider	OpenAI	IBM
Hosting location	Cloud-hosted AI model (Azure)	Cloud-hosted AI model (IBM Cloud)
Data storage and flow	External data processing	Internal data processing
Model type	General public model	Industry-specific public model (healthcare)
Model training	Public knowledge, generalized	Industry-specific model training

Now that we have the classifications, let’s overlay our governance framework.

Model	OpenAI ChatGPT	IBM Watson Health
Access control	ChatGPT, being a general-purpose, cloud-hosted AI, must have strict access controls. Role-based access should restrict its use to employees working in non-sensitive areas (e.g., content creation, research). Employees handling sensitive or proprietary information should have limited access to prevent accidental data exposure.	IBM Watson Health is a highly specialized AI model tailored for healthcare, so access must be limited to healthcare professionals or staff authorized to handle sensitive medical data (PHI). Fine-grained role-based access control should ensure only those with explicit needs can use Watson Health.
Data sensitivity mapping	ChatGPT should be classified under “high-risk” for sensitive data processing due to its public, external data handling nature. Enterprises should map its use to less sensitive data (e.g., marketing or general information) and prevent interaction with customer PII or confidential business data.	Because Watson Health is designed to handle sensitive data (e.g., patient records, PHI), it must align with healthcare-specific data classification systems. All data processed should be marked as “highly sensitive” under classification frameworks like HIPAA and stringent safeguards must be in place.
Regulatory compliance	ChatGPT may struggle to meet strict regulatory standards like GDPR or HIPAA, as it’s not inherently compliant for handling highly sensitive or regulated data. Organizations must ensure that employees do not feed it information governed by strict data privacy laws.	Watson Health is designed to comply with industry regulations like HIPAA for healthcare and HITRUST for data security. However, enterprises still need to ensure that their specific deployment configurations are aligned with these standards, particularly regarding how data is stored and processed.
Auditing and monitoring	Continuous monitoring of interactions with ChatGPT is crucial, especially to track the data that employees share with the model. Logging all interactions can help identify policy violations or risky data-sharing practices.	Given its role in handling sensitive healthcare data, Watson Health requires continuous, real-time auditing and monitoring to detect potential unauthorized access or data breaches. Logs must be securely stored and routinely reviewed for compliance violations.
Incident response planning	Given ChatGPT’s general-purpose nature and external hosting, a specific incident response plan should be developed to address potential data leaks or unauthorized use of the model. If sensitive information is mistakenly shared, the incident must be investigated swiftly.	In case of a data breach or PHI exposure, Watson Health must have a healthcare-specific incident response plan. Rapid containment, remediation, and reporting (including notifications under HIPAA’s breach notification rule) are critical.

Reducing AI risks through AI governance

As AI technology advances, it brings both transformative opportunities and unprecedented risks. For enterprises, the challenge is no longer whether to adopt AI, but how to govern AI responsibly, balancing innovation against security, privacy, and regulatory compliance.

By systematically categorizing generative AI applications—evaluating the provider, hosting environment, data flow, and industry specificity—organizations can build a tailored governance framework that strengthens their defenses against AI-related vulnerabilities. This structured approach enables enterprises to anticipate risks, enforce robust access controls, protect sensitive data, and maintain regulatory compliance across global jurisdictions.

The future of enterprise AI is about more than just deploying the latest models; it’s about embedding AI governance deeply into the fabric of the organization. Enterprises that take a proactive, comprehensive approach will not only safeguard their business against potential threats but also unlock AI’s full potential to drive innovation, efficiency, and competitive advantage in a secure and compliant manner.

Trevor Welsh is VP of products at WitnessAI.

—

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.

I recall my angst about my first visit to an architecture review board (ARB), where a team of enterprise architects reviewed plans for new systems and application architectures. My presentation was required to follow a template and be reviewed by the board’s infrastructure and security leads prior to the presentation.

The corporate CIO selected and procured the technology platforms, so I didn’t expect any issues with using them. However, my teams were still learning about these technologies and the business requirements. At best, we had a conceptual architecture that would go through our agile development process to be refined and improved upon.

Our architecture was approved, but acclimating enterprise architects to a more agile approach to evolving the architecture required some creativity. I tell a longer version of this story in my book, Digital Trailblazer.

Architecture review boards are out of step

To this day, I shiver when I hear leaders speak about their architecture review boards and the process of presenting to them. To be clear, I believe these boards are important, but their missions, processes, and tools must be modernized for today’s faster and more agile development processes. ARBs and enterprise architects also have many opportunities to uplift digital transformation by weighing in on implantation tradeoffs and establishing which non-functional requirements are essential for specific initiatives.

“The role of an architecture review board once was much more autocratic, led by a small group that made decisions for the larger organization under a ‘one-size-fits-all’ philosophy,” says Dalan Winbush, CIO of Quickbase. The democratization of software, particularly through low-code/no-code, agile, and AI technologies, is changing the ARB’s role, said Winbush. Architecture review boards are expected to be more collaborative and responsive, and the ARB’s role is “more expansive in considering governance, security, compliance, data management, connectivity, and collaboration, all in service of larger business goals,” he said. “The ARB’s responsibilities include ensuring the integrity of the application development process, data, and the overall IT infrastructure.”

The Open Group Architecture Framework (TOGAF) version 9.2, published in 2018, describes the role of cross-organization architecture board as overseeing the implementation of strategy. It identifies over 20 responsibilities such as establishing targets for component reuse, providing advice, and resolving conflicts. However, some of the responsibilities listed may cause devops leaders to cringe, such as “providing the basis for all decision-making with regard to the architectures.”

A modernized approach to architecture review boards should start with establishing a partnership, building trust, and seeking collaboration between business leaders, devops teams, and compliance functions. Everyone in the organization uses technology, and many leverage platforms that extend the boundaries of architecture.

Winbush suggests that devops teams must also extend their collaboration to include enterprise architects and review boards. “Don’t see ARBs as roadblocks, and treat them as a trusted team that provides much-needed insight to protect the team and the business,” he suggests.

Architecture review boards can be especially useful for setting guideposts to help teams and organizations navigate competing agendas like these:

• Faster innovation vs. safer compliance
• Experimentation vs. best practices
• Self-organization vs. reliable standards

Let’s look at three scenarios the highlight the role and potential of an enlightened architecture review board.

Innovate architectures and minimize technical debt

For organizations developing microservices, how are standards created to ensure usability, reliability, and ongoing support? How can organizations avoid creating point-solution services, undocumented solutions, and APIs without robust automated testing? Empowering too much autonomy can lead to technical debt and microservices that are hard to support.

Another area of complexity is when organizations support multiple CI/CD tools and empower devops teams to create, customize, and support their own CI/CID pipelines. Over time, the benefits of self-organization diminish, and the cost, complexity, and technical debt can reduce development velocity.

“Applications today are more complex than they were 20 years ago,” says Rob Reid, technology evangelist at Cockroach Labs. “Compare the complexities of managing a microservice architecture to a client-server architecture, and you see why sub-one-hour restoration is a growing pipe dream.

“Deployment pipelines are increasingly non-standard, and every team carefully crafts their own bespoke pipeline using modern tools,” adds Reid. “As teams and technology evolve, knowledge of these pipelines and technologies fades, along with our pipe dreams.”

ARBs can play a role in helping organizations avoid complexity by defining technical debt metrics, promoting self-organizing standards, and guiding devops teams on best practices.

Prioritize and simplify risk remediation

IT teams once captured risk logs in spreadsheets and scored them based on the likelihood of a risk occurrence and its business impact. They then used these scores to prioritize remediations. Today, capturing, prioritizing, and managing risk can be baked into agile development and IT management services with tools like risk register for Jira and Confluence and ServiceNow Risk Management.

However, integrated tools don’t solve the issue of assessing priorities and identifying solutions that minimize remediation costs. ARBs can play a critical role, sometimes acting as product managers over risk backlogs and other times as delivery leaders overseeing implementations.

“If properly empowered, the board should operate as a critical arbiter of the broader conversation about regulatory compliance, best practices, and the continually evolving state of the art to how that translates into the specific actions a technical team takes,” says Miles Ward, CTO of SADA. “It’s easy to look backward at a breach or a cost-overrun and point to broad guidance on how to avoid such a thing; it’s much harder to anticipate, prioritize, and drive to implementations that actually prevent negative outcomes. Companies that tackle the hard part will outperform those who do not.”

Amplify AI, automation, and observability

Devops teams reduce toil by automating the scaffolding processes, including CI/CD, infrastructure as code, and Kubernetes orchestration. Coding copilots enable development teams to prompt for code, while automation and AI agents help IT service managers provide better employee experiences when responding to incidents and requests.

How can ARBs continue to rely on presentations, spreadsheets, and manually created architecture diagrams as their primary communication tools when devops is well down the path of improving productivity using automation and AI?

“Architectural review boards remain important in agile environments but must evolve beyond manual processes, such as interviews with practitioners and conventional tools that hinder engineering velocity,” says Moti Rafalin, CEO and co-founder of vFunction. “To improve development and support innovation, ARBs should embrace AI-driven tools to visualize, document, and analyze architecture in real-time, streamline routine tasks, and govern app development to reduce complexity.”

One opportunity for ARBs is to institute observability standards and site reliability engineering tools. These two areas connect development teams with operational responsibilities, where standards, governance, and platforms provide long-term business value.

“Architectural observability and governance represent a paradigm shift, enabling proactive management of architecture and allowing architects to set guardrails for development to prevent microservices sprawl and resulting complexity,” adds Rafalin.

It’s time to rebrand your architecture review board

I recommend that IT organizations with ARBs rebrand them with a more inviting, open, and inclusive name that connotes collaboration and trust. Words like forum, hub, team, and even council are more inviting than the idea of having to appear in front of a board. The word review suggests a process that is reactionary and judgmental, whereas words like enablement, excellence, and growth suggest increased collaboration with business, devops, and data science teams.

I informally polled my network and the rebrand of “collaboration architecture hub” received the most votes. I like the sound of it. By modernizing their tools, practices, and mindset, enterprise architects participating in such hubs may find a more receptive audience and improve results.

In its 2024 report, Splunk breaks down observability practices into four stages: foundational visibility, guided insights, proactive response, and unified workflows. Based on that, it classifies companies into four stages of observability maturity: beginning, emerging, evolving, and leading.

Splunk found that just 11% of organizations in the study have reached that final stage, and only 8% in the United Kingdom, suggesting that British businesses need to catch up to other countries regarding observability.

Observability versus monitoring

Keep in mind that Splunk is not a disinterested third party; it sells observability tools. I’m not saying they are spinning their statistics, but you’ll never hear a cloud observability company say that cloud observability is not an issue. As always, you need to consider the source to decide if their analysis has some wisdom. In this case, it does.

Observability is the ability to understand what is happening inside a system based on the external data it generates, such as logs, metrics, and traces. This data offers insights into the system’s internal state without directly interacting with it.

In the rapidly evolving world of cloud computing, observability has emerged as a critical asset for organizations navigating the complexities of cloud ecosystems. Cloud architectures have become increasingly dynamic and diverse. Multicloud deployments that span multiple cloud providers and on-premises environments have made gaining meaningful insights into system behavior not just advantageous but essential.

Observability is distinct from traditional monitoring and transcends mere reactive metrics and static dashboards. Monitoring often involves passively consuming information to assess system states. Observability takes an integrative and proactive approach to evaluate the holistic state of systems. It leverages the vast array of data, enabling IT teams to understand current system conditions, anticipate future states, and optimize performance accordingly.

Complexity makes observability a necessary evil

The complexity of modern cloud environments amplifies the need for robust observability. Cloud applications today are built upon microservices, RESTful APIs, and containers, often spanning multicloud and hybrid architectures. This interconnectivity and distribution introduce layers of complexity that traditional monitoring paradigms struggle to capture. Observability addresses this by utilizing advanced analytics, artificial intelligence, and machine learning to analyze real-time logs, traces, and metrics, effectively transforming operational data into actionable insights.

One of observability’s core strengths is its capacity to provide a continuous understanding of system operations, enabling proactive management instead of waiting for failures to manifest. Observability empowers teams to identify potential issues before they escalate, shifting from a reactive troubleshooting stance to a proactive optimization mindset. This capability is crucial in environments where systems must scale instantly to accommodate fluctuating demands while maintaining uninterrupted service.

The significance of observability also lies in its alignment with modern operations practices, such as devops, where continuous integration and continuous delivery demand rapid feedback and adaptation. Observability supports these practices by offering real-time insights into application performance and infrastructure health, allowing development and operations teams to collaborate effectively in maintaining system reliability and agility.

The steps to observability success

The path to effective observability travels through a landscape of complex dependencies, distributed systems, and rapidly changing technologies. To effectively implement observability for their cloud deployments, enterprises should consider the following actions:

• Cultivate a culture that prioritizes observability as a fundamental part of the development and operations processes. This involves recognizing the value of data-driven insights for optimizing performance and reliability.
• Deploy robust observability tools that can collect, analyze, and visualize data from logs, metrics, and traces across all cloud infrastructure components. Ensure these tools integrate seamlessly with existing systems and support multicloud environments.
• Leverage artificial intelligence and machine learning technologies to process large volumes of data and identify patterns or anomalies that could indicate potential issues. A proactive approach can help preempt problems before they impact users.
• Share insights and dashboards to encourage collaboration between development, operations, and business teams. This alignment helps rapidly address issues and improves overall system performance.
• Gain visibility into the entire application stack, from infrastructure to user experience. With a comprehensive view, you can understand how applications perform in real-world scenarios.
• Assess observability practices and tools regularly to ensure they meet evolving business needs. Stay updated with the latest advancements in observability technologies and methodologies to continually enhance capabilities.
• Equip teams with the necessary skills and knowledge to effectively utilize observability tools. Investing in employees can lead to better analysis, troubleshooting, and system optimization.

By taking these steps, enterprises can harness the full power of observability, leading to improved system reliability, faster incident response, and a more robust overall cloud strategy. This is way more complex than the current studies will lead you to believe, so you’re going to have to make some strides on your own.

F# 9, the latest version of Microsoft’s open source functional language, has been released with support for nullable reference types and empty-bodied computation expressions. Standard library improvements also are featured, including random sampling functions.

F# 9 was released in conjunction with the .NET 9 software platform on November 12. Instructions on getting started with F#  can be found at dotnet.microsoft.com.

With nullable reference types in F# 9, F# now has a type-safe way to deal with reference types that can have null as a valid value. While F# was designed to avoid null, it nevertheless can creep in with .NET libraries written in C#. F# 9 also introduces support for empty computation expressions. Writing an empty computation expression will result in a call to the computation expression builder’s Zero method. This is a more natural syntax compared to the previously available builder { () }, Microsoft said.

In the FSharp.Core standard library in F# 9, the  List, Array, and Seq modules have new functions for random sampling and shuffling, making F# easier to use for common data science, machine learning, and other scenarios where randomness is needed. Also with the standard library, Shuffle functions return a new collection of the same type and size, with each item in a randomly mixed position. In another standard library improvement, developers now can use C# collection expressions to initialize F# lists and sets from C#.

F# also brings performance improvements. Equality checks now are faster and allocate less memory, and the compiler now generates optimized code for more instances of start..finish and start..step..finish expressions.

Other new features and improvements in F# 9:

• Hash directives now are allowed to take non-string arguments. Previously, hash directives for the compiler only allowed string arguments passed in quotes.
• The #help directive in F# Interactive now shows documentation for a given object or function, which now can be passed without quotes.
• New or improved diagnostic messages or more precise diagnostic locations are featured in F# 9, such as unions with duplicated fields and active pattern argument count mismatch.
• To align with a pattern in some .NET libraries, where extension methods are defined with the same names as intrinsic properties of a type, F# now resolves these extension methods instead of failing the type check.

Akka, formerly known as Lightbend, has released Akka 3, an update to the JVM-based distributed computing platform that adds a Java SDK as well as serverless and “bring your own cloud” deployment options.

Akka 3 and the company’s name change were announced November 15. Sign-ups to try out Akka can be done at the company website.

The SDK in Akka 3 combines high-level components, a local console, and an event debugger. The composable components, covering endpoints, entities, streaming consumers, workflows, views, and timers, make it easy to build responsive, elastic, and resilient cloud applications, Akka said. While Akka libraries have supported both the Scala and Java languages for many years, the new SDK is based on Java. Akka believes the SDK is simple enough that most engineers, regardless of their language expertise, will be productive with Akka within one day, a company spokesman said.

Deployment options now include serverless, with Akka running the user’s apps in Akka’s cloud, and “bring your own cloud,” with users supplying their own AWS, Microsoft Azure, or Google Cloud cloud instances and Akka bringing the control plane, a cost profile, and managed infrastructure services. In early-2025, the company plans to roll out a self-hosted option for running Akka apps wherever desired, either on-premises or in private or a hybrid cloud.

For cloud deployments, Akka has focused on providing more flexibility regarding how an application is deployed and replicated, supporting single-region/pinned, multi-region/read-replicated, and multi-region/write-replicated topologies. Innovations in Akka 3 include an application runtime with multi-master replication, where each service instance runs in multiple locations, and a PaaS that migrates across hyperscalers, with operations able to stretch an application across multiple clouds and migrate an app from one cloud to another with no downtime or disruption.

Akka enables development of applications that are primarily event-driven. The platform provides libraries, components, sandboxes, build packs, and a cloud runtime, the company said.

As much as we love them, programming languages can often feel like straitjackets. They’re a complex bundle of syntactic rules, and if we break them—even once—the compiler starts screaming out error messages. There are conventions to define every little thing, such as the best way to name variables or how to indent your code. The language designers claim these constraints are a feature, not a bug.

But programming languages don’t need to be that way. Over the years, clever developers have come up with sneaky and not so sneaky ways to write code in their own idiosyncratic styles. Preprocessors can bridge the gap, jumping into the pipeline before the code is compiled to fix all the strange twists and personal styles that keep coding fun.

Preprocessors aren’t new. Languages like C have relied on them for years. But lately they’ve been growing in popularity, as developers create more expressive ways to let programmers write software however they like. When it comes time to compile, all that unique style is quietly removed and replaced, so the final version fits the narrow rules of the language.

In the interest of programmers slipping out of the straitjacket, here’s our list of ways to preprocess your code. Included are language-specific preprocessors, ones that bridge the gap between data scientists and developers, and even one for converting American-style English to something more palatable to our colleagues across the pond.

LESS and SASS

The power and responsibilities given to CSS are now so great that we need a way to bring order to some of the more elaborate layouts seen on modern sites. Both LESS (Leaner CSS) and SASS (Syntactically Awesome StyleSheets) are preprocessors that let you behave more like a programmer by deploying variables and other functions to simplify a CSS layout. If your website design has a dominant color, you’ll only need to define it once. SASS is the more powerful of the two, with more complex options like loops. While it’s leaner, LESS is still powerful enough to get the job done. Either tool lets you bring a programmer’s touch and sensibility to cleaning up the seemingly endless list of CSS layout options.

AbsurdJS

Some people like consistency and prefer to work with one particular language. If you’re a fan of JavaScript and you want to use its power to craft your CSS, then AbsurdJS is the preprocessor for you. The letters JS are in the name, but the goal is CSS. With AbsurdJS, you can use the power of a programming concept like inheritance to produce elaborate CSS layouts. Like LESS and SASS, this is a preprocessor that lets you think like a programmer instead of a designer.

Bython

Some developers like using braces to define blocks of code. Some prefer hitting the spacebar and the tab key. Python was designed for the programmers who love a good indent. Now that it’s more powerful and ubiquitous, some of the curly-brace-loving crowd may want to use Python libraries and tools. Bython is a preprocessor that lets you keep your curly-braces and your Python libraries, too. You just code like you normally would and Bython does the rest. It will automatically replace your curly braces with indents, so you never have to hit the spacebar.

Pypreprocessor

The C language has long offered C coders the chance to make complex decisions about code with preprocessing statements like #ifdef, which turns big blocks of code on and off. Now Python programmers can do the same thing with Pypreprocessor, a dynamic library that lets you use flags and metavariables to make code disappear and reappear at will.

TypeScript

JavaScript was originally designed for web programmers who needed to add short blocks of code to websites that were mostly built from HTML. If you didn’t want to spell out the type of a variable, it was no big deal because the JavaScript code block was small and easy to understand. That’s changed, and now many developers build elaborate and very dynamic sites out of thousands and thousands of lines of JavaScript.

Given the range of JavaScript, some developers now want the assurance that comes from strongly typed code. TypeScript is the answer, and it’s an amazing compromise. Generic JavaScript continues to be acceptable to TypeScript, which means that all the type information you add is optional. TypeScript’s preprocessing stage double checks for errors when it can find them, then spits out something the generic JavaScript engine can process. Some of the most popular JavaScript frameworks, like Angular, now rely on TypeScript for strong typing.

CoffeeScript

For every Python programmer who yearns to be writing with a C-style syntax, there’s a JavaScript programmer who desires the freedom and simplicity of writing Python. CoffeeScript is the answer. There are now a number of variants like ToffeeScript, Civet, Storymatic, and CoffeeScript II: The Wrath of Khan, along with more than a dozen others. All these languages save us from the incredibly onerous task of lifting a right pinkie finger to press the semicolon key. They also offer neat features like asynchronous grammars and elaborate mechanisms for metaprogramming. The result is cleaner code with less punctuation, which is—in the eyes of CoffeeScript programmers, at least—much easier to read.

Handlebars and Pug

Modern code typically contains many blocks of text with messages for eventual human users. These are often filled with many insertions and customizations. Templating systems like Handlebars and Pug help to speed up writing these blocks of human readable text. There’s no need to write the low-level code required to glue together strings. You just write the text and the templating system handles the chore of patching together all the parts.

AWK

The Unix command-line tool is one of the simplest and most powerful tools for working with pure text. Named for its three original creators, Alfred V. Aho, Peter J. Weinberger, and Brian W. Kernighan, AWK links together a number of commands for extracting data from lines and sorting and filtering it. It is possible to build full reports using AWK. Programmers also use it to clean up raw data in the processing pipeline before the main program imports it.

Vapour

R is a powerful language that was largely created by statisticians, who generally think like mathematicians not computer programmers. That’s not a bad thing, but it can be a hurdle for using all the great libraries in R, which lack some of the great advances in programming design. Vapour is a preprocessor that lets R users think like programmers, specifically, programmers who love using type systems to catch bugs and enforce structure. Vapour’s developers say it’s still in an early alpha stage, so they may be adding new features and tweaking the syntax. The goal is to let the tool evolve quickly with the needs of users.

Spiffing

Not all English speakers use the language in the same way, particularly across continents and cultures. Spiffing (also see Spiffing) is a preprocessor that translates code written in American English to British English. It’s a bit of a goof, but that doesn’t mean it’s not useful or capable of bridging a cultural divide. If it catches on, maybe one day, developers will build out the preprocessor so that it converts the rather direct American-style diction into a more reserved British style. Instead of if-then statements, we could have perchance-otherwise syntax, for example.

Linting preprocessors

Not all preprocessors convert code. Some clean up after us and look for the bugs we’ve missed. The original Unix command-line tool, lint, has metastasized and now its functions are found as preprocessors in many language development stacks. These linting tools, or linters, fix formatting, enforce naming conventions, and even fix some syntactic and semantic errors. Some enforce rules that flag potential security flaws from bad logic. Popular versions include RuboCop for Ruby code, Pylint for Python, and ESLint for JavaScript (ECMAScript).

Preprocessors for documentation

Some preprocessors produce something other than runnable code. Tools like Sphinx, MkDocs, and Doxygen analyze your files and create an annotated and cross-referenced set of documentation files directly from code. These tools are designed to work with multiple languages but almost all the languages have their own official preprocessor. Popular examples include Javadoc, Rustdoc, Godoc, and JSDoc.

Preprocessors for integrated data reporting

Data scientists don’t just speak R language. They also write out complex data reports in a human language filled with charts, tables, and graphs created by R. Over the years, data scientists have created complex preprocessors for not only R but also LaTeX, the typesetting language. The scientist writes everything in R and human language, then the preprocessor splits it up, sending the computational instructions to R and the typesetting instructions to LaTeX. At the same time, it juggles the parts so the pictures produced by R end up in the right place in your document. LaTeX then folds them into the eventual PDF that’s produced from the human language parts of the file. It does all this while also organizing page references and illustration numbers to be consistent.

There are a variety of options with different strengths and advantages. R Markdown is a variation of common markdown that can also merge computational and data analysis. It can also merge in results from languages like Python or SQL to produce slides, documents, books, and websites. Knitr and its precursor Sweave are two closely aligned preprocessors that are both well-supported by Rstudio. For those who want to merge Python with LaTeX, there’s also Pweave. One day there may be a meta version that merges all of them into one big preprocessor.

Using AI for preprocessing

All preprocessors require some configuration. Why not just get an AI to do it? Some are already uploading their preprocessor to an LLM (large language model) and asking it to fix everything that’s wrong. In one example, some bean counters hit the roof after the developers told them that it would cost more than $1 million to rewrite their Agda compiler to make it current. Someone had the bright idea to just upload all 500+ files from their codebase to Anthropic’s Sonnet-3.5. And Voilà! The compiler was converted to TypeScript in the blink of an eye. The developers reported that most of the code ran fine with no intervention. The LLMs aren’t perfect, but they’re bringing us closer to a world where we can just wave our hands around and the machines do our bidding, like magic.

In the last decade, every web application developer has become an API designer. But most organizations do not think of developers as API designers, nor do they think about APIs as a product of design — to the detriment of their developers’ productivity. With the rise of AI, there are more APIs than ever before, making this problem even worse.

In this article, I’ll talk about the often-neglected internal APIs that, more and more, accidentally power businesses and how organizations can get back on top of these APIs.

The (internal) APIs that accidentally power businesses

The APIs that often get attention are the APIs that organizations have intentionally built their businesses on. These are APIs like the Stripe API, the Twilio API, and the Instagram API — APIs that are crucial to companies’ product and go-to-market strategies. These APIs start with well-reviewed designs and go through many iterations of polish, curation, and documentation before they reach their consumer, the public.

Then there are the APIs that organizations have accidentally built their businesses on:

• Front-end and back-end APIs. The rise of RESTful API design since the early 2000s means that web application front ends primarily talk to back ends via APIs.
• Cross-service APIs. The rise of service-oriented architectures since the early 2000s means that software organizations are structured such that each team owns a set of services. These teams operate in an increasingly decentralized way, with individual teams designing their own APIs, rather than a small number of architects designing all APIs in a top-down way.

There are often more of these kinds of APIs than external-facing APIs. These internal APIs are often designed and owned entirely by developers.

Why design matters for internal APIs

Okay, you might wonder. What does it matter that developers are designing APIs that external users have never seen? Product managers and business owners never dug into the code, so do they really need to dig into internal APIs?

The issue at hand is that developer-driven design decisions affect both the ability to deliver a good user experience and the velocity of development (and thus the nimbleness of the business). And there is a tension between these two concerns.

From the perspective of an API user, the ideal API design has the most general possible functions. For instance, if you’re using a bank API, you ideally want there to be only one function for getting the balance for a user, one function for changing the balance, etc. If there are dozens of functions to call to get a bank balance, it becomes much easier to call the wrong one!

From the perspective of a developer, however, the easiest API to build for is the most specific. This is because the more specific a function is, the more a developer can optimize. For instance, the way to build the fastest possible banking app is to have the app back end send exactly the right information the app front end needs and no more. Internal APIs bias towards performance, meaning they are designed by the developer for ease of optimization, rather than for ease of consumption.

In the absence of other forces, developers will bias towards delivering a good immediate user experience rather than towards longer-term development velocity, or even reuse of an API for platform purposes.

Harness the power of developer-driven design

There are two ways to look at the world of APIs we now live in. If we look at this world from the lens of top-down API design, we can bemoan the chaos and API sprawl that has befallen us and continue trying to get in control in a spec-first way.

But there’s a more empowering alternative, one where we accept the developer-driven nature of API design and embrace collaboration. API design does not have to be fully top-down, architect-driven, or bottom-up developer-determined. What if API design were, instead, a collaboration?

Here is one model of what collaborative API design looks like in a developer-first model:

• An API developer designs an internal API for a specific purpose, getting feedback from the immediate consumer and fellow API developer. These designs are not just static documentation but may be enhanced with richer information from tests or mocks.
• As the API gets more usage, the developer gets more feedback and updates the API.
• Previous versions of the API get stored and documented; the reasons for updating the API are clear to everyone.
• The API evolves in tandem with a “living design,” allowing developers to keep the API implementation optimized to the current use cases, allowing consumers to smoothly use the API for their needs, and allowing consumers and collaborators to give feedback as their needs change.
• Bonus: The living design gets updated automatically as the implementation updates, using real app behavior as the source of truth.

By making all software development API development, you unlock an immense amount of productivity — but only if it is as easy to share API designs as it is to share code and documents.

It is incredible how much faster software organizations can move when they empower developers to build APIs in a decentralized way. Fast, decentralized development does not require sacrificing organization or coordination. The key is productive collaboration.

Jean Yang is head of product at Postman.

—

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.

Fermyon has released Spin 3.0, a major update to its open source developer tool for building serverless WebAssembly applications. The new release introduces polyglot programming to ease development.

The update to Fermyon’s Spin framework was introduced November 11. Installation instructions can be found on developer.fermyon.com.

Spin 3.0 introduces a workflow for polyglot programming that leverages component dependencies. This functionality is intended to make it seamless to perform tasks such as writing a library for a compute-intensive task in Rust and using it as a dependency in a JavaScript application. Component dependencies can be stored, discovered, and fetched from OCI registries, giving developers an experience akin to npm, NuGet, or crates.io but for Wasm, Fermyon said.

Spin 3.0 also includes an experimental flag, spin up --component-id, that lets developers specify which components to run from a Spin application, and it features deeper integration with WASI (WebAssembly System Interface) standards Spin 3.0, bringing support for the WASI Key-Value and WASI Config APIs. This support is a step toward bringing into Spin WASI cloud core, a WASI proposal for standardizing a set of APIs that applications can use to interact with a common set of cloud services.

Spin 3.0 also introduces support for OpenTelemetry (OTel) observability in Spin applications, enabling Spin application observability with popular tools such as Grafana, Jaegar, and Prometheus.

Finally, the release also features a major refactor of Spin internals with a feature called Spin Factors, where a “factor” encapsulates a host functionality feature. Spin Factors allow the Spin runtime to be more modular, Fermyon said.

Spin is positioned as a framework for building and running fast, secure, and composable cloud-based microservices with WebAssembly. Spin 3.0 follows Spin 2.0, introduced a year ago and focused on the developer experience and runtime performance. Spin 1.0 arrived in March 2022.

“Nobody cares if you contribute.” That’s what a Postgres friend said to me during lunch at KubeCon when I suggested that hiring Postgres contributors could be a selling point for customers. His comment surprised me because for years I’ve believed the open source dogma that contributions somehow qualified developers and vendors to disproportionately profit from projects. This, despite the overwhelming evidence to the contrary.

For example, no one has benefited more from open source than AWS but, relatively speaking, no one has contributed less. AWS has started to change, which I’ve celebrated. But after talking to my friend, I now wonder whether it matters at all. It may make employees feel better that their employer “gives back,” but it doesn’t seem to make the slightest difference to customers. Mostly. It’s worth talking about that “mostly.”

Make it easy

AWS has long billed itself as the best place to run open source software, and its customer success seems to support that statement. Open source has been central to AWS’ rise for nearly 20 years. Indeed, when I used to manage AWS’ open source strategy and marketing team, we ran a survey to uncover what customers cared about most in open source. Was it contributions or something else? Contributions made the list, but the number one determinant of open source “leadership,” according to developer respondents, was making it “easy to deploy my preferred open source software in the cloud.”

Enterprises, in other words, have a limited amount of time; they prefer vendors who remove the burden of managing their own open source software deployments, regardless of whether those same vendors are active contributors to the projects in question. This particular survey didn’t involve AWS customers and, indeed, I’m sure the results would be the same if you asked developers that use Microsoft Azure, Google Cloud, or any other cloud service. As much as you or I may think contributions to open source matter, customers just want to get stuff done as quickly as possible, for the lowest cost.

And yet there’s still an argument to be made for contributing to open source projects.

Contributions are part of the product

Back to my Postgres friend. Although he said customers may not care that so-and-so maintainer works for his company, having key contributors does enable his company to deliver excellent support to customers. In a community-run project such as Postgres or Linux, that doesn’t mean a particular employer gets to dictate road map, accelerate bug fixes, etc., but it does mean that they influence the road map. More importantly, it means they understand the code and the community around it and are thus better positioned to know how to weave short-term customer fixes into the main project without taking on technical debt. It also means, more simply, that they understand how to support a customer’s use of the code because they know that code intimately, in ways an interloping outsider simply doesn’t.

Additionally, though this happens rarely, should a company see a need to fork the project for long-term customer welfare, having core contributors and maintainers positions them to succeed with a fork. This is one reason AWS has a much greater chance of success with the Redis fork, Valkey. AWS has long employed one of Redis’ core maintainers, Madelyn Olson. Again, forks rarely happen, but contributing to an open source project is a solid insurance policy for a vendor’s customers. Is this something to market to customers? No. It’s behind-the-scenes work that ultimately creates a better product, but “we contribute” isn’t a product feature.

The Go programming language having just turned 15 years old on November 10, proponents now are planning to adapt the Go language to large multicore systems, the latest vector and matrix hardware instructions, and the needs of AI workloads.

In a blog post on November 11, Austin Clements of the Go team said that, looking forward, Go would be evolved to better leverage the capabilities of current and future hardware. “In order to ensure Go continues to support high-performance, large-scale production workloads for the next 15 years, we need to adapt to large multicores, advanced instruction sets, and the growing importance of locality in increasingly non-uniform memory hierarchies,” Clements said. The Go 1.24 release will have a new map implementation that is more efficient on modern CPUs, and the Go team is prototyping new garbage collection algorithms that are designed for modern hardware. Some improvements will be in the form of APIs and tools that allow Go developers to make better use of modern hardware.

For AI, efforts are under way to make Go and AI better for each other, by enhancing Go capabilities in AI infrastructure, applications, and developer assistance. The goal is to make Go a “great” language for building production AI systems. The dependability of Go as a language for cloud infrastructure has made it a choice for LLM (large language model) infrastructure, Clements said. “For AI applications, we will continue building out first-class support for Go in popular AI SDKs, including LangChainGo and Genkit,” he said. Go developers already view the language as a good choice for running AI workloads.

Also on the roadmap are efforts to ensure that the Go standard library remains safe by default and by design. “This includes ongoing efforts to incorporate built-in, native support for FIPS-certified cryptography, so that FIPS crypto will be just a flag flip away for applications that need it,” Clements said.

In noting the 15th anniversary of Go’s initial open source release, Clements said the user base of the language has tripled in the past five years. Go ranked seventh in the November 2024 Tiobe index of programming language popularity, its highest ranking in the index ever. The most recent version, Go 1.23, was released in August, with faster PGO (profile-guided optimization) build times and the rollout of Go telemetry data.

In the wake of Java Development Kit (JDK) 23, which arrived September 17, work now focuses on the planned successor release, JDK 24, which has ballooned to 21 proposed features. The two most recent additions proposals would improve Java’s resistance to quantum computing attacks, by providing Java implementations of a quantum-resistant module-latticed-based digital signature algorithm and a quantum-resistant module-latticed-based key encapsulation mechanism.

Previously proposed features include removing the 32-bit x86 port; synchronizing virtual threads without pinning; simple source files and instance main methods; permanently disabling the security manager; module import declarations; an experimental version of compact headers; primitive types in patterns, instanceof, and switch; linking runtime images without JMODs; the generational Shenandoah garbage collector; scoped values; a key derivation function API; removal of the non-generational mode in the Z Garbage Collector; stream gatherers; a vector API; a class-file API; warnings to prepare developers for future restrictions on the use of JNI (Java Native Interface); and a late barrier expansion for the G1 garbage collector.

JDK 24 outdoes JDK 23, which listed 12 official features.

Due March 18, 2025, JDK 24 has been designated a non-long-term support (LTS) release. Like JDK 23, JDK 24 will receive only six months of premier-level support from Oracle. Early access builds of JDK 24 can be found at jdk.java.net. 

The two features proposed for improving Java security through quantum-resistance include a quantum-resistant module-lattice-based key encapsulation mechanism (ML-KEM) and a quantum-resistant module-lattice-based digital signature algorithm (ML-DSA). ML-DSA would secure against future quantum computing attacks by using digital signatures to detect unauthorized modifications to data and to authenticate the identity of signatories. Key encapsulation mechanisms (KEMs) are used to secure symmetric keys over insecure communication channels using public key cryptography. Both features are designed to secure against future quantum computing attacks.

Flexible constructor bodies are in a third preview after being featured in JDK 22 and JDK 23, albeit with a different name in JDK 22, when the feature was called statements before super(…).  The feature is intended to reimagine the role of constructors in the process of object initialization, letting developers more naturally place logic that they currently must factor into auxiliary static methods, auxiliary intermediate constructors, or constructor arguments.

Ahead-of-time class loading and linking aims at improving startup times by making classes of an application instantly available in a loaded and linked state, when the HotSpot Java virtual machine starts. This would be achieved by monitoring the application during one run and storing the loaded and linked forms of all classes in a cache for use in subsequent runs.

The Windows 32-bit x86 port was deprecated for removal in JDK 21 with the intent to remove it in a future release. Plans call for removing the source code and build support for the Windows 32-bit x86 port. Goals include removing all code paths that apply only to Windows 32-bit x86, ceasing all testing and development efforts targeting the Windows 32-bit x86 platform, and simplifying the JDK’s build and test infrastructure. The proposal states that Windows 10, the last Windows operating system to support 32-bit operation, will reach its end of life in October 2025.

Synchronizing virtual threads without pinning involves improving the scalability of Java code that uses synchronized methods and statements by arranging for virtual threads that block in such constructs to release their underlying platform for use by other threads. This would eliminate almost all cases of virtual threads being pinned to platform threads, which severely restricts the number of virtual threads available to handle an application workload.

A fourth preview of simple source files and instance main methods would evolve the Java language so beginners can write their first programs without needing to understand language features designed for large programs. The feature was previously previewed in JDK 21, JDK 22, and JDK 23. The goal is to allow beginning Java programmers to write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow.

Permanently disabling the security manager involves revising the Java platform specification so developers cannot enable the security manager, while other platform classes do not refer to it. The security manager has not been the primary means of securing client-side Java code for many years, has rarely been used to secure server-side code, and has been costly to maintain, the proposal states. The security manager was deprecated for removal in Java 17.

Module import declarations, previously previewed in JDK 23, enhance the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries but does not require the importing of code to be a module itself.

Compact object headers would reduce the size of object headers in the HotSpot VM from between 96 and 128 bits down to 64 bits on 64-bit architectures. The goal of the proposed feature is to reduce heap size, improve deployment density, and increase data locality.

A second preview of primitive types in patterns, instanceof, and switch in JDK 24 would enhance pattern matching by allowing primitive types in all patterns and contexts. The feature also would extend instanceof and switch to work with all primitive types. The feature\’s goals include enabling uniform data exploration by allowing type patterns for all types, whether primitive or reference; aligning types with instanceof and aligning instanceof with safe casting; and allowing pattern matching to use primitive types in both nested and top-level pattern contexts. This feature was previously previewed in JDK 23.

Other goals include providing easy-to-use constructs that eliminate the risk of losing information due to unsafe casts, following the enhancements to switch in Java 5 and Java 7, and allowing switch to process values of any primitive type.

With linking runtime images without JMODs, the plan is to reduce the size of the JDK by roughly 25% by enabling the jlink tool to create custom runtime images without JDK JMOD files. This feature must be enabled by default and some JDK vendors may choose not to enable it. Goals include allowing users to link a runtime image from modules regardless of whether those modules are standalone JMOD files, modular JAR files, or part of a runtime image linked previously. Motivating this proposal is the notion that the installed size of the JDK on the file system is important in cloud environments, where container images that include an installed JDK are automatically and frequently copied over the network from container registries. Reducing the size of the JDK would improve the efficiency of these operations.

Generational Shenandoah would enhance the garbage collector with experimental generational collection capabilities to improve sustainable throughput, load-spike resistance, and memory utilization. The main goal is to provide an experimental generational mode, without breaking non-generational Shenandoah. The generational mode is intended to become the default mode in a future release.

Scoped values enable a method to share immutable data both with its callees within a thread and with child threads. Scoped values are easier to reason about than local-thread variables. They also have lower space and time costs, particularly when used together with virtual threads and structured concurrency. The scoped values API was proposed for incubation in JDK 20, proposed for preview in JDK 21, and improved and refined for JDK 22 and JDK 23. Scoped values will be previewed in JDK 24.

With the key derivation function (KDF) API, an API would be introduced for key derivation functions, which are cryptographic algorithms for deriving additional keys from a secret key and other data. A goal of this proposal is allowing security providers to implement KDF algorithms in either Java code or native code. Another goal is enabling applications to use KDF algorithms such as the HMAC (hash message authentication code)-based extract-and-expand key derivation function (RFC 5869) and Argon2 (RFC 9106).

Removing the non-generational mode of the Z Garbage Collector (ZGC) is a proposal aimed at reducing the maintenance cost of supporting two different modes. Maintaining non-generational ZGC slows the development of new features, and generational ZGC should be a better solution for most use cases than non-generational ZGC, the proposal states. The latter eventually should be replaced with the former to reduce long-term maintenance costs. The plan calls for removing the non-generational mode by obsoleting the ZGenerational option and removing the non-generational ZGC code and its tests. The non-generational mode will expire in a future release, at which point it will not be recognized by the HotSpot JVM, which will refuse to start.

Stream gatherers would enhance the stream API to support custom intermediate operations. Stream gatherers allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations. This feature was proposed as a preview in JDK 22 and JDK 23. The API would be finalized in JDK 24. Goals include making stream pipelines more flexible and expressive and allowing custom intermediate operations to manipulate streams of infinite size.

The vector API is designed to express vector communications that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations. The vector API previously was incubated in JDK 16 through JDK 23. It would be re-incubated in JDK 24 with no API changes and no substantial implementations relative to JDK 23. Goals of the proposal include clearly and concisely expressing a wide range of vector computations in an API that is platform-agnostic, that offers reliable runtime compilation and performance on x64 and AArch54 architectures, that degrades gracefully and still functions when a vector computation cannot be expressed at runtime, and that aligns with Project Valhalla, leveraging enhancements to the Java object model.

The class-file API, previously previewed in JDK 22 and JDK 23, would be finalized in JDK 24, with minor changes. This API provides a standard API for parsing, generating, and transforming Java class files. It aims to provide an API for processing class files that tracks the class file format defined by the Java Virtual Machine specification. A second goal is to enable JDK components to migrate to the standard API, and eventually remove the JDK’s internal copy of the third-party ASM library. Changes since the second preview include a renaming of enum values, removal of some fields, the addition of methods and method overloads, methods renamed, and removal of interfaces and methods deemed unnecessary.

Late barrier expansion for the G1 garbage collector is intended to simplify the implementation of G1’s barriers. The G1 garbage collector’s barriers record information about application memory accesses, by shifting their expansion from early in the C2 compilation pipeline to later. Goals include reducing the execution time of C2 compilation when using the G1 collector, making G1 barriers comprehensible to HotSpot developers who lack a deep understanding of C2, and guaranteeing that C2 preserves invariants about the relative ordering of memory accesses, safepoints, and barriers. A fourth feature is preserving the quality of C2-generated JIT (just-in-time)-compiled code, in terms of speed and size.

The first JDK 24-targeted feature, officially called “Prepare to Restrict the Use of JNI,” calls for issuing warnings about uses of JNI and adjusting the foreign function and memory (FFM) API, featured in JDK 22, to issue warnings in a consistent manner. These warnings are intended to prepare for a future release that ensures integrity by default by uniformly restricting JNI and the FFM API. Goals of the plan include preserving JNI as a standard way to interoperate with native code, preparing the Java ecosystem for future releases that disallow interoperation with native code by default, and aligning the use of JNI and the FFM API so library maintainers can migrate from one to the other without requiring developers to change command-line options.

Additional features targeting JDK 24 will be determined during the next several weeks. Other potential Java 24 features include structured concurrency, which simplify concurrent programming, and string templates, a feature previewed in JDK 21 and JDK 22 but dropped from JDK 23.

The most recent LTS release, JDK 21, arrived in September 2023 and is due to get at least five years of Premier support from Oracle. The next LTS version, JDK 25, is due in September 2025. LTS releases have dominated Java adoption, which means adoption of JDK 23 and JDK 24 could be on the low end as users await JDK 25.

This half-month in Python and elsewhere: Take a peek at seven libraries for parallel processing in Python, tour Python’s most popular ORM libraries, and check out our Flask 3.0 tutorial. Also, place your bets for which contender remains standing when PyCharm, VS Code, and five other popular Python IDEs duke it out.

Top picks for Python readers on InfoWorld

The best Python libraries for parallel processing
Here are 7 frameworks you can use to spread an existing Python application and its workload across multiple cores, multiple machines, or both—and do it at scale!

Get started with Flask 3.0
Want to get started with the popular, powerful, and straightforward Flask 3.0 framework for Python? Take your first steps with this guide.

The best ORMs for data-powered Python apps
Never write raw SQL queries again! These 6 ORMs let you manage and query database objects like any other Python object.

Review: 7 Python IDEs compared
We put VS Code, PyCharm, Spyder, and four other popular Python IDEs in the ring. Which one do you think came out on top?

More good reads and Python updates elsewhere

Pyloid: A web-based GUI framework for Python
Want to create apps in the Electron or Tauri way, but with Python as your back end? Pyloid is your friend.

PEP 750—Template Strings
Check out the new Python draft proposal for a string templating system even more powerful than f-strings. Is it a valuable addition, or ultimately redundant?

Is async Django ready for prime time?
One company’s experience deploying Django in production with asynchronous code. What flaming hoops did they jump and was it worth it?

The Mill build tool needs Python support—and there’s a reward!
Up to $4,000 (US) awaits those who create Python support for this build-tool project, which already services Java, Scala, and Kotlin.

In my line of work, I often hear CIOs and CFOs say, “Cloud providers are bleeding us dry.” As ever-increasing cloud bills roll in, they’re demanding answers about what they’re paying for and why they’re paying so much.

Public cloud providers are eager to oppose this line of questioning. They point to the shared responsibility model. If cloud customers spend too much money, it’s usually because they created cost-ineffective deployments. It’s common knowledge that many enterprises “lifted and shifted” their way to the clouds with little thought about how inefficient those systems would be in the new infrastructure.

Think of it this way: If a customer puts rubber tires on a horse-and-buggy delivery cart so it can be operated on a modern highway, isn’t the cart owner responsible for its lack of speed and increased operating expenses, and not the highway department? Yes, but the situation is not completely one-sided, and the cloud providers are not blameless. Let’s look at what they are doing wrong.

Complex pricing models

Purposely or not, public cloud providers created intricate pricing structures that are nearly incomprehensible to anyone who does not spend each day creating cloud pricing structures to cover every possible use. As a result, enterprises often face unexpected expenses. Many of my clients frequently complain that they have no idea how to manage their cloud bills because they don’t know what they’re paying for.

The solution to this problem is straightforward. Until providers simplify their pricing models, enterprises should assign a specific employee to be the pricing structure expert. That person can engage with cloud advisors and use cost calculators and other tools to help illuminate the intricacies of pricing models. Another option is consulting services that specialize in cloud economics.

However, many enterprises are pushing back on the notion that they need to spend even more money to figure out how they spent too much in the first place. Cloud providers need to do a much better job of making their pricing easier to understand. If you provide pertinent facts and information to your clients, you empower them to make changes that will benefit everyone. For example, let’s say the highway department knows that a motorized delivery van is 8.5 times more efficient than a horse-drawn delivery cart. The horse’s owner now has solid facts; replacement will result in a fully realized ROI in 1.25 years. Getting the horse and buggy off the roads will also make road management and maintenance tasks easier for the highway department. Everyone wins.

Overprovisioning and underutilization

Cloud providers often encourage enterprises to overprovision resources “just in case.” Enterprises still pay for that unused capacity, so the misalignment dramatically elevates costs without adding business value. When I ask my clients why they provision so much more storage or computing resources beyond what their workload requires, the most common answer is, “My cloud provider told me to.” Again, there’s an easy answer. Enterprises should adopt regular monitoring strategies to align resource allocation with usage demands.

Better cost management tools

Many providers offer cost management tools, but they are too complex or insufficient for effective tracking. Some enterprises may try other third-party tools to manage costs, but most enterprises just keep paying whatever providers ask.

The answer for this one is not so easy. Enterprises need to adopt regular monitoring strategies to align resource allocation with usage demands. They can also mitigate unnecessary spending by implementing rightsizing tactics and deploying tools to track and optimize cloud use. Sadly the state of the tools and the knowledge to construct monitoring strategies is pretty lacking right now.

For enterprises, these tools are essential. Companies should fully utilize the available features in cost management dashboards to gain insight into their spending. Establishing spending alerts and conducting periodic reviews of cost reports can improve financial oversight and compliance with budgetary constraints.

Cloud providers also need to do better. Instead of pushing back on enterprises that are having issues, help them. Now there’s a new concept that could help both sides.

Automatic scaling without proper governance

One of the best features of public cloud computing is autoscaling so you’ll never run out of resources or suffer from bad performance due to insufficient resource provisioning. However, autoscaling often leads to colossal cloud bills because it often is triggered without good governance or purpose.

Here’s a simple solution, although most enterprises don’t understand it: Set clear guidelines and thresholds for scaling operations. This avoids the financial impact of unchecked scaling by continuously reviewing and adjusting policies to align with evolving business needs and budget capabilities. The parameters need to be paired with sound cost governance systems. However, the cloud providers’ systems are often insufficient, and other paths should be found.

Lack of transparency in service offerings

Unclear service offerings and related charges can lead to unpleasant billing surprises. Having a thorough understanding of the utilized services is essential. Organizations should prioritize regular training for IT teams to ensure they comprehensively understand the cost implications of various cloud services. Developing a full grasp of the service terms and conditions will further inform decisions. This is another area where, once again, the cloud providers need to improve transparency.

Addressing these cost pitfalls requires a strategic approach to cloud management, which many enterprises avoid, and most cloud providers do not promote. By implementing informed and proactive strategies to tackle complex pricing, optimize resource usage, improve cost management, control scaling, and improve service transparency, enterprises can significantly reduce wasteful spending and maximize the value of their public cloud investments.

A day of reckoning is on the horizon. Currently, most enterprises blindly pay these inflated bills, albeit with many complaints. Enterprises, you need to fix the problems you are responsible for fixing. Cloud providers, you need to become a true partner. Help your customers use your resources in the most business-efficient ways possible. In the long run, helping them will help you.

The Rust Foundation, which stewards development of the Rust language, has released a statement addressing challenges and opportunities for interoperability between Rust and C++, with the intent of making cross-language development more accessible and approachable.

Formally announced November 12, the foundation’s C++/Rust Interoperability Problem Statement aims to overcome the obstacles to Rust-C++ interoperability. While C interoperability has been a focus of Rust, various factors have inhibited a mature, standard, and automatic solution for developing software using C++ and Rust together, the document states. To overcome these obstacles, the initiative will pursue a top-down, problem-space approach to enable cooperation and consensus among stakeholders including the Rust project, Rust Foundation member organizations, and individuals and organizations using C++ or Rust. The core challenge is in developing a mature, standardized approach to C++ and Rust interoperability, despite Rust’s historical focus on C compatibility.

Material resources contributed to the initiative will be used to pursue three concurrent strategies:

1. Improve existing tools and address tactical issues within the Rust Project to reduce interoperability friction and risk, in the short term.
2. Build consensus around long-term goals requiring changes to Rust itself and develop the tactical approaches to begin pursuing them.
3. Engage with the C++ community and committee to improve the quality of interoperation for both languages, to help realize mutual goals of safety and performance.

C++ and Rust interoperability, according to the statement, is the ability to exchange data and execute code written in both languages. “Both C++ and Rust will play important roles in systems programming for the foreseeable future,” the statement reads. “With such a high degree of overlap in applicability, using both languages together is essential to pursuing safety and performance which is maintainable and scalable.” Empowering technologists to choose the language best suited to their situation and minimizing costs and risks of interoperation is the core goal of the initiative.

The C++ and Rust interoperability initiative was launched in February 2024 with a $1 million contribution from Google.

JetBrains IDEs, with new 2024.3 edition releases, now provide a logical code structure view alongside the familiar physical code structure view in the Structure tool window. The updated IDEs also streamline debugging for Kubernetes applications and provide cluster-wide Kubernetes log access with streaming and pattern matching.

JetBrains announced the 2024.3 releases on November  12. The updated versions of the IDEs will be available soon through JetBrains’ website and Toolbox App, the company said.

The JetBrains IDEs covered by the release include IntelliJ IDEA ( Java and Kotlin), PyCharm (Python), WebStorm (JavaScript and TypeScript), GoLand (Go), and RubyMine (Ruby). Also released was JetBrains AI Assistant 2024.3, which now allows users to choose between between Google Gemini, OpenAI, or local large language models for code chat. This update also brings advanced code completion for all major programming languages, JetBrains said.

Specific JetBrains 2024.3 updates include the following:

• IntelliJ IDEA lets developers work more efficiently with updates, offering capabilities such as better handling of aliases in the data flow engine for Java and Kotlin. Also featured is a code formatter to preserve blank lines for clearer code.
• JetBrains AI Assistant adds Google Gemini models including Gemini 1.5 Pro 002 and Flash 002 to the model lineup. Developers can choose between Gemini, OpenAI, or local models to tailor their AI chat experience.
• PyCharm brings AI to the editor. Users can type a natural language request in a new line in the editor and the IDE will respond with a suggestion. Code assistance is provided for Python, JavaScript, TypeScript, JSON, and YAML.
• WebStorm offers an enhanced framework component navigation and renaming, database tools, SQL support, and improved AI-driven code completion.
• GoLand has a set of features and inspections to streamline developer workflow. AI users can benefit from refined multi-line completion and inline prompts. The latest Go language features are supported.
• CLion, for C and C++, offers new capabilities for embedded development, such as debug servers and support for native ZephyrWest debugging, and an ability to attach the debugger to an unstarted process.
• Rider, for .NET and games development, brings support for the .NET 9 SDK including the latest C# 13 features.
• PhpStorm, for PHP, has new inspections and quick fixes to help developers upgrade to PHP 8.4. Parallel and mutation testing in the Pest testing framework is supported.
• RubyMine introduces Rails 8 support, including Kamal 2 code completion and code insight for Solid Queue and Solid Cache.
• ReSharper, a Visual Studio extension for .NET developers, offers support for the latest C# 13 features.

Aspect-oriented programming (AOP) decomposes an application’s source code into distinct aspects that isolate the core business logic from cross-cutting concerns. With AOP, cross-cutting concerns like logging and authentication become “aspects” that you program in one place and then apply in all of the places they’re needed. Thus AOP enhances modularity, makes your code more readable and maintainable, and helps you reduce coding errors. You can learn more about AOP from my previous article here.

We’ve examined how we can implement AOP in C# using PostSharp and Autofac. In this article, we’ll look at implementing AOP in C# using the DispatchProxy class. To work with the code examples provided in this article, you should have Visual Studio 2022 Preview installed in your system. If you don’t already have a copy, you can download Visual Studio 2022 Preview here.

Create a console application project in Visual Studio 2022 Preview

First off, let’s create a .NET Core 9 console application project in Visual Studio 2022 Preview. Assuming you have Visual Studio 2022 Preview installed, follow the steps outlined below to create a new .NET Core 9 console application project.

1. Launch the Visual Studio IDE.
2. Click on “Create new project.”
3. In the “Create new project” window, select “Console App (.NET Core)” 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.
6. Click Next.
7. In the “Additional information” window shown next, choose “.NET 9.0 (Preview)” as the framework version you would like to use.
8. Click Create.

We’ll use this .NET 9 console application project in the subsequent sections of this article.

The perils of cross-cutting concerns

Cross-cutting concerns are application concerns that span several modules or layers of an application. Typical examples include logging, authentication, caching, performance monitoring, and transaction management. These concerns add a degree of complexity to the application’s core business logic.

Aspect-oriented programming is a proven approach to addressing these challenges. By modularizing these concerns, AOP decreases code clutter and improves code readability and maintainability, thereby enabling your application’s source code to be flexible.

The DispatchProxy class in C#

The most commonly used technique for implementing aspect-oriented programming is to intercept method calls in AOP, using a dynamic proxy for code interception. The DispatchProxy class provides a way to create proxy objects in C# and intercept method calls. This feature helps implement aspects without polluting or complicating an application’s business logic with cross-cutting concerns.

Essentially, DispatchProxy is an abstract class pertaining to the System.Reflection namespace. It contains the declaration of only two methods, an abstract method named Create and a generic method named Invoke as shown below.

protected abstract object Invoke(MethodInfo targetMethod, object[] args);
public static T Create() where TProxy : DispatchProxy

Using the DispatchProxy class in C#

Consider the following code that contains an interface and a class that implements the interface.

interface IMyInterface
{
    void Display(string text);
}
class MyClass : IMyInterface
{
    public void Display(string text)
    {
        Console.WriteLine(text);
    }
}

Create another class named MyClassDispatchProxy that extends the DispatchProxy class and implements the IMyInterface interface. We’ll use this class to create proxy object shortly.

class MyClassDispatchProxy : DispatchProxy where T : class, IMyInterface
{
    private IMyInterface Target { get; set; }
    protected override object Invoke
    (MethodInfo targetMethod, object[] args)
    {
        return targetMethod.Invoke(Target, args);
    }
    public static T CreateProxy(T target)
    {
        var proxy = Create>() as MyClassDispatchProxy;
        proxy.Target = target;
        return proxy as T;
    }
}

You can use the following piece of code to invoke the Display method using the proxy instance.

IMyInterface decoratedObject = MyClassDispatchProxy.CreateProxy(new MyClass());
decoratedObject.Display("This is a text message for testing purposes only.");

When you call the CreateProxy method, it calls the Create method of the abstract base class to create a proxy object for you. When you call any method on the proxy instance called IMyInterface, the proxy will automatically call the Invoke() method.

Use DispatchProxy to add logging capabilities

Let us now update the MyClassDispatchProxy class to include logging capabilities and change its name to CustomLogger. To do this, create a new C# class named CustomLogger that extends the DispatchProxy class.

public class CustomLogger : DispatchProxy where T : class
{
    private readonly ILogger _logger;
    private T target;
    protected override object Invoke
    (MethodInfo targetMethod, object[] args)
    {
       throw new NotImplementedException();
    }
    public static T Create(T target)
    {
       throw new NotImplementedException();
    }
}

The CustomLogger class shown in the preceding code uses Serilog to log data in this example. The following code snippet shows how you can update the Invoke method we created in the MyClassDispatchProxy class earlier to incorporate logging capabilities.

protected override object Invoke
    (MethodInfo targetMethod, object[] args)
    {
        if(targetMethod == null)
            throw new ArgumentNullException(nameof(targetMethod));
        _logger.Information($"Entering method: {targetMethod.Name}...");
         var result = targetMethod.Invoke(target, args);
        _logger.Information($"Exiting method: {targetMethod.Name}...");
        return result;
    }

Note how the method calls are logged before and after invocation in the Invoke method. If the targetMethod instance is null, the Invoke method throws an exception. In the Create method, we create a new instance of the CustomLogger class and then set the target object based on which the proxy object will intercept method calls.

Complete source code for DispatchProxy logging example

The complete source code of the CustomLogger example is given below for your reference.

public class CustomLogger : DispatchProxy where T : class
{
    private readonly ILogger _logger;
    private T target;
    public CustomLogger()
    {
        _logger = new LoggerConfiguration()
        .WriteTo.Console()
        .CreateLogger();
    }
    protected override object Invoke
    (MethodInfo targetMethod, object[] args)
    {
        if(targetMethod == null)
            throw new ArgumentNullException(nameof(targetMethod));
        _logger.Information($"Entering method: {targetMethod.Name}...");
         var result = targetMethod.Invoke(target, args);
        _logger.Information($"Exiting method: {targetMethod.Name}...");
        return result;
    }
    public static T Create(T target)
    {
        var proxy = Create>() as CustomLogger;
        proxy.target = target;
        return proxy as T;
    }
}

Run the application

Finally, create an instance of type IMyInterface that you would want to create a proxy object for and pass it to the Create method of the CustomLogger class as shown in the code below.

var myObject = new MyClass();
var proxy = CustomLogger.Create(myObject);
proxy.Display("Test message");

When you run the above piece of code, you’ll be able to see the text messages displayed before and after the method invocation as shown in Figure 1.

DispatchProxy proxies interfaces, not classes

The DispatchProxy class in C# enables you to intercept method calls and modify method invocations at runtime by using reflection. It is an excellent choice in applications where interface-based programming is used. Moreover, because the DispatchProxy class is available as part of the .NET Core library, you do not need to use any third-party libraries to implement aspect-oriented programming.

However, remember that DispatchProxy works only with interfaces, i.e., it proxies interfaces, not classes. You should also be aware of the potential performance implications (and be prepared to address any performance challenges) that might creep in because of the dynamic nature of proxy creation when working with DispatchProxy.

Virtualization seemed to be one of those technologies that was done. With Hyper-V, VMware, and KVM all offering similar features and performance, all that was left to do was to support new chipset instructions and fix bugs. But slowly things began to change, as operating systems and platforms adopted virtual machines and containers as key building blocks.

Windows support for virtualization-based security was one key driver, with new paravisor-based features in Hyper-V’s Krypton binding platform and virtual machines together so that users didn’t know that they were using code running in a VM. Security has driven many other recent virtualization developments, with tools like OpenHCL providing a framework for a virtualization-based trusted execution environment.

Modern virtual machines for serverless computing

There’s another increasingly important place where VMs are important. In the cloud-native and serverless computing world, we need to be able to launch code fast to scale with demand and support scaling down to zero when necessary. This is how we run data centers economically, ensuring we don’t need to keep loads running in case a user needs them.

We need to be able to launch small elements of functionality in microseconds, fast enough that users don’t notice any latency. This requires a new form of virtualization, where the hypervisor provides the APIs that would traditionally have been hosted by a guest OS, providing a lightweight set of services that can be accessed through known interfaces.

Introducing Hyperlight: a small, fast VM manager

In 2023 Azure CTO Mark Russinovich mentioned some work being done within Azure on a virtual machine manager designed for use with WASI, the Web Assembly System Interface. Hyperlight would work by eliminating the requirement to have a guest OS in a virtual machine, instead simply exposing a virtual CPU and I/O to guest applications. The resulting minimalist approach was showing good results and allowed either statically linked binaries to boot and run.

Hyperlight is now a public project with a GitHub repository. It’s still very much experimental, but there’s enough to explore what you can do with your own minimal VMs, especially how you can write code for them. Microsoft suggests that Hyperlight is intended for functions as a service where event-driven applications need to scale quickly, but there are other possibilities: for example, microservices in a Kubernetes environment that’s managed using Kubernetes Event-Driven Autoscaling (KEDA), or portable code for edge IoT hardware.

It’s interesting to look at other recent Azure announcements, as many of them could work well with Hyperlight, especially where both latency and density are key. Running Hyperlight on Cobalt Arm hardware would allow Azure to take advantage of its new lower power compute, and it would also allow Drasi workloads to quickly respond to change notifications across many data sources.

Using Hyperlight for functions as a service

So how does Hyperlight work? To start with, all your code needs to run on the Hyperlight virtual CPU. That requires code to be compiled for it, with a set of specialized libraries to provide platform support that needs to be statically linked when compiled. This is currently available as C, though there are plans to also implement it in Rust. That approach makes using a Web Assembly runtime a good choice, as it allows you to build the runtime once and then use WASI to run arbitrary code written in a higher-level language and compiled to Web Assembly’s wasm instruction set. That should allow you to use any language that has a wasm compiler, including .NET languages such as C#.

Hyperlight provides the basic infrastructure for running a thinly provisioned VM. This sets up the necessary memory via the host OS hypervisor APIs, enabling the virtual CPU and its registers, before running a pre-configured app at a set instruction pointer. It’s an approach that’s optimized for running one process per VM, with the app and VM bundled together.

While that may seem like other virtual machine managers, it’s very much optimized for fast cold starts, going from nothing to a fully instantiated application in the minimum possible time. By launching functions quickly, Hyperlight allows Azure to scale its functions-as-a-service tool more effectively by shutting them down completely when not running, ensuring that when a function is active, it’s computing, not simply using power while waiting to be called.

Launching a Hyperlight-hosted VM takes a couple of milliseconds, as opposed to 120 or so for a traditional VM. It’s slower than launching a web assembly runtime on its own, but using a VM provides the added level of security and isolation that’s necessary for multitenant applications.

Developing for and with Hyperlight

Hyperlight is invoked programmatically. Microsoft’s sample code is written in Rust and it takes a handful of lines of code to create a Hyperlight sandbox and load code into it. One useful option is creating a snapshot of the VM once it’s been created, which can be used to launch future instances more quickly.

Once a VM is up and running, you can use the Hyperlight Rust libraries to call a VM-hosted function directly. Your host code needs to run in a loop until the VM function halts successfully or it fails with a known or unknown error. If the function succeeds, the host passes the result on to the calling function. If it fails, it logs the appropriate error message.

Using Rust here makes sense. It’s memory-safe, so it reduces the risk of memory leaks and buffer escapes, helping keep both host and guest code secure. This is essential in a cloud-native environment where function instances are created and destroyed and there is no link between any one instance and the next.

How can you build a guest binary for use in Hyperlight? You need to use the Hyperlight library, with both C and Rust versions available. It’s also important to remember that this is the only one you can use, so don’t start with the standard library, even if that’s what you’ve always worked with in the past. There are other important prerequisites, including a specific entry point for your code, to trap unregistered function calls from the host.

One key point is that there is no access to the host system from the guest application unless it’s explicitly enabled by the host. Even if you have enabled that option, guest applications are strictly limited in what can be delivered, locking down both argument length and type. If what’s sent is not what’s expected, the call will be rejected by the Hyperlight host.

Security is important when building a Hyperlight host. Microsoft has put out a list of requirements that help define the host’s role as a tool for managing guest code. These include ensuring that your host doesn’t do things like create or work with files, access network resources, or even work with encryption tools. When you consider that a host may be loading more than one different function for different owners, these rules begin to make sense. There is no need to expose state or services that can be accessed by malicious actors. And if you are running a public service, you can be sure that they will be trying to do just that.

Designing for cloud economics

It’s still early days for Hyperlight, but there’s a lot to like in what we’ve been shown so far. The idea of a lightweight host for functions is a good one, especially one with the ability to truly scale to zero. As it rolls out in Azure and other cloud platforms, it should have an interesting effect on the economics of cloud-native serverless development, both for users and the cloud providers.

Scaling to zero with minimal startup latency will ensure there are no costs associated with idle functions, and at the same time, will improve overall utilization in data centers. That should be a win for everyone. Now all we need is a Hyperlight Functions runtime, one that hides the plumbing underneath Web Assembly and lets us build code in our language of choice. And that’s what handing the project over to the Cloud Native Computing Foundation should do, encouraging developers to think about how to build using Hyperlight with Kubernetes and Web Assembly.