devopsy.kinsta.cloud

Tag: Wasm

Microsoft’s Hyperlight Wasm: Bringing WebAssembly to Secure Micro-VMs
Microsoft has taken another significant step in advancing secure virtualization technology with the release of Hyperlight Wasm, expanding the capabilities of its embedded VMM (Virtual Machine Monitor) project announced last year. This new open-source offering bridges the gap between WebAssembly and micro-VM security, creating exciting possibilities for developers across platforms.

Expanding the Hyperlight Ecosystem

The original Hyperlight project emerged as an innovative solution for VM-based security, specifically designed for small embedded functions within Windows and Linux applications. It offered a lightweight approach to virtualization that could be integrated directly into applications, providing isolation without the overhead of traditional VMs.

Microsoft has significantly broadened the scope of this technology with Hyperlight Wasm by incorporating WebAssembly (Wasm) support. This integration allows developers to run WebAssembly component workloads inside the secure boundaries of Hyperlight’s micro-VM environment.

Cross-Platform Compatibility

One of the most compelling aspects of Hyperlight Wasm is its broad platform support. The project works across:
- Windows (via the Windows Hypervisor Platform)
- Linux (via KVM)
- macOS (via /dev/mshv)
This cross-platform compatibility makes Hyperlight Wasm an attractive option for organizations with diverse computing environments, eliminating the need for platform-specific security solutions.

Technical Implementation

According to the official GitHub repository, Hyperlight Wasm is designed as “a component that enables Wasm Modules to be run inside a lightweight Virtual Machine backed Sandbox.” The primary goal is to allow applications to execute untrusted or third-party WebAssembly code safely within a VM with minimal latency and overhead.

Written primarily in Rust, Hyperlight Wasm inherits both the language’s memory safety guarantees and the security features of the underlying Hyperlight architecture. This combination creates a compelling security story for applications that need to run potentially untrusted code.

Why This Matters

The marriage of WebAssembly and micro-VM technology addresses several critical challenges in modern application development:
1. Security: By running WebAssembly components in isolated VMs, applications can execute untrusted code with significantly reduced risk.
2. Performance: The “low latency/overhead” design ensures that security doesn’t compromise application responsiveness.
3. Language Flexibility: Since WebAssembly can be targeted by numerous programming languages, developers aren’t restricted to a single language ecosystem.
4. Cross-Platform: The solution works consistently across major operating systems, simplifying deployment in heterogeneous environments.
Looking Forward

Microsoft’s continued investment in open-source virtualization technology signals a broader industry trend toward more granular, purpose-specific security controls. Rather than relying solely on perimeter security, organizations can now implement security boundaries at the function level, creating defense-in-depth architectures more resilient to compromise.

According to Mitch Ashley, VP and Practice Lead, DevOps and Application Development at The Futurum Group, “Easing the integration of Wasm runtime into Hyperlights’ micro-VM brings the added security of Hyperlight being built in Rust. The question is whether Hyperlight Wasm brings more complexity or added benefits to developers. We need to see whether Hyperlight Wasm strikes a chord with developers by saving them time and other benefits.”

As cloud-native applications continue incorporating more third-party and community code, tools like Hyperlight Wasm will likely become essential components in the security toolbox. They allow developers to benefit from the broader ecosystem without exposing their applications to unnecessary risk.

Developers interested in this technology can find the Hyperlight Wasm repository on GitHub and learn more through Microsoft’s Open-Source Blog.
March 28, 2025
Fiberplane Adds Open Source Libraries to Automatically Collect Metrics

Fiberplane today added an ability to automatically collect metrics in real-time and make them accessible either via its namesake notebook software for debugging infrastructure or an open source Grafana dashboard.

Fiberplane CEO Micha Hernandez van Leuffen said Autometrics is an open source set of libraries the company created to make it simpler for developers to see platform performance metrics using a set of tools embedded within their integrated development environment (IDE).

The goal is to reduce the cognitive load on developers; today, developers need to first determine what metrics to track, find a way to collect the appropriate data and then launch queries against those metrics to determine the root cause of an issue, said Hernandez van Leuffen.

Autometrics, in contrast, provides access to a set of common queries using the Prometheus programming language (PromQL) against data that has been collected using open source OpenTelemetry agent software, he noted.

That approach, for example, makes it simpler to track error rates, response time and latency of any function. Links to live charts based on real-time data can also be inserted into the comments section of any document a development team creates.

The Fiberplane notebook uses the same operational transformation algorithm embedded within Google Docs to enable teams to easily collaborate around a document or spreadsheet. The core platform itself is built in Rust and WebAssembly (Wasm) to make it simpler to integrate Fiberplane as a plug-in into an existing DevOps workflow.

Autometrics extends that capability in a way that enables DevOps teams to provide developers with instant access to observability data. They can then see how their code is performing on any given platform, which is critical as more responsibility for running applications continues to shift left, said Hernandez van Leuffen. Today, many developers need to wait for an IT operations team to share data collected via an observability platform that was designed to be used by ITOps rather than a developer, he added.

As observability capabilities become more federated across the entire software development life cycle, it’s critical to make sure developers and IT operations teams can see metrics being generated in real-time. Otherwise, confusion arises because teams are not looking at the same set of metrics.

Fiberplane address that issue by taking the concept of notebooks—often used by data science teams to collaborate—and applying it to DevOps workflows to reduce the amount of time it takes to resolve any issue. As IT environments become more distributed in the age of the cloud and microservices, troubleshooting issues invariably spans the responsibilities of multiple members of an IT team. In effect, a notebook makes it possible to spin up a virtual war room on demand that enables the members of an IT organization to collaborate—regardless of where they are physically located or which organization they may be employed by.

April 13, 2023
Dylibso Releases Tool for Tracking and Validating Wasm Modules

Dylibso today made generally available a system of record for tracking, investigating, searching and validating modules built using the WebAssembly (Wasm) binary instruction format.

Fresh from raising $6.6 million in additional funding, Dylibso CEO Steve Manuel said Modsurfer exposes the internal contents to enable developers to debug Wasm modules and ensure compatibility with runtime environments.

Modsurfer provides development teams with a console for accessing a fully auditable database of modules indexed for search and debugging. In addition, development teams have the ability to extract critical information from binary formats in a way that can be integrated with DevOps pipelines. In effect, Modsurfer provides application development teams with X-ray vision into previously opaque Wasm modules, said Manuel.

Dylibso previously developed Extism, an open source universal plug-in system that supports multiple programming languages used to build Wasm modules. That reduces the level of effort required to integrate Wasm modules and provided the foundation upon which Modsurfer was created, noted Manuel.

Wasm, at its core, is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. The World Wide Web Consortium (W3C) drove the development of Wasm as part of an effort to create a common format for browsers executing JavaScript code. Wasm is now being extended beyond browsers and JavaScript to enable developers to create a set of universal binaries that could work on any platform without modification.

That approach replaces the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct boundaries between them. One of the issues of that approach is that it becomes relatively simple for malware to infect all the components of an application.

It may be some time before WASM becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are finally starting to crumble. Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. That’s not only critical in terms of overall application developer productivity; it also has major implications in terms of streamlining the management of DevOps workflows as it becomes easier to both initially deploy applications and continuously update them.

As organizations continue to review their application development practices to better secure software supply chains, it’s also become apparent that legacy approaches to building applications are fundamentally flawed. Rather than attempting to reengineer processes to encourage developers to better secure applications, it may be more effective to change the way applications are built. After all, considering all the processes required to secure legacy development approaches, it may be cheaper and easier to adopt a new method for building applications that lowers overall risk, said Manuel.

Of course, the amount of Wasm expertise that exists in the developer community is still limited. However, DevOps teams should expect to see more Wasm modules moving through DevOps pipelines as Wasm tooling continues to improve.

March 23, 2023
Fiberplane Adds Wasm Plug-in Framework for DevOps Notebook

Fiberplane today announced it is extending the reach of a real-time collaboration notebook designed for DevOps teams by making available tools for building plug-ins based on the WebAssembly (Wasm) framework.

Micha Hernandez van Leuffen, Fiberplane CEO, said these plug-ins, dubbed providers, will make it much simpler for anyone to connect the Fiberplane notebook to other DevOps tools and platforms.

The Fiberplane notebook uses the same operational transformation algorithm used in Google Docs to enable teams to easily collaborate around a document or spreadsheet. The core platform itself is built in Rust and WebAssembly. That approach enables a DevOps team to, for example, write and run PromQL queries and display Prometheus charts alongside other data presented via an integrated graph. Wasm makes it possible to run those providers both in the browser and on a backend platform.

Fiberplane also announced it is open sourcing its Provider Development Kit (PDK), written in Rust, to enable organizations or third-party developers to create additional plug-ins. A Fiberplane Daemon then executes the plug-ins. The overall goal is to provide an open format based on Wasm for consuming DevOps data, noted Hernandez van Leuffen.

The full open source Fiberplane WebAssembly-based Plugin System includes a Fp-bindgen to provide the bindings generator for building plug-ins, the Provider Development Kit (PDK), a toolchain for building plug-ins, a set of pre-configured plug-ins for Prometheus, ElasticSearch, Sentry, Grafana Loki, Cloudwatch and a generic HTTP provider, the Fiberplane command line interface and the Fiberplane Daemon.

Fiberplane is essentially taking the concept of notebooks used for collaboration by data science teams and applying it to DevOps workflows. The goal is to improve DevOps teams’ productivity by reducing the amount of time it takes to sort through multiple types and classes of DevOps data to resolve an issue.

As IT environments become more distributed in the age of the cloud and microservices, troubleshooting issues now invariably spans the responsibilities of multiple members of an IT team. Fiberplane, in effect, makes it possible to spin up a virtual war room that enables the members of an IT organization to collaborate until the issue of the moment is resolved.

The speed at which any IT issue is resolved has become a crucial metric. Given the complexity of IT environments, it’s inevitable that incidents will arise. Ideally, IT teams would discover those issues before they disrupt the business. However, in reality, the metrics organizations use to evaluate the effectiveness of a DevOps team are often how quickly IT issues are resolved once they are discovered. The longer it takes for a distributed DevOps team to marshal its resources, the more likely it becomes that team will be perceived as being inefficient—regardless of what level of application availability is actually achieved.

Most DevOps teams have, of course, implemented a wide range of incident management best practices that create a level of muscle memory for responding to a wide range of issues. The trouble is there will always be unforeseen issues that arise. DevOps teams, as a result, need to find ways to quickly focus on an unpredictable issue that they didn’t anticipate.

February 15, 2023
Best of 2022: We Must Kill ‘Dinosaur’ JavaScript | Microsoft Open Sources 3D Emoji

As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: JavaScript is a bloated barrier to progress, and Microsoft’s emoji are on GitHub. (more…)

December 30, 2022
DevOps 2022: The Year That Was and Wasn’t
We will be wrapping up our DevOps coverage for the year by the end of this week. It’s hard to believe that another year has gone by. The gravitational lensing of COVID-19 makes it hard to see the progression of the last nine years here at devopsy.kinsta.cloud. Things seem to get a bit hazy looking back. However, 2022 was certainly one for the record books in ways both good and bad. 2022 saw DevOps, our community our countries and our world pushed and pulled in directions we would not have imagined just a few short years ago. To understand what happened in DevOps in 2022, we need to account for several macro factors that played outsized roles this year. They are:
1. COVID-19: It’s still here; still killing hundreds of people every day. While some in the U.S. and Western Europe have “moved beyond” it, COVID-19 is still draining our resources, sucking the air out of the room and impacting not just the economy but how we interact with each other individually. In the next few months, I am afraid we will see the 1.4 billion people of China experience a backlash as they move away from zero-COVID policies. Not to mention the other viruses and diseases that are circulating.
2. War: When I was a young boy, I remember a popular poster/sticker that said something like, “War is not healthy for children and other living things.” That’s still true; it’s not healthy for the economy, either (unless you sell ammunition). The human toll of the war in Ukraine is heartbreaking in the present moment, and the toll that this war will take on the once-healthy tech sectors in Ukraine, Russia and the rest of Eastern Europe also will be felt for a very long time.
3. Inflation: Again, I am transported back to my youth as inflation rears its ugly head and puts its foot on the throat of our economy. Sometimes I wonder if the Fed and other central banks won’t stop raising interest rates until the economy is good and dead, but their fear of inflation is almost genetic. While recent signs point to a potential peak, we still have a long way to go and the possibility of more interest rate hikes ahead of us. These will continue to make it harder to raise money and put a crimp in companies’ budgets. That means layoffs and budget cuts; projects cut or pushed out. We haven’t seen disruption like this in tech for more than 10 years. But for those of my vintage, we have seen cycles like this before. This too shall pass.
4. Hate: Is it me or has the whole world gone crazy with tribalism, nationalism, racism, antisemitism and a bunch of other “-isms”? We seem to be ripping ourselves apart from the inside out. I don’t have a clue how to combat this on a macro level, but I pray every day that things get better.
With these four horsemen of the apocalypse riding among us, you may think that I am not very bullish on DevOps now and in the future. But you’d be wrong. Like the little boy in a room full of horse manure, I remain very excited because I know there must be a pony around here somewhere.

DevOps has continued to evolve, continued to mature and has become an indispensable part of today’s modern software factories. Like their own version of Marvel’s Avengers or DC’s Justice League, DevOps, along with cloud-native, SRE, Agile, CI/CD, DevSecOps and dare I say it, platform engineering, are wielded by IT teams around the globe to continue to push forward as we digitally transform our businesses and the very fabric of our lives. That is what gets me up and out of bed every day and makes me excited to come to work.

While some marketers are busy running around printing stickers and shirts proclaiming that DevOps is dead, nothing could be further from the truth. Look around—as far as the eye can see, DevOps is everywhere. As we explored in our DevOps Experience virtual event in October (the sessions are still there for you to watch on demand), DevOps is everywhere. It is at the edge; it is in the “connected things”; it is inherent in technologies like WebAssembly (Wasm) and DevOps is distributed.

In 2023, I think DevOps at the edge, the DevOps of things and Wasm will be huge areas of growth. I realized that some of these folks claiming that DevOps is dead are trying to say platform engineers will replace DevOps engineers. But like Darth Vader trying to strike down Obi-Wan, all they are doing is making DevOps stronger than ever. You see, DevOps was never about DevOps engineers; it’s not about one role or one individual. In fact, some of my best friends helped kick off the DevOps movement and they’d react quite loudly when they heard the term DevOps engineers. DevOps is about building, maintaining and managing our software and applications. It’s a way of thinking about how we can go faster, be smarter and achieve better quality. It’s not about a particular tool you use or the role you play on the team, it’s about the fact that you have a team.

So, what does 2023 have in store for DevOps? More of the same, I think. DevOps, along with all of the associated frameworks and technologies, will continue to allow us to do more and do it faster and better. As I think about the coming year, I am very excited about the potential for ML and AI and I think they are going to have an outsized role in allowing us to be more successful. I think the novelty of these technologies has worn off and we will get to the productivity phase. I remember interviewing Luke Kanies years ago; he told me that one day software would write software. I asked him when he thought this might happen, and he said maybe 2035 or so. I think we are on track. Much like ChatGPT and Jasper’s impact on copywriting, AI won’t take the place of developers. But it will free them of some of the mundane, repetitive chores they do now.

I think we’ll also see an emphasis on feedback loops and iteration. I think automation, ML/AI will contribute to this in a big way. We have put so much of our DevOps emphasis on the development, integration and deployment of software. But observability allows us to see patterns and use cases as never before. We need to incorporate those findings into the next revision of our software. This is going to be a big story in 2023. That old infinity loop model for DevOps will rise to the top once again.

Thank you for all of the support for devopsy.kinsta.cloud this year and over the past few years. I hope this holiday season finds you and yours healthy and happy. Merry, merry. Happy, happy. See you in 2023.
December 20, 2022
CNCF Survey Predicts Growing Wasm Momentum

A survey of 93 developers conducted by the Cloud Native Computing Foundation (CNCF) found more than a quarter (28%) are using WebAssembly (Wasm) in their cloud-native development projects, with another 36% planning to do so during the next six to 12 months.

The survey, published this week, is effectively a straw poll that found 42% of respondents are developing or plan to develop server-side applications using Wasm, while 48% are combining or planning to combine server-side workloads with client-side applications.

Originally developed five years ago by the World Wide Web Consortium (W3C) to create a common format for browsers executing JavaScript code, Wasm is now starting to be used to rapidly build lighter-weight applications that can be deployed on any server platform. The promise of being able to write an application once and deploy it anywhere is finally being realized some 25 years after the initial introduction of the Java programming language.

The survey found 70% of respondents viewed Wasm runtimes as a disruptive emerging technology. The primary programming languages used in association with Wasm are Rust (59%), Go (47%) and JavaScript (46%), the survey found.

Nearly two-thirds (63%) said they are both porting new applications using Wasm and migrating existing workloads, compared to 37% who said they were creating new applications only. The primary reason cited for migrating workloads to Wasm was application portability (78%), better security (77%) and improved runtime performance (70%).

Security ranks high because existing approaches to building applications rely on the aggregation of software components that tend to lack distinct boundaries between them. As a result, it becomes relatively simple for malware to infect all the components of an application. Wasm code runs in a sandboxed environment that isolates execution environments in a way that eliminates the ability of malware to laterally move across an application environment.

Target platforms for Wasm applications include serverless computing frameworks (63%), edge platforms (54%) and the web (52%), the survey found.

The biggest barriers to adoption were tools (46%) and lack of standards (45%). Just over half (56%) of respondents said Wasm developer tools are missing features and are difficult to use. A full 81% said they would like to see vendors provide full-featured and stable Wasm tools and projects.

Matt Butcher, CEO of Fermyon, a provider of a platform for building Wasm applications, said that while survey respondents most likely represented more advanced developers, it’s clear Wasm momentum is starting to build. Much like JavaScript before it, Wasm is about to jump from the client to server-side application environments, he noted.

Less clear is whether Wasm represents the next era of cloud-native computing or is simply another type of software artifact that will be employed to build applications alongside other artifacts such as containers.

Wasm isn’t necessarily going to replace existing approaches for building applications any time soon, but it does provide an alternative to serverless computing frameworks for developing lighter-weight applications that run faster. Existing serverless computing frameworks typically use containers that are much slower to start up than Wasm code running natively on a platform, which accounts for why developers are looking to embrace the format to improve overall application performance.

One way or another, more Wasm code will soon be finding its way into DevOps pipelines. The issue is determining how to incorporate it alongside all the other code moving through those pipelines.

October 28, 2022
Fermyon Adds Managed PaaS for Building Wasm Applications

Fermyon Technologies this week launched a hosted platform-as-a-service (PaaS) environment, dubbed Fermyon Cloud, that promises to make it simpler to build WebAssembly (Wasm) applications.

Announced during the Cloud Native Wasm Day event during the KubeCon + CloudNativeCon North America conference, Fermyon Cloud is now available in open beta.

Fresh from raising $20 million in funding, Fermyon CEO Matt Butcher said IT teams can quickly build and deploy Wasm applications using a Fermyon Spin development tool and a Fermyon Platform the company launched earlier this year.

Fermyon Cloud adds an opinionated PaaS environment managed by Fermyon that can start up Spin applications in less than a millisecond. It uses a serverless application programming interface (API) that makes it possible to cache and optimize applications as they are loaded, noted Butcher.

Originally developed more than five years ago by the World Wide Web Consortium (W3C) to create a common format for browsers executing JavaScript code, Wasm is now used to rapidly build lighter-weight applications that can be deployed on any server platform. In effect, the promise of being able to write an application once and deploy it anywhere is finally being realized some 25 years after the initial introduction of the Java programming language.

Wasm isn’t necessarily going to replace existing approaches for building applications, at least not any time soon, but it does provide an alternative to serverless computing frameworks for developing lighter-weight applications that run faster.

In addition, at a time when organizations are becoming more concerned about application security, the appeal of Wasm is clear. Existing approaches to building applications rely on the aggregation of software components that tend to lack distinct boundaries between them. As a result, it becomes relatively simple for malware to infect all the components of an application. In contrast, Wasm code runs in a sandboxed environment that isolates execution environments to eliminate the ability of malware to laterally move across an application environment.

Wasm is especially well-suited for building lightweight applications that previously might have been deployed on a serverless computing framework, noted Butcher. The issue developers are encountering when using a serverless computing framework is that those frameworks are based on containers that have comparatively slow startup times, he added.

It remains to be seen how much traction Wasm gains in the months ahead, but Butcher said he expects most backend services, such as databases, will continue to be built using containers. Fermyon is betting, however, that many future cloud-native applications built by the average developer will be constructed using Wasm. In the longer term, Wasm will also soon be used to build applications infused with machine learning algorithms, said Butcher.

In the meantime, DevOps teams should get ready for more Wasm code to move through continuous integration/continuous delivery (CI/CD) pipelines. The challenge, of course, is that code will need to be managed alongside all the other software artifacts moving through those pipelines, as well.

October 27, 2022
Cosmonic Unveils PaaS for Building Wasm Applications

Cosmonic today at the KubeCon + CloudNativeCon North America conference unveiled a platform-as-a-service (PaaS) environment for building cloud-native applications using Web Assembly.

Based on the open source wasmCloud distributed computing environment now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF), the Cosmonic PaaS gives developers access to a lightweight environment that makes it simpler to quickly build applications that can run anywhere.

Cosmonic CEO Liam Randall said a PaaS enables developers to achieve that goal by making databases and other non-functional services available via an abstraction layer that eliminates the need for developers to provision these resources themselves.

Designed to be deployed on any cloud service or on-premises IT environment, the Cosmonic PaaS also enables developers to define their own laptops, cloud resources or entire data center by combing resources to create Constellations. Cosmonic also enables developers to build a Super Constellation by adding customer-hosted components to the services provided by Cosmonic.

Originally developed under the auspices of the World Wide Web Consortium (W3C) for building browser applications, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. The wasmCloud project was created by Cosmonic to provide an open source application runtime that hosts components, written as Wasm modules, that can then be loosely connected to build applications. Cosmonic reports there are now more than 100 members of the wasmCloud community.

The Cosmonic PaaS extends the capabilities provided by wasmCloud so developers can now more easily build Wasm applications via an abstraction layer defined by Cosmonic. Those applications are also more secure than applications built using previous software artifacts because all Wasm code is executed in a stateless and reactive sandbox that prevents malware from moving from one software component to another.

It may be some time before Wasm becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are about to crumble. Every earlier format for building applications locked developers into a specific platform. Wasm is the first software artifact that enables applications to run on any platform, including Linux and Windows, without any modification required.

Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. Just as importantly, those applications will run in a memory-safe sandbox that is more secure than what can be enabled in legacy IT platforms. In fact, as more organizations review the security of their software supply chains, they may decide to accelerate their embrace of Wasm to build more secure applications.

Obviously, Wasm has major implications for DevOps teams, and Randall said Cosmonic is working toward integrating its PaaS with multiple continuous integration/continuous delivery (CI/CD) platforms.

It’s not clear how quickly Wasm will drive a transition to another era of computing, but the ramifications for how IT is managed in the next era of cloud-native computing could be profound. It remains to be seen how quickly developers are willing to embrace yet another software artifact for building and deploying applications. What is clear is that there are an increasing number of platforms that will make it possible to more easily embrace Wasm.

October 24, 2022
Cosmonic Previews Deployment Platform for Distributed Wasm Apps

Cosmonic has made available a preview of a platform for deploying applications built using the portable WebAssembly (Wasm) binary format that enables applications to be deployed on any platform.

Cosmonic CEO Liam Randall said the company is providing early access to the Cosmonic Platform Developer Preview platform to enable developers to experiment with a new type of software artifact that will be used to build a new class of cloud-native applications.

The Cosmonic Platform Developer Preview platform is based on wasmCloud, an open source application runtime that hosts components written as Wasm modules that can then be loosely connected to build applications. Originally developed under the auspices of the World Wide Web Consortium for building browser applications, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment.

That approach replaces the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct boundaries. It’s that lack of distinct boundaries that enables malware to flow so easily from one software module to another. The wasmCloud runtime, originally developed by Cosmonic, provides a platform for deploying distributed Wasm applications and is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

Prior to Wasm, Randall noted, every format for building applications led to the creation of ‘walled gardens’ that resulted in developers being locked into a platform. Wasm is the first software artifact that enables applications to run on an platform, including Linux and Windows, without any modification required, said Randall.

It may be some time before Wasm becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are about to crumble. Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. Just as importantly, those applications will run in a memory-safe sandbox that is more secure than what can be enabled in legacy IT platforms. In fact, as more organizations review the security of their software supply chains, they may decide to accelerate their embrace of Wasm to build more secure applications.

Naturally, the transition to Wasm will have major implications for DevOps teams, as it represents an opportunity to streamline deployment processes across multiple platforms. In effect, the total cost of application development and deployment would decline as processes spanning multiple platforms become more automated using platforms such as wasmCloud. Ultimately, much of the infrastructure complexity that developers need to navigate today would be eliminated, noted Randall.

It’s not clear just yet to what degree Wasm will drive a transition to another era of computing, but the potential to change almost every aspect of IT is on the horizon. Ultimately, the issue will be decided by how quickly developers are willing to embrace yet another software artifact for building and deploying applications. What is clear is that the number of platforms that will make it possible to experiment with Wasm are starting to multiply.

October 3, 2022