0x Crystal Technology
Developing a fault-tolerant fog application spanning over fog nodes requires high programming complexity and dealing with all the exceptions and failures, in- evitably leading to complicated application development process. To tackle these issues, the proposed fog computing framework Crystal provides an easy abstrac- tion for fog application development. The name Crystal is derived from ice fog, a type of fog composed of tiny ice crystals suspended in the air. Similarly, in Crystal framework, a fog application is composed of multiple components called Crystals spanning over fog nodes. Crystals are loosely-coupled components, each of which can run a standalone component, and they communicate each other through mes- sage passing. The functional definition of a Crystal component can vary from function-level to microservice-level depending on its roles in a fog application.
The proposed Crystal framework follows ’let it disappear’ philosophy to re- flect the inherently unreliable nature of fog where any node can leave and join at any moment. Whenever a fog node disappears from the fog by any reason, a fog application consisting of Crystals automatically heals by exploiting available fog and/or cloud nodes. Thus, developers can use Crystals as building blocks for fog applications without concerning failures of fog nodes. A fog application
using Crystals can take full advantage of location transparency, self-healing, auto- scaling and mobility support described below:
Crystal: 0xPlatform's Next-Generation Fog Computing Platform
Crystal components should be able to run on any node at any time. While the location of each Crystal instance may affect the overall performance of a fog application, it should not affect the context of the application. The concept of Crystal’s location transparency enables a fog application to be easily decomposed and deployed over a pool of fog nodes. Also, location transparency gives developers an illusion that a fog application development is more like a local application development.
Crystal components should embed a self-healing functionality to survive in fog environment. Fog’s highly unreliable and unpredictable nature imposes a significant burden on developers to deal with all the exception and error handlings. Crystal assumes that any node can fail at any moment in fog. In that sense, Crystal components keep monitoring and respawning each other for self- healing, rather than expecting developers to program an error-free fog application. A fog application can be presented as a directed acyclic graph according to the communication patterns of its Crystals. When a parent Crystal detects a failure from its child Crystal instance, it automatically re-creates it on another fog node. All of these procedures are transparent to the user application, and also to the user code.
Crystal components should automatically scale out and scale in when a Crystal instance is busy or idle, respectively. In case of a stateless Crystal instance, Crystals are seamlessly scaled out and scaled in by creating or killing replicated Crystal instances. Messages to the replicated Crystal instances are automatically load-balanced. In case of a stateful Crystal instance, its state is written to a distributed data store and accessed by replicated Crystal instances.
Crystal components should move from one fog node to another when migration is required. With Crystal’s mobility, a fog application consisting of Crystals can dynamically expand itself from things, to the fog, to the cloud, and also vice versa. When a Crystal instance of a fog application does not meet the minimum running requirements anymore (e.g., lack of resources, or location change), it finds an adequate fog node and migrates to the node. Crystals are responsible for delivering the messages designated to the migrated Crystal instance and it is transparent to the user code.