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: The OpenSSL project has egg on its face, and half of Twitter’s staff are for the chop tomorrow. (more…)

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: The OpenSSL project has egg on its face, and half of Twitter’s staff are for the chop tomorrow. (more…)

Momento this week emerged from stealth to launch an elastic Serverless Cache platform that promises to improve the performance of applications running on databases deployed in the cloud while simultaneously reducing costs.
Fresh from raising $15 million in seed funding, Momento CEO and co-founder Khawaja Shams said Serverless Cache gives IT teams access to a serverless computing framework for accessing cache memory that can be used to improve the interactivity of applications.
Cache is, of course, already widely employed to improve the performance of applications running on databases in the cloud. However, organizations today are required to provision excess cache memory to address performance workload peaks. That approach, over time, conspires to increase the total cost of cloud computing, he noted.
A serverless cache makes it possible to more easily share an elastic pool of memory that can be invoked in seconds via an application programming interface (API) that is itself invoked by adding five lines of code to an application. The Momento cache service can then handle millions of transactions per second that can be spread across multiple applications, said Shams.
The Momento Serverless Cache service also automatically manages hot-keys, maintains high cache hit rates and keeps tail latencies low.

Organizations that are already using Momento on either the Amazon Web Services (AWS) or Google Cloud Platform (GCP) include CBS, NTT Docomo and Wyze Labs, Shams said.
In general, there’s a lot more scrutiny of cloud costs in the wake of the economic downturn, noted Shams. More IT teams are starting to take note of the fact that various cloud-native platforms enable them to more efficiently consume cloud resources, he added.
The simple truth is that far too many organizations are managing cloud resources in much the same way they managed on-premises IT environments. Capacity is being dedicated to virtual machines to ensure application availability with even less regard for cost because the perception is that the cloud makes it easy to throw hardware resources at any issue. The challenge is the bill for those cloud resources tends to add up at the end of every month. Cloud database services, in fact, are among the most expensive to consume, noted Shams.
It’s not clear how much organizations will optimize the consumption of cloud resources in the weeks and months ahead, but it’s clear more supervision is going to be required. Organizations have historically let developers provision resources in the name of agility with little to no regard for cost. Now that finance teams are looking to, at the very least, make sure cloud resources are optimally consumed, there will undoubtedly be more reviews of cloud spending patterns.
In the meantime, many organizations may also decide to accelerate the rate at which they are embracing cloud-native technologies to optimize that spending. One of the more compelling attributes of Kubernetes clusters and serverless computing is they make it easier to scale compute resources up and down as required to eliminate the need to overprovision cloud infrastructure. The challenge, of course, is that the cost of acquiring and mastering those technologies remains significant.

Gitpod today revealed it will add an application programming interface (API) to make cloud development environments (CDEs) more extensible. Gitpod also said Johannes Landgraf assumed the role of single CEO for Gitpod, as the previous co-CEO, Sven Efftinge, becomes the company’s first technical fellow.
Fresh from raising an additional $25 million in funding, Gitpod’s Landgraf said that API will make it easier to build plug-ins for CDEs. In time, Landgraf said, CDEs will become as accessible as any development environment running on a local desktop.
Software engineers typically waste five hours a week maintaining application environments, noted Landgraf. Via an open source development platform, Gitpod automates the provisioning of secure workspaces in the cloud that provide the added benefit of making it easier for multiple developers to collaborate, he added.
Capabilities added to the GitPod product roadmap include dramatically faster startup times, improved resiliency and a Gitpod Cloud offering for larger companies as well as a preview environment and workflows that foster collaboration. Gitpod also announced it passed a SOC2 Type II security audit.
Today, the Gitpod platform is being used by more than 750,000 developers at organizations such as Shopify, Stripe and Slack, noted Landgraf.
One of the longstanding issues that has always been problematic when building software is that code that runs on a local desktop doesn’t always work when deployed in a production environment. The Gitpod API will make it simpler to spin up various platforms and tools whenever a developer accesses a CDE. The goal is to make it possible to more closely replicate the production environments on which developers will ultimately deploy their applications, noted Landgraf.
In addition, a CDE should reduce the amount of data that developers routinely move between laptops and cloud computing environments as they build more complex applications, he added.
In the wake of the economic downturn, there is a lot more focus on developer productivity these days, especially as organizations look to accelerate their of digital business transformations. DevOps teams are also keen to find ways to centrally manage developer experience at a time when many of those developers continue to work from home, said Landgraf.
It’s not clear to what degree CDE will replace integrated development environments (IDEs) running on a local machine, but all the major cloud service providers are encouraging developers to build applications in the cloud where their applications will run. The challenge is that many of those offerings tend to lock developers into a specific cloud platform, noted Landgraf. Most developers today are building applications that need to be deployed across multiple clouds, he added.
One way or another, software development is increasingly shifting to the cloud. Most organizations will likely try to find a balance between the amount of code developed on a local machine that developers can just fire up when the mood strikes and the amount of code developed in the cloud. The most immediate challenge is to make sure the CDE experience is every bit as good as the existing local IDE.

At the Pulumi Cloud Engineering Days event, Pulumi announced today it has added a code deployment capability to its Pulumi Cloud platform for managing infrastructure-as-code (IaC).
Pulumi CEO Joe Duffy said Pulumi Deployments will make it possible for DevOps teams to provision infrastructure and deploy applications via a single Git commit that can be invoked via an application programming interface (API) or graphical tool.
A Git Push to Deploy capability allows DevOps teams to connect to any Git repository to drive deployments for a given project path, push to any given branch and set up GitOps workflows such as pull request reviews. Deployment actions include both updates and destroys in addition to providing drift detection and remediation capabilities.
The Deployments and Automation API Pulumi developed also enables ephemeral code review environments, automatic cleanup and deployment orchestrations across multiple cloud platforms using a library of templates Pulumi provides. In effect, Pulumi is now providing a GitOps workflow out of the box, said Duffy.
Pulumi has already integrated these capabilities with GitHub and plans to add support for GitLab, Atlassian Bitbucket and other DevOps platforms. The goal is to make it possible for DevOps teams to effectively manage ten times the amount of cloud infrastructure resources per engineer using GitOps workflows than is currently possible relying on IaC tools such as Terraform, said Duffy.

As an alternative to Terraform, the Pulumi platform has been gaining traction because it makes it possible to more easily centralize the management and provisioning of infrastructure using a set of embedded guardrails. One of the major issues enterprise IT organizations are encountering these days is the number of misconfigurations created when developers use tools like Terraform to provision infrastructure on their own. Those misconfigurations often lead to, for example, ports being left open and cybercriminals exfiltrating data. In the wake of a series of high-profile breaches, more organizations are now reviewing the security of their software supply chains including how infrastructure is provisioned by embedding policy-as-code into DevOps workflows.
At the same, organizations are also keenly interested in increasing the productivity of DevOps teams during an economic downturn that limits the number of IT professionals an organization can afford to hire, added Duffy.
Pulumi claims there are now more than 5 million users of its platform spanning more than 1,000 organizations. Less clear is the degree to which organizations are embracing GitOps workflows to unify deployments on IaC and application code. As platforms make it easier to make that transition, the number of organizations using a more opinionated approach to DevOps should steadily increase.
In the meantime, DevOps teams are going to be required to find ways to build and deploy safer applications faster. Much of the focus in recent years has been on accelerating application deployments with little regard for cybersecurity. Those days are clearly now coming to an end.

InfluxData has made good on a promise to deliver a next-generation time-series database that enables observability and monitoring tools used by DevOps teams to ingest high volumes of data more cost-efficiently.
In addition, for the first time, the latest iteration of the InfluxDB database supports the de facto standard SQL query language. Developers can run unlimited time-series workloads and contextualize data by any dimension without restrictions using SQL or existing tools such as the InfluxDB application programming interface (API), Flux scripting language or the InfluxQL query language
Brian Gilmore, director of internet-of-things (IoT) and emerging technologies for InfluxData, said InfluxDB is now based on a columnar engine, dubbed IOx, that leverages the open source Apache Arrow memory format and the Rust programming language accessed via a multi-tenant InfluxDB Cloud service that company manages on behalf of application developers. Use cases that require processing large volumes of data such as metrics, events, traces and other high cardinality data can now be queried in milliseconds, he noted.

The goal is to make this latest incarnation of InfluxDB available via a managed cloud service before providing IT teams with a version they can install themselves.
The arrival of a revamped InfluxDB architecture comes as the amount of data being generated across application environments continues to rapidly expand. Many DevOps teams are especially struggling with ways to process and store all the data being generated by cloud-native applications made up of microservices generating a steady stream of logs, metrics and traces.
InfluxData, of course, has ambitions for its database that go beyond application development and deployment environments. Edge computing platforms, for example, will increasingly process and analyze data in real-time at the point where it is generated and consumed. Similarly, applications infused with machine and deep learning algorithms will require databases that can process data at scale. Regardless of the use case, however, it’s apparent more IT teams will be embracing DataOps best practices alongside DevOps to manage data as applications are deployed and continuously updated.
It remains to be seen how many observability and monitoring tools might embrace this latest iteration of the InfluxDB database, but it’s clear DevOps teams should expect to see major advances as the underlying databases upon which these platforms depend continue to evolve. The goal is to ultimately eliminate the tradeoff that now often occurs between how much data is collected and analyzed versus the cost of processing and storing it.
In the meantime, DevOps teams will need to decide whether they want to manage databases themselves as more managed services become easier to invoke in the age of the cloud. Most database selections these days are made by development teams that aren’t especially eager to take on the tasks normally performed by a database administrator. A managed service essentially outsources responsibility for managing a database to a services provider instead of requiring IT teams to hire a DBA themselves.
One way or another, however, the speed at which data can now be processed in real-time should sharply reduce the need to rely on existing and cumbersome batch-oriented approaches to processing data.

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.

At the KubeCon + CloudNativeCon North America conference this week, JFrog announced it contributed the Pyrsia project, which uses blockchain technologies to secure software packages, to the Continuous Delivery (CD) Foundation.
Stephen Chin, vice president of developer relations at JFrog and governing board member for the CD Foundation, said the goal is to increase the number of contributors to the project. Current contributors to the Pyrsia project include Docker, Inc., DeployHub, Futurewei and Oracle.
As part of those efforts, the CD Foundation will bring a centralized governance model through which a roadmap for the project will be defined.
Pyrsia provides IT teams with a decentralized blockchain network to access an immutable software package repository that is designed to seamlessly integrate with the package management systems developers already employ. It creates a digitally signed, immutable chain of evidence for code that can be incorporated into a software bill of materials.
Securing software supply chains became a more urgent issue following the discovery last year of the zero-day Log4Shell vulnerability that impacted Java applications. Many developers routinely reuse open source software, but many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited; the onus for making sure that software is secure falls on the organizations that decide to deploy it.
The trouble is, many organizations that rely on open source software assume it is more secure than it really is. Initiatives like Project Pyrsia are part of a larger effort to make it simpler for maintainers to secure open source software.
It’s not clear to what degree security concerns are prompting organizations to review the amount of open source software they consume. Most organizations are more dependent on open source software than they realize, as most packaged applications include a large amount of open source code that is downloaded from any number of repositories. Whenever a zero-day vulnerability is discovered, organizations can easily spend months looking for all the instances of an open source component that might be vulnerable.
In theory, blockchain platforms and DevSecOps best practices should make it easier to secure software packages by reducing the number of vulnerabilities in production environments. The challenge organizations face today is the amount of technical security debt that exists due to vulnerabilities in legacy applications. It might be close to a decade before applications based on more secure code replace existing solutions.
In the meantime, multiple approaches to securing software supply chains are advancing, including the use of some type of immutable platform. It may be a while before those platforms are widely incorporated into software supply chains, but it’s apparent that it’s now more a question of how long it will take rather than if those technologies will be applied to securing software development environments.

The need to protect SaaS data has never been greater. A recent global survey from Odaseva found that 51% of ransomware attacks are targeting SaaS data, and they are more likely to succeed (52%) than were attacks on cloud, endpoint and on-premises data.
But there are plenty of reasons beyond the threat of ransomware to protect SaaS data. Employees accidentally—and maliciously–delete data. And while outages are not common, they do happen, and when they do, it can cause a lot of pain. Atlassian, for instance, suffered a two-week outage in April. If the data isn’t backed up, the organization is completely at the mercy of the provider to get the service back online before they can access it.
And though all respondents said their organizations say they have some form of SaaS data protection in place, 57% said they still have SaaS data that remains unprotected. Likely, that’s why only half of respondents whose SaaS data had been successfully encrypted by an attack said they were able to recover all of it, compared to more than eight in 10 (81%) who were able to do so for on-premises data.
That’s not surprising, because backing up SaaS data is very different from on-premises data protection. For starters, of course, IT has limited control, at best, over the application and data. IT will need to rely on APIs to back up and restore SaaS data, and those API calls will have hard caps. SaaS providers almost always run their services on a multi-tenant architecture, so they need to make sure API resources are available for everyone. To accomplish this goal, they set hard caps on API calls, typically over a 24-hour period, which means that IT must carefully manage API usage for backup and restore operations. And with many different APIs with different capabilities and limitations to choose from, IT will need to make some hard, complex choices.
Managing API usage is important, and not just for backup. These same APIs are also vital for connecting other applications integrated into the SaaS application. And for core SaaS apps, such as CRM or ERP, there will likely be many such integrated applications that require the use of those APIs.
To get the best performance, IT needs to be very careful with the APIs it uses for backup and recovery. Let’s take Salesforce as an example. The Salesforce REST API can transfer up to one million records per hour, while the BULK API can do up to ten times more in the same amount of time. And if you use parallel calls to multiplex data, the BULK API can do up to 300 million. The upshot is that the API you use can make a huge difference in your recovery point objectives (RPOs) because transferring more data faster means more backups throughout the day.
Unfortunately, Salesforce customers won’t be able to depend on BULK API for all their backup and recovery needs. Some objects can only be accessed via the REST or other APIs, for instance, and that BULK API will also be useful to other apps—you don’t want to hit that hard cap and leave other applications unable to connect. And you can’t always use the same API to write data as you do to read it.
The SaaS backup infrastructure has to achieve a balance of API usage, which must be closely managed. And don’t forget about restore, which can consume a ton of API resources. Make sure you have enough to account for a big restore—you really don’t want to hit the API cap while you’re trying to get your users back in business after a data loss event.
Lastly, APIs change over time and the backup system has to be able to adapt. You’ll need to make sure you keep up with API documentation so the system can be updated regularly; otherwise, data may go unprotected.
It’s now becoming widely accepted that SaaS data needs to be protected, but building a SaaS backup solution that meets an organization’s RPOs and RTOs is more complex than many in IT may realize. A strategic plan for API management is a must-have for any SaaS backup management solution.

Organizations continue to increase their footprint in the cloud. Yet, applying governance and enforcing policies across multiple cloud environments at scale is a challenging endeavor. Organizations typically have governance policies written in English, but translating them into enforceable code has historically required some custom workarounds. In the same vein as infrastructure-as-code (IaC), DevOps engineers now seek a similar GitOps approach to implement shared policies across cloud-based workloads.
Cloud Custodian is one such toolset that can manage and enforce cloud policies in a standardized format. Using Cloud Custodian, a Cloud Center of Excellence has the building blocks to create policies for security governance, development guardrails and cloud cost optimizations. The free, open source project, which has been steadily evolving for years, recently gained its incubation status with the Cloud Native Computing Foundation (CNCF) and to date boasts over 350 contributors on GitHub.
I met with Kapil Thangavelu, Cloud Custodian creator and maintainer and CTO at Stacklet, to learn more about Cloud Custodian and what features we should anticipate from the project in the near future. Below, we’ll provide a comprehensive introduction to Cloud Custodian, exploring its history, how to use it and its core benefits. We’ll also analyze a few sample policies to showcase how Cloud Custodian functions in practice.
Cloud Custodian got its start as an internal tool developed within Capitol One toward the end of 2015, explains Thangavelu. At the time, engineers were grappling with the newfound realities of managing the cloud at scale and realized that having one-off ad-hoc policies across teams was causing friction. “It’s really hard to manage and enforce policies at scale,” says Thangavelu. So, engineers toyed with creating a more GitOps approach to policies around governance and security that could be run as an internal SaaS solution.
Thus, Cloud Custodian was born. The YAML DSL tool allows you to easily define rules to manage cloud infrastructure. It can offer real-time enforcement and produce event-based responses. For example, you can create policies that require tags on resources or one that turns off instances during off-hours. Or, a policy could prevent a developer without the proper privileges from accidentally making an open load balancer. Cloud Custodian supports AWS, Azure, and GCP and policies are specified to a resource type, whether it’s EC2, ASG, Redshift, CosmosDB or a PubSub Topic.
Thangavelu describes Cloud Custodian as a bunch of Lego bricks that developers can pick up to build guardrails in arbitrary ways. Instead of shipping with canned rulesets, “Cloud Custodian makes customization itself a first-class citizen,” he says. Capital One open sourced the project and contributed Cloud Custodian to CNCF in August 2020.
Cloud Custodian comes with a library of actions and filters. Let’s take a look at a few example policies across the three main cloud providers. But first, to install Cloud Custodian from PyPI, you can initiate the following command:
$ python3 -m venv custodian
$ source custodian/bin/activate
(custodian) $ pip install c7n
Let’s consider an example policy that would improve security hygiene on AWS. Below is one such policy that creates a CloudWatch Event to be triggered anytime a user logs in from an invalid IP address. This could be used to ping a security administrator to investigate. With this rule, it’s also possible to turn on an auto-remediation function.
policies:
- name: invalid-ip-address-login-detected
resource: account
description: |
Notifies on invalid external IP console logins
mode:
type: cloudtrail
events:
- ConsoleLogin
filters:
- not:
- type: event
key: 'detail.sourceIPAddress'
value: |
'^((158\.103\.|142\.179\.|187\.39\.)([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])
\.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]))|(12\.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])
\.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]))$'
op: regex
actions:
- type: notify
template: default.html
priority_header: 1
subject: "Login From Invalid IP Detected - [custodian {{ account }} - {{ region }}]"
violation_desc: "A User Has Logged In Externally From A Invalid IP Address Outside The Company's Range:"
action_desc: |
"Please investigate and revoke the invalid session along
with any other restrictive actions if appropriate"
to:
- CloudAdmins@Company.com
- SecurityTeam@Company.com
transport:
type: sqs
queue: https://sqs.us-east-1.amazonaws.com/12345678900/cloud-custodian-mailer
region: us-east-1
Next, let’s consider a policy that would add some degree of governance for developers working on Azure. One simple yet popular policy involves tagging the ownership details to individual resources. This policy, therefore, will tag all resource groups with the creator’s email address:
policies:
- name: azure-auto-tag-creator-resource-groups
resource: azure.resourcegroup
description: |
Tag all existing resource groups with the 'CreatorEmail' tag; looking up to 10 days prior.
actions:
- type: auto-tag-user
tag: CreatorEmail
days: 10
Finally, let’s consider a policy that could aid in cost optimization on GCP. Below is a sample policy to enforce minimal CPU utilization for autoscalers on GCP. Implementing such a policy could help avoid underutilization to combat rising cloud costs.
vars:
min-utilization-target: &min-utilization-target 0.8
policies:
- name: gcp-autoscalers-enforced
resource: gcp.autoscaler
mode:
type: gcp-audit
methods:
- v1.compute.autoscalers.insert
filters:
- type: value
key: autoscalingPolicy.cpuUtilization.utilizationTarget
op: less-than
value: *min-utilization-target
actions:
- type: set
cpuUtilization:
utilizationTarget: 0.8
By automating a lot of the tedious policy management away, Cloud Custodian could reduce risk and accidents through more streamlined cloud governance. “It solves the natural problems when infrastructure is in everyone’s head,” says Thangavelu. By aggregating ad-hoc scripts and unifying policies across an organization, you could immediately instigate new rules without manually reminding all members of an organization, which could take years.
For those familiar with Open Policy Agent (OPA), you may notice some overlap in the objectives, as both are engines for enacting cloud-native policies. Compared to OPA, Cloud Custodian has some developer experience perks. For one, you don’t have to use Rego, as the policies are written in YAML, which is a familiar configuration language for DevOps engineers. Cloud Custodian uses abstractions on event runtimes for each cloud provider. Furthermore, compared to OPA, you don’t need to bind the engine for a particular problem domain, says Thangavelu, as Cloud Custodian is specifically bounded to cloud governance and management.
Cloud Custodian is also battle-tested. Many big names are using it in production, including Capital One, HBO Max, Intuit Inc, JP Morgan Chase & Co, Siemens and Zapier. Across its adoption, the tool tends to either be utilized by a Center of Cloud Excellence, security teams to conduct reporting or reveal real-time incidents or the CFO to direct cost optimizations.
Cloud Custodian maintainers describe the project as a consistent firehouse. Since the project tracks changes in all cloud provider resources in real-time, it’s quite a dynamic toolset. In addition to monthly updates, users can expect many additional updates on the horizon, including support for Tencent Cloud as well as additional Kubernetes support. Additional work is being done around shift-left capabilities to meet the developer where they are, says Thangavelu.
For more information, check out the Quickstart Guide to Cloud Custodian, or view the project roadmap here.

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.