THE PANDEMIC HAS compelled enterprises to rapidly move their critical workload to the cloud to ensure seamless functioning of business. As cloud is gaining momentum, and enterprises are frantically looking for ways to optimise their network, storage and agility, edge computing has turned out to be the perfect solution.

To understand where edge computing fits in the whole spectrum of IT infrastructure, we need to begin with the basics— Understanding what actually is edge computing. “Edge computing” is a type of distributed architecture in which data processing occurs close to the source of data, that is, at the “edge” of the system. This approach reduces the need to bounce data back and forth between the cloud and device while maintaining consistent performance. This reduces latency in data transmission and computation, thereby enhancing agility.

With regards to infrastructure, edge computing is a network of local micro data centers for storage and processing purposes. At the same time, the central data centre oversees the proceedings and gets valuable insights into the local data processing. However, we need to be mindful that edge computing is a kind of expansion of cloud computing architecture— an optimised solution for decentralised infrastructure.

The ultimate purpose of edge computing is to bring compute, storage, and network services closer to endpoints and end users to improve overall application performance. Based on this knowledge, IT architects must identify and document instances where edge computing can address existing network performance problems.

How does edge computing work?
In traditional enterprise computing, data is produced at a user’s computer. That data is moved across a WAN such as the internet, through the corporate LAN, where the data is stored and worked upon by an enterprise application. Results of that work are then conveyed back to the end-user. However, if we consider the number of devices that are connected to a company’s server, also the volume of data it generates, it is far too much for a traditional IT infrastructure to accommodate.
So, IT architects have shifted focus from the central data centre to the logical edge of the infrastructure—taking storage and computing resources from the data centre and moving those resources to the point where the data is generated.

There are several reasons for the growing adoption of edge computing:

Due to emerging technologies such as IoT and IoB, data is being generated in real-time. Devices enabled by these technologies require a high response time and considerable bandwidth for proper operation.
Cloud computing is centralised. Transmitting and processing massive quantities of raw data puts a significant load on the network’s bandwidth.
Incessant movement of large quantities of data back and forth is beyond reasonable cost-effectiveness and leads to latency.
Processing data at the source and then sending valuable data to the centre is a more efficient solution.
As organisations move back to remote working models, we will witness wider adoption of edge computing as it empowers remote work infrastructure with greater computation and storage capabilities.

Discussions about the relationship between cloud computing and edge computing have a tendency to present the cloud and edge as opposite types of architectures and to treat them as an either/or proposition.

This isn’t the best way to think about cloud and edge. Although there are key differences between cloud and edge computing, the cloud and the edge don’t compete with each other as much as they complement each other.

Differences between cloud and edge
The differences between cloud computing and edge computing boil down largely to where workloads are hosted.

In a conventional cloud, data and applications are housed in large data centers located within a public cloud vendor’s network.

In an edge architecture, workloads are hosted in a location that is “closer” — from the perspective of the network — to end-users than is a traditional data center.

Multiple approaches to edge computing
It’s worth noting that the definition of edge can get a little messy because there are many possible ways to build an edge architecture. Sometimes, an edge environment runs directly on end-user devices. In others, it looks more like a traditional data center populated by conventional servers, which happen to be closer to end-users than traditional cloud data centers.

Cloud computing tends to be more straightforward from an architectural perspective. Although there can be some variation in which cloud regions and zones teams use to host workloads, all public cloud environments rely on conventional data centers that are comparatively distant — again, in networking terms — from end-users.

Why cloud and edge computing go together
Although cloud and edge computing are fundamentally different types of architectures, “cloud vs. edge” is not necessarily the best way to think about them.

In many cases, it makes sense to use both cloud and edge at the same time. Cloud data centers can host workloads that don’t require the minimal latency and high reliability of those hosted on the edge, while edge infrastructure handles those that do.

By pairing cloud and edge together, organizations can leverage the scalability and ease of deployment of cloud environments while still achieving high-performance goals that cloud data centers can’t always support due to network latency issues.

This isn’t to say that you always have to use cloud and edge at the same time. It’s entirely possible to host applications or data in the cloud without also running an edge environment. It’s also possible — although less common — to use edge without using a public cloud.

Cloud and edge supercharge performance
But in general, using cloud computing and edge computing at the same time can lead to the best overall outcome from a performance perspective. The only big downside is that it can be harder to manage a cloud environment and an edge environment at the same time, although platforms like Kubernetes simplify this by making it easy to deploy applications to both types of environments from a central management plane.

Verizon Business and Amazon Web Services said Monday they are expanding their 5G collaboration to bring private mobile edge computing (MEC) to U.S. enterprise customers.

The solution will deliver a completely dedicated edge compute infrastructure on-premise that enables ultra-low latency, higher levels of security and deeper customization that fully integrates Verizon’s Private 5G networks and Private Edge platform with AWS Outposts, according to the announcement.

This allows Verizon enterprise customers to use the private MEC to deploy real-time enterprise applications like intelligent logistics, robotics, predictive maintenance, factory automation and more to help lower costs and improve efficiency.

Corning Inc., a materials science and advanced manufacturing company, will be the first company to leverage the solution, according to the announcement.

The solution will have use cases in factories, warehouses, and large business campuses and it supports unified connectivity, compute and storage without having the customer having to own the networking and IT infrastructure.

According to Verizon, the MEC solution will support a wide range of industrial applications, like autonomous mobile robots, predictive maintenance, quality assurance and near real-time monitoring and hazard alerts.

“Verizon’s Private 5G Edge platform will give customers a reliable, secure, high bandwidth, low latency connection to AWS services, APIs, and tools running on AWS Outposts,” the Verizon announcement said. “Additionally, two smaller AWS Outposts — 1U and 2U form factors — will give customers options to deploy AWS on-premises in space-constrained locations.”

The edge computing collaboration between the two companies began with the Verizon 5G Edge with AWS Wavelength, which was launched in August. The companies have announced the general availability of 5G mobile edge computing via Wavelength Zones in 10 cities across the U.S.

Private MEC is a natural expansion on the collaboration between the two companies, said Dave Brown, vice president of Elastic Compute Cloud at AWS, in a statement.

“Customers are already leveraging AWS Wavelength’s ability to provide ultra-low latency access to end users for use cases like video distribution, inference at the edge, AR/VR, and connected vehicles,” Brown said. “Now, Private 5G MEC from AWS and Verizon brings ultra-low latency to dedicated, closed, on-premises environments for use cases such as autonomous mobile robots, quality assurance, and hazard alerting.”

Edge infrastructure can integrate with central cloud data centers to deliver performance levels that wouldn’t be possible using the cloud alone.

You’ve heard of cloud computing. You’ve probably also heard of edge computing. But do you understand the differences between the cloud and the edge?

That’s a simple question with a relatively complex answer since both cloud and edge architectures can come in various forms. Let’s try to break down the similarities and differences between cloud computing and edge computing and explain how they relate to each other.

What is the cloud?
Cloud computing, of course, is an architecture in which data or processing are offloaded to servers hosted in a remote data center.

Clouds come in many forms – public, private and hybrid – and there are a wide variety of cloud services available, ranging from basic virtual machines and storage to serverless functions, IoT device management, and even satellite communication controls.

What is the edge computing?
In an edge architecture, data or processing are offloaded to remote infrastructure that is not necessarily a traditional data center. That work is done “closer” to end-users – in terms of geographic and network proximity –than a conventional data center.

One of the factors that makes edge complicated is that edge infrastructures can take a variety of forms. Edge infrastructure could consist of traditional data centers that are simply closer to users than a centralized cloud data center. But edge infrastructure could also be a network of IoT sensors that stores and processes data. It could even be end-user devices themselves, like smartphones, onto which data storage and processing are directly outsourced.

Cloud vs. edge
The varying forms of edge infrastructure make it difficult in some respects to distinguish cloud architectures from edge architectures. For instance, some hybrid clouds are arguably also edge architectures if they mix cloud data centers with local data centers in a way that brings some workloads closer to the network edge. A multi-region public cloud could also be considered a form of edge architecture if it includes regions that place workloads closer to the network edge than they would be in a single-region environment.

That said, the general distinction between edge computing and cloud computing is that in an edge architecture, workloads are close enough to end-users to deliver latency rates that are measured in single- or double-digit milliseconds. Many applications now require such low latency. For example, self-driving and autonomous vehicles do not have the time to send a video stream to a data center for image analysis to decide whether a pedestrian is in the car’s path? The data analysis, decision-making, and action must be done on the vehicle, which is essentially a complex edge device.

A conventional cloud environment is not usually capable of that level of performance. For example, latency between different AWS regions is typically measured in the hundreds of milliseconds (and that is inter-region, intra-cloud latency, which is likely to be lower in many cases than latency between the cloud and an end-user).

Edge computing as an extension of cloud
It’s worth noting, too, that edge computing is not an alternative to cloud computing as much as it is an extension of it. Edge infrastructure can integrate with central cloud data centers to deliver performance levels that wouldn’t be possible using the cloud alone.

Viewed from this perspective, the somewhat hazy relationship between edge and cloud comes into sharper focus. Don’t worrying about what counts as an edge architecture and what counts as the cloud in contexts where the distinctions are ambiguous. Think of edge and cloud as complementary setups that, when combined, deliver an end-user experience that adds up to more than the sum of its parts.

Microsoft on Dec. 7 announced Azure Government Top Secret, a new cloud for Top Secret classified data, and outlined new features of Azure Government and the expansion of Azure Government Secret as part of its annual Government Leaders Summit.

In a Microsoft Azure blog, Tom Keane, corporate vice president of Azure global, said Azure Government Top Secret, which has been undergoing federal accreditation, is designed to provide the same capabilities as the commercial version of Azure, Azure Government and Azure Government Secret, “enabling a continuum of compute from mission cloud to tactical edge.”

New features of Azure Government Secret, which is authorized by both Department of Defense impact level 6 and intelligence community directive 503, address needs of application developers and security analysts. The new Azure Kubernetes Service and Azure Container Instances will allow developers to better deploy and manage containerized applications. With Azure Sentinel and Azure Security Center analysts can collect, analyze, and act on telemetry data from their Azure and on-premises environments to deliver unified security and proactive threat management.

For the Azure Government cloud, Availability Zones give users redundancy and logical isolation of data center services, assuring that critical customer services and workloads are available anywhere 24/7. Additionally Windows Virtual Desktop in Azure Government recently became available, accredited at the high level by the Federal Risk and Authorization Management Program.

To address needs of users working on the tactical edge, Microsoft announced rugged hardware to that supports low-latency data processing, making it easier for agencies to deploy artificial intelligence and machine learning to the network edge or access satellite data in disconnected environments. The Azure Modular Data Center — available at impact levels 5 and 6 – was announced in October, but now has a high availability power module and a network high availability module that provides network resiliency through multiple satellite communication partners in different orbits.

The ruggedized versions of Azure Stack Hub, Azure Stack Edge Pro R and the portable Azure Stack Edge Mini R are now generally available for customers in Azure Government and Azure Government Secret.

Microsoft made these government cloud announcements as part of its annual Government Leaders Summit.

AWS today closed out its first re:Invent keynote with a focus on edge computing. The company launched two smaller appliances for its Outposts service, which originally brought AWS as a managed service and appliance right into its customers’ existing data centers in the form of a large rack. Now, the company is launching these smaller versions so that its users can also deploy them in their stores or office locations. These appliances are fully managed by AWS and offer 64 cores of compute, 128GB of memory and 4TB of local NVMe storage.

In addition, the company expanded its set of Local Zones, which are basically small extensions of existing AWS regions that are more expensive to use but offer low-latency access in metro areas. This service launched in Los Angeles in 2019; starting today it’s also available in preview in Boston, Houston and Miami. Soon, it’ll expand to Atlanta, Chicago, Dallas, Denver, Kansas City, Las Vegas, Minneapolis, New York, Philadelphia, Phoenix, Portland and Seattle. Google, it’s worth noting, is doing something similar with its Mobile Edge Cloud.

The general idea here — and that’s not dissimilar from what Google, Microsoft and others are now doing — is to bring AWS to the edge and to do so in a variety of form factors.

As AWS CEO Andy Jassy rightly noted, AWS always believed that the vast majority of companies, “in the fullness of time” (Jassy’s favorite phrase from this keynote), would move to the cloud. Because of this, AWS focused on cloud services over hybrid capabilities early on. He argues that AWS watched others try and fail in building their hybrid offerings, in large part because what customers really wanted was to use the same control plane on all edge nodes and in the cloud. None of the existing solutions from other vendors, Jassy argues, got any traction (though AWS competitors would surely deny this) because of this.

The first result of that was VMware Cloud on AWS, which allowed customers to use the same VMware software and tools on AWS they were already familiar with. But at the end of the day, that was really about moving on-premises services to the cloud.

With Outposts, AWS launched a fully managed edge solution that can run AWS infrastructure in its customers’ data centers. It’s been an interesting journey for AWS, but the fact that the company closed out its keynote with this focus on hybrid — no matter how it wants to define it — shows that it now understands that there is clearly a need for this kind of service. The AWS way is to extend AWS into the edge — and I think most of its competitors will agree with that. Microsoft tried this early on with Azure Stack and really didn’t get a lot of traction, as far as I’m aware, but it has since retooled its efforts around Azure Arc. Google, meanwhile, is betting big on Anthos.

The OpenStack Foundation’s StarlingX project reached a significant milestone in mid-2019 with the release of version 2.0 of its edge computing cloud infrastructure platform. The update delivers deeper Kubernetes integration, containerized OpenStack services, and a cleaner upstream OpenStack codebase — changes that collectively make StarlingX a more practical choice for organizations deploying cloud workloads at the network edge.

What Is StarlingX?

StarlingX is an open-source cloud infrastructure platform designed specifically for edge computing and IoT use cases. Originally based on code contributed by Wind River Systems, it debuted under the OpenStack Foundation in late 2018. The platform targets environments where compute resources must operate at the edges of a network — such as 5G base stations, remote industrial facilities, and small branch offices — rather than in centralized data centers.

Unlike general-purpose cloud platforms optimized for large-scale core data centers, StarlingX is engineered around the constraints of edge deployments: limited hardware footprint, intermittent connectivity, strict latency requirements, and the need for high reliability with minimal on-site IT staff.

Key Changes in StarlingX 2.0

Kubernetes Integration

The most significant architectural change in version 2.0 is the integration of Kubernetes as the container orchestration layer. This makes it straightforward for operators to deploy and manage containerized workloads at edge sites, without needing a separate orchestration platform.

“The platform went through a drastic change with the transformation to leverage the benefits of using container technologies,” said Ildiko Vancsa, ecosystem technical lead at the OpenStack Foundation. “The community has been working hard since the 1.0 release to build an open infrastructure solution for edge and IoT use cases … utilizing multiple well-known open-source components.”

Containerized OpenStack Services

Starting with version 2.0, OpenStack services themselves run inside containers. This approach simplifies deployment, improves upgrade manageability, and isolates control plane services from the underlying host. The platform integrates OpenStack and Kubernetes components using Airship — an OpenStack Foundation project for automated cloud provisioning — to provide both flexibility and robustness.

Upgrade to OpenStack Stein

Glenn Seiler, vice president of open source strategy at Wind River Systems, highlighted the upgrade from OpenStack Pike to OpenStack Stein (released April 2019) as another major improvement. The previous StarlingX 1.0 release carried significant technical debt in the form of patches applied on top of Pike. With 2.0, the project now runs a largely unmodified “vanilla” OpenStack, reducing maintenance burden and improving long-term supportability.

Security Enhancements

Version 2.0 adds two notable security features:

• Trusted Platform Module (TPM) support: Enables secure storage of cryptographic secrets using hardware TPM devices.
• UEFI Secure Boot: Adds firmware-level boot integrity verification to protect against low-level tampering.

Precision Time Protocol (PTP) Support

StarlingX 2.0 also adds support for the Precision Time Protocol (PTP), which provides highly accurate clock synchronization across a network. This is critical for industrial automation and telecom environments where Network Time Protocol (NTP) does not offer sufficient precision — for example, synchronizing equipment across a factory floor or within a telecom radio access network.

OpenStack Is No Longer Required

Despite being an OpenStack Foundation project, StarlingX 2.0 does not require OpenStack for all deployment scenarios. Organizations that only need to run containerized workloads can deploy on bare metal using Kubernetes alone, without provisioning the full OpenStack stack.

If virtual machine (VM) support is needed, StarlingX packages the OpenStack services and VMs inside containers. Some OpenStack-derived services do remain on the controller in all configurations — Keystone for identity and secret management, and Horizon for the administrative web interface — but these do not impose an OpenStack dependency on container workloads themselves.

“There isn’t any OpenStack dependency on container workloads.”

Glenn Seiler, VP of Open Source Strategy, Wind River Systems

StarlingX in the Edge Computing Landscape

The edge computing space was already crowded with competing platforms and reference architectures in 2019. Seiler argued that StarlingX differentiates itself through pre-integration: all component dependencies, version pinning, and integration testing are handled by the project before release, rather than being left to operators to configure themselves.

Many competing projects provide reference architectures or loosely validated component combinations, but require substantial operator effort to achieve a production-ready configuration. Seiler’s position is that StarlingX aims to be genuinely deployment-ready out of the box.

Wind River has also indicated that StarlingX would form the technical foundation for a future commercial product offering, though specifics were not disclosed at the time of the 2.0 release.

What Comes Next for StarlingX?

With 2.0 shipped, the StarlingX community outlined an accelerated release cadence. Vancsa indicated that StarlingX 3.0 was targeted for later in 2019, and that subsequent releases would follow a cycle-trailing model aligned with the OpenStack release calendar — meaning two releases per year.

The community also announced expanded investment in testing, including sanity testing, robustness testing, and exploration of performance benchmarking.

“StarlingX is a very friendly and open community which is still growing and looking for participation and feedback from anyone who is interested in the platform or the use cases it is designed to provide a solution for.”

Ildiko Vancsa, Ecosystem Technical Lead, OpenStack Foundation

Summary

StarlingX 2.0 represents a substantial architectural maturation of the platform: Kubernetes is now a first-class citizen, OpenStack services are fully containerized, the OpenStack base has been upgraded and de-patched, and new security and timing features address real edge and telecom requirements. For DevOps and infrastructure teams evaluating edge cloud platforms, StarlingX 2.0 is worth examining — particularly for 5G, industrial IoT, and distributed enterprise scenarios where pre-integrated, deployment-ready infrastructure reduces operational risk.

Further reading: OpenStack Foundation Edge Computing | StarlingX Project Homepage

What Is Azure IoT Edge?

The Internet of Things (IoT) is a technology paradigm built around internet-connected devices that publish data streams — often feeding into real-time processing pipelines, machine learning models, or cloud storage services. Azure IoT Edge extends this model by allowing cloud workloads (analytics, AI, custom business logic) to run directly on edge devices, closer to where data is generated.

Managing these distributed, containerized workloads at scale introduces real engineering challenges: how do you reliably build, test, and deploy IoT Edge modules across a fleet of devices? The answer lies in applying the same DevOps principles used for cloud-native software development.

Why DevOps Matters for IoT Edge Solutions

Modern DevOps practices — automation, continuous integration, continuous delivery, monitoring, and quality gates — are just as valuable for IoT Edge development as they are for web services. Without a disciplined pipeline, deploying and validating module updates across many edge devices quickly becomes error-prone and slow.

Applying DevOps to IoT Edge development typically involves:

• Automated builds: Compile and containerize IoT Edge modules on every code change.
• Automated testing: Run smoke tests and integration tests before promoting a build.
• Container registry management: Store and version module images in Azure Container Registry (ACR).
• Scalable integration testing: Use Kubernetes replica sets to simulate multiple edge devices during testing.
• Monitoring and observability: Instrument modules with Application Insights to capture telemetry and diagnose failures.
• Automated deployment: Push validated module configurations to target IoT Edge devices via Azure IoT Hub.

Key Components of the Pipeline

Azure Pipelines (Azure DevOps)

Azure Pipelines orchestrates the entire CI/CD workflow. It builds IoT Edge module images, pushes them to ACR, runs test stages, and triggers deployments. Critically, the Azure IoT Edge task is now a built-in, in-house task within Azure Pipelines — meaning it is pre-installed in every Azure DevOps account. You no longer need to install it separately from the Visual Studio Marketplace.

Azure Container Registry (ACR)

IoT Edge modules are packaged as Docker containers. ACR provides a private, managed registry to store these images. Pipelines push newly built images to ACR, and IoT Hub deployment manifests reference those images by digest or tag to ensure devices pull the correct version.

Azure Kubernetes Service (AKS) for Integration Testing

One of the more powerful techniques in this pipeline is using AKS and Kubernetes replica sets to run scalable integration tests. Rather than requiring a physical fleet of edge devices for testing, containerized IoT Edge device simulators can be deployed as pods in a Kubernetes cluster. This allows tests to run against multiple simulated device instances in parallel, increasing confidence before a real-world rollout.

Application Insights

Application Insights provides telemetry, logging, and alerting for IoT Edge modules. Instrumenting modules with the Application Insights SDK (or routing logs through Azure Monitor) gives teams visibility into module health, exception rates, and custom metrics — supporting both pre-release smoke testing and post-deployment monitoring.

Pipeline Stages at a Glance

A typical end-to-end IoT Edge DevOps pipeline follows these stages:

1. Build: The Azure IoT Edge task compiles module code and builds Docker images for each target platform (e.g., amd64, arm32v7).
2. Push: Built images are tagged and pushed to Azure Container Registry.
3. Smoke Test: A quick validation stage confirms the module container starts correctly and responds as expected.
4. Integration Test: The pipeline deploys the containerized IoT Edge device simulator to AKS as a replica set, running more thorough end-to-end tests against multiple simulated instances.
5. Release: Validated images are promoted and an updated deployment manifest is pushed to Azure IoT Hub, triggering the rollout to real edge devices.
6. Monitor: Application Insights dashboards and alerts track module health post-deployment.

Important Note: Azure IoT Edge Task Location

As of the time of the original presentation (note at timestamp ~5:55): the Azure IoT Edge task has moved to Azure Pipelines in-house tasks. This means the task is pre-installed in any Azure DevOps account — you do not need to install the extension from the Visual Studio Marketplace to use the Azure IoT Edge build and deploy task.

Resources and Reference Implementations

The following repositories and marketplace extensions were referenced in the original presentation:

• IoTEdge-DevOps reference implementation (GitHub) — A sample project demonstrating the full DevOps pipeline for IoT Edge solutions.
• Replace Tokens extension (Visual Studio Marketplace) — Used to substitute configuration values (e.g., registry credentials, connection strings) into deployment manifests during pipeline execution.
• IoT Edge Build and Deploy extension (Visual Studio Marketplace) — Note: as described above, this functionality is now available as an in-house Azure Pipelines task.
• Azure IoT Edge Device Container (GitHub) — A containerized IoT Edge device simulator used for scalable integration testing in Kubernetes.

Summary

Bringing DevOps discipline to Azure IoT Edge development dramatically improves the reliability and velocity of module deployments. By combining Azure Pipelines, Azure Container Registry, Application Insights, and AKS-based integration testing into a cohesive pipeline, teams can validate changes thoroughly before they reach physical edge devices — reducing risk and accelerating iteration cycles.

The reference implementation at github.com/toolboc/IoTEdge-DevOps is a practical starting point for teams building their own IoT Edge CI/CD pipelines.

Cloud Adoption Has Reached the Tipping Point — But the Story Isn’t Over

For enterprise IT, cloud computing is no longer a question of whether — it is a question of when and how. Most large organizations have either executed a cloud strategy or are actively mid-migration. After years of skepticism, hybrid and multi-cloud architectures have become mainstream, and the benefits in scalability, cost elasticity, and developer velocity are well understood.

Yet, even as enterprises settle into this new normal, a structural shift is underway that demands attention from IT and business leaders. Edge computing — the practice of processing data closer to where it is generated rather than sending it to a centralized cloud — is rapidly maturing and beginning to alter the architecture of enterprise systems.

The Edge Computing Argument: Peter Levine’s Prediction

Venture capitalist Peter Levine of Andreessen Horowitz put forward a provocative thesis: the gravitational pull that sent compute and storage toward centralized cloud data centers is now reversing, driven by the explosive growth in on-device compute power at the edge.

Levine’s clearest example is the autonomous vehicle. A modern luxury car already contains roughly 100 CPUs managing everything from engine control to infotainment. A fully self-driving vehicle of the near future could contain more than 200 connected computing units — effectively making it a rolling data center.

“If you think about a self-driving car, it’s effectively a data center on wheels.”

Peter Levine, Andreessen Horowitz

An autonomous vehicle may generate approximately 10 GB of sensor data per mile driven. Sending all of that to a remote cloud data center for processing before acting on it is not viable — the latency alone would be dangerous. The vehicle must process, interpret, and act on most of that data locally, in real time, without waiting for a round trip to the cloud.

What “The Edge” Actually Means

In this context, “the edge” refers to the broad category of compute-capable devices operating outside centralized data centers. This includes:

• IoT sensors and smart devices embedded in factories, buildings, and infrastructure
• Autonomous vehicles and drones that must process environmental data in real time
• Industrial robots performing closed-loop control with millisecond tolerances
• Mobile devices running increasingly sophisticated on-device AI workloads
• Web browsers acting as lightweight application runtimes

Each of these categories shares a common trait: they generate data at the point of action and often require a response before a cloud round-trip is possible or economically justified.

Is Cloud Computing Dead? No — It’s Evolving Into a Hybrid Ecosystem

Levine’s argument is sometimes characterized as a prediction of cloud’s demise. That reading is an overstatement. What he describes is better understood as a distributed, hybrid compute model in which workloads are placed wherever they can be executed most effectively:

• Edge devices handle real-time inference, sensor fusion, and immediate control decisions
• Regional edge nodes or on-premises infrastructure aggregate and pre-process data before passing selected subsets upstream
• Centralized cloud platforms handle compute-intensive batch workloads such as model training, large-scale analytics, and long-term data storage

Using the autonomous vehicle again: the vehicle’s onboard systems handle moment-to-moment driving decisions. Only data that is useful for improving machine learning models, informing fleet analytics, or feeding regulatory reporting makes the trip to the cloud. The cloud then trains updated models, which are pushed back to the fleet. This is a tightly integrated feedback loop — not a choice between edge and cloud, but a deliberate division of labor between both.

Practical Implications for Enterprise IT Strategy

For IT leaders, the rise of edge computing creates several concrete strategy questions:

1. Rethink IoT Device Roles

Most early IoT deployments treat smart devices as passive data collectors — sensors that ship raw telemetry to a cloud platform for processing. A more advanced model embeds lightweight analytics directly on the device. This enables faster local decision-making, reduces bandwidth costs, and improves resilience when connectivity is intermittent. Companies such as Greenwave (referenced in the original NetworkWorld analysis) have developed platforms designed to enable this kind of on-device analytics for manufacturers.

2. Treat the Browser as a Compute Platform

Web browsers have become increasingly powerful runtimes. Technologies such as WebAssembly (Wasm) allow near-native performance for code running inside a browser sandbox. Early edge computing companies like Instart Logic explored the idea of injecting virtualization components into the browser — giving content delivery platforms a foothold at the very last mile of the user’s session. While the specific vendor landscape has shifted since 2017, the architectural concept of distributing application logic into the browser remains relevant and has accelerated with modern Wasm-based edge runtimes.

3. Design Data Workflows for Multiple Compute Tiers

Architects should explicitly map each workload to the tier where it belongs: edge, regional, or central cloud. Key factors in that placement decision include:

• Latency requirements: Does the system need a sub-millisecond response? It belongs at the edge.
• Data volume: Does sending raw data to the cloud consume prohibitive bandwidth? Pre-process it locally.
• Compute intensity: Is the workload a large model training job? It belongs in a cloud environment with GPU availability and elastic scaling.
• Regulatory requirements: Must certain data remain on-premises or within a specific geography? Design accordingly.

4. Invest in Edge-Aware Security Models

Distributing compute across thousands of edge nodes dramatically expands the attack surface. Security controls — including firmware integrity verification, mutual TLS between edge and cloud, and zero-trust network access policies — must be applied consistently across every tier, not just the cloud perimeter.

The Broader Lesson: Continuous Architectural Evolution

The most important takeaway from Levine’s analysis is not that cloud is over. It is that enterprise IT architecture is not a destination — it is a continuous process of adaptation. The mainframe gave way to client-server. Client-server gave way to web-centric architectures. Web-centric architectures gave way to cloud-native design. Now cloud-native is being extended and complicated by edge compute requirements.

Each transition did not eliminate the previous paradigm entirely — mainframes still run banking cores, and on-premises infrastructure still underpins regulated industries. What changes is the center of gravity: where new workloads are designed to run by default, and where investment in tooling and talent is concentrated.

For DevOps teams, this means the operational scope is expanding. Pipelines must deploy not just to cloud Kubernetes clusters but to constrained edge runtimes. Observability stacks must aggregate telemetry from devices with limited connectivity. Configuration management must handle heterogeneous hardware at scale.

Key Takeaways

• Cloud computing is not being replaced — it is being complemented by edge compute tiers that handle latency-sensitive and bandwidth-intensive workloads locally.
• The autonomous vehicle is a useful mental model: massive local data generation, local real-time processing, selective cloud offload for training and analytics.
• IoT strategy must evolve beyond data collection toward on-device analytics and decision-making.
• Workload placement decisions should be driven by latency, data volume, compute intensity, and regulatory constraints.
• Security and observability must be designed across all compute tiers from day one.
• Architectural change in enterprise IT is constant; the organizations that build adaptive strategies outperform those that optimize for any single paradigm.