Open Source release of IoT app environment Calvin
Calvin is available now on Github.
Calvin is an application environment that lets things talk to things. It includes both a development framework for application developers, and a runtime environment for handling the running application.
Calvin is based on the fundamental idea that application development should be simple and fun. There should be no unnecessary barriers between an idea and its implementation. An app developer should not have to worry about communication protocols or hardware specifics (unless he or she wants to, of course).
Distributed cloud for IoT
In short, a distributed cloud for IoT is the ability to execute parts of the application code where it is most beneficial – for example in a central node when analyzing aggregated data from many sources, or close to specific hardware to achieve extremely low latency. It’s also possible to speed up processing by using parallel processing nodes.
Calvin is built upon the well-established actor model, using a methodology often referred to as dataflow programming.
What are the benefits of Calvin?
Calvin runtimes scale well; the basic functionality is simple enough to run on tiny IoT-devices, yet still utilize the full compute power available in the cloud.
Calvin’s programming model makes no distinction between cloud and device, smartphone and sensor, client and server; they are all represented by actors and share the same paradigm. When writing Calvin applications, there is no need to worry about exactly where to deploy it as long as the necessary hardware requirements are fulfilled. Development and deployment are separate concerns. Moving an application to another set of compute nodes does not require changing the code. Conversely, changes to the application do not prevent deployment to the same set of compute nodes.
Calvin actors can even do live migration from one runtime to another. The system accomplishes this by serializing the internal state of the moving actor, sending it to the target runtime where it is de-serialized and loaded into a copy of the moving actor. This property makes it possible to write applications that adapt to changing conditions. Thus, a runtime on a device that needs to go into sleep mode can move actors out of itself without interrupting the application(s) they are part of before sleeping.
What is the current implementation?
The reference Calvin implementation is written in Python and is available on Github. With time there will be leaner runtimes requiring less resources. The intention of the design is to even allow for micro controller based implementations.
Who will use it?
We envision all developers for the Internet of Things to embrace Calvin due to the simple programming model, the powerful communication and convenient deployment mechanisms that are built into the system. Complexities are hidden; the development becomes more efficient, the result is more robust, and there are fewer errors in the code.
We believe the initial uptake of Calvin will primarily take place in the embedded device space.
Why are you releasing this as Open Source?
It will simplify collaboration with academia as well as with industrial partners. Our objective is to get this into the hands of as many users as possible, so more talented programmers can contribute new features as well as bug fixes.
To build an eco-system around IoT it is crucial to have good tools available for developers that address their basic needs. Calvin is a good starting point for this, and with the help of an enthusiastic community it has the potential of becoming even better.
Will you continue to invest in the development of Calvin?
We will continue our work on Calvin. We believe that a programming model specifically designed for a distributed execution environment is fundamental to make the Internet-of-things really fly. Calvin is a very promising technology that addresses these needs.
How do you use it?
When building a Calvin application, the programmer uses pre-defined actors that perform certain tasks. Usually the task of an actor is to perform an operation on one or more streams of input data, and write the resulting stream to one or more output ports. The actors are easily connected and combined into larger program structures that together perform more complex tasks than the individual components. New actors can easily be constructed in order to interact with new hardware, or to add functionality missing from the existing collection of actors. By adding these to the library of actors they are ready to use by others as well.
With minimal programming efforts, Calvin devices can become an integrated part of completely separate applications—even at the same time. The runtime is capable of handling several actors concurrently that belongs to different applications. Consequently, the same device can differ with respect to how it reacts to events and stimuli as well as how it process and output data depending on what application it is part of.
Vendors of IoT hardware (e.g., sensors or actuators) can make their products Calvin ready by including a small runtime and/or a customized actor that exposes the device’s functionality through the well-defined message passing mechanisms that are offered within Calvin.
Usually it is cumbersome to write distributed applications that are to be deployed onto a heterogeneous set of hardware. Developers need to handle different types of communication, protocols and feature sets. The Calvin runtime effectively hides the complexity of connectivity and protocol adaptation; actors connect and talk in the same way regardless of how the underlying transport is carried out. Thus the Calvin developer can focus entirely on the functionality of the application, letting the system take care of the communication.
Existing hardware and services can be made accessible to Calvin applications through an intermediating proxy that handles the necessary protocol translation. When native device support is available, the proxy can be removed and the application will still run without changes.
In short, Calvin facilitates flexibility and adaptability when merging IoT and the cloud. It is distributed programming without the hassle, it is simplicity and reuse of functionality combined.
A live vizualizer of a small running Calvin application
How does Calvin relate to other app developer frameworks? Why would developers choose this one?
We have not seen any other framework that entirely takes our viewpoint on developing distributed applications for IoT. We provide a mechanism and methodology that puts focus on helping the application developer. Much of the complexity is hidden within the runtime; actor migration is automatically handled for you, communication and message passing is taken care of, and the lightweight API facilitates implementations on very resource limited hardware. Simplicity, reuse, flexibility and separation of concerns are all key parts of our design. We believe that this is the correct way of bringing things together and make them collaborate.
Can you say more about distributed cloud for IoT?
There are several reasons why the ability to execute code in different places is desirable. First of all, introducing a distributed execution environment simplifies the implementation of functionality for several classes of real-world problems. For instance, the scenarios envisioned for the Internet-of-things are inherently distributed as multiple connected devices are involved. Through “compartmentalization” and binding certain functionality of the distributed program to specific hardware nodes, one can, for example, get lower latency or prevent bandwidth bottlenecks. It is also possible to improve reliability or speed up processing time of critical program functionality through instantiation of parallel processing nodes.
There are different approaches to accomplish a distributed execution environment. In the actor model which Calvin is built upon, functional primitives, the “actors”, are connected in a network. Actors react to data that is received on their input ports, process it and write the result to their output ports. The network of actors constitutes a distributed application. It’s this methodology that is often referred to as dataflow programming.
