Dew Computing

What Is Dew Computing?

Dew computing is an on-premises computing paradigm in which a local device provides full, self-contained functionality that operates independently of cloud services while remaining capable of synchronizing with those services whenever a network connection is available. The term was coined to complement the existing cloud/fog/edge hierarchy by giving a name to the specific combination of local independence and cloud collaboration. Where cloud computing places computation and storage on remote servers accessible over the Internet, and fog computing places compute resources at network edge nodes, dew computing assigns a substantial functional role to the end device itself. The concept was formally introduced and analyzed in IEEE Xplore in an introductory paper on dew computing that established its two-property definition.

The motivation for dew computing arises from a recognized gap in cloud-dependent architectures: when network connectivity is interrupted, purely cloud-dependent applications become unavailable or lose data. Dew computing addresses this by requiring that the on-premises component store a complete or near-complete local copy of its working data and run locally the logic needed to serve users. Synchronization with the cloud master copy resumes automatically when connectivity is restored.

Local Independence

The independence property of dew computing requires that the on-premises device be able to perform its full intended function without any active connection to external services. This goes beyond simple offline caching: a dew-compliant application must provide the same functional surface to users regardless of whether the Internet is reachable. In practice, this means the local device runs a server process, often called the dew server, that hosts both the application logic and a local copy of the data. Users interact with the local dew server through the same interface they would use to reach a cloud service, making the underlying topology transparent. Formal descriptions of this architecture are detailed in work published through dewcomputing.org research publications.

Cloud Collaboration and Synchronization

The collaboration property requires that the dew computing application exchange data with cloud services automatically and bidirectionally when a connection is available. This creates a dew-cloud architecture in which the local dew server holds a working replica and the cloud holds the authoritative master. Conflict resolution policies govern what happens when both endpoints have accepted writes during a disconnected interval, a problem shared with distributed database replication. The synchronization layer must handle version conflicts, deletion semantics, and partial update ordering to converge both replicas to a consistent state. This architecture extends the traditional client-server model by placing a capable server at the client end of the link rather than treating the client as a thin, dependent terminal.

Relationship to Cloud and Edge Architectures

Dew computing occupies a distinct position in the computing topology hierarchy. Cloud computing handles large-scale, shared computation and persistent storage. Edge and fog computing place compute closer to the data source to reduce latency and backhaul bandwidth. Dew computing focuses specifically on the end device, asserting that the device itself should be a first-class server, not merely a display and input terminal. The three layers are complementary: a dew-capable device can function alone, use a local edge node for low-latency coordination with nearby devices, and synchronize with the cloud for durability and remote access. A discussion of how dew computing complements the cloud tier appears in Wang's categorization of dew computing.

Applications

Dew computing has applications in a wide range of disciplines, including:

  • Personal productivity software that must function during intermittent connectivity
  • Healthcare systems in remote or disaster-affected areas where Internet access is unreliable
  • Industrial monitoring where local processing must continue during network outages
  • Distributed collaboration platforms that require consistent local performance regardless of network state
Loading…