Calvin means business
Our open sourced Calvin environment is designed to simplify development of Internet-of-Things applications. But it also supports new business models. In this blog post we’ll outline how a micro-payment system might be implemented with Calvin.
It is simple to establish agreements between users, application developers, and service providers about how much to charge for application usage. This can be accomplished without the need for application developers to instrument the code in any way, and service providers do not have to examine the data or know anything about the operations performed on the data.
Micro-payments and subscription models
The software industry is moving away from up-front payments in favor of subscription or different pay-per-use models. Typical examples include the cloud service, or hosting provider, market with well known players, where almost any kind of infrastructure- or platform-as-a-service can be leased and paid for based exclusively on usage, including a free tier. This allows developers to scale up their system as their business grows, and not waste money and resources on unused capacity just to handle rare spikes in activity. However, the scaling is often done in bulk steps, when the customer hits the limit of the current level of machine performance, storage size, throughput, number of transactions, etc.
A better model would be a kind of micro-payment system, where each transaction, performed in the application, is associated with a certain price. The price tag would vary with complexity, resource allocation, business value of the transaction, or other relevant parameters. Some transactions could be free of charge, others, like recognizing a face in an image, could be priced at a few cents. All transactions together would then add up to a monthly bill.
The drawback of such a system is that it is a lot harder to implement than the discrete usage levels described previously.
Calvin provides a solution to this.
Calvin: Firings and bookkeeping
In Calvin, applications are defined as data flow graphs with actors, encapsulating functionality, reacting to incoming data in the form of tokens. Yyou can find detailed information in our earlier blog posts, and on the project’s home at Github. Incoming tokens cause actions to be performed in the actor, referred to as an actor firing.
One of the key features of the Calvin environment is that actors do not share their state with anyone or anything. At a first glance, this might seem like a problem if one would like to implement something like micro-payments or a charging system for Calvin applications, but in fact it is quite the contrary. What actors can supply to an external environment is fine grained information about what actor fired which action and when, the size and number of tokens consumed and produced, and the identity of the application it belongs to.
This meta-data does not require any knowledge of what the application does, what kind of data is being processed, and on behalf of whom the application is being run. This makes it possible to charge for the processing of sensitive data, without requiring access to neither the data nor the operations performed on it.
Another key feature of Calvin is that actors execute on runtimes, which means that wherever a Calvin application can run its constituent actors, be it on a device, a gateway, a network node, or a cloud server, someone has deployed a runtime. That someone could be the end user, an operator, or a cloud provider. By design, Calvin runtimes keep track of meta-data related to actors, and thus the owner of a runtime will have access to all the bookkeeping details required to charge for processing incurred by actors executing on that runtime.
Below is a figure that shows the principle.
The application is deployed on a runtime (RT) which is controlled by an operator. The developer agrees a price with the operator, based on some measurable use of the application. As mentioned previously, this can be basically anything. For instance, pricing can be based on number or frequency of firing a certain action within a specific actor, the number of tokens sent from actor C to actor D, the time instances when actor A is used combined with the amount of data it sends to actor B, and much more. The runtime keeps track of this meta-data, making it possible for the operator to charge the user of the application.
A Concrete case
Let’s turn to an example to illustrate how Calvin could be used to implement pay-as-you-go services.
Consider a conventional application; an access control system similar to the example in the blogpost “A closer look at Calvin” where a surveillance camera is monitoring access to a building. Whenever someone attempts to enter the premises, an image of that person is sent to an actor performing face recognition and depending on the outcome of the face recognition action will open a door (or keep it locked).
In the first stages of processing a face detection actor is used to select images for further processing. This is a fairly simple operation that is likely running on the camera. If a face is detected, it is sent to the face recognition actor which is a much more complex task best run somewhere in the cloud. Finally, if the face recognition turns up favorably (for the person trying to enter the building) a signal is sent to unlock the door.
Let us examine the face recognition service first. The service provider sells the service “Does this face belong to someone in your employee database?”, charging a fixed (small) amount for each image of a face it examines. This is not entirely different from an ordinary cloud service, save for the pricing model. The really interesting things happen when we look at the surveillance camera and the door. The surveillance camera is run by its manufacturer, and the door is run by the facility management operator. Both items are owned, installed, and maintained by 3rd parties, and carries no fixed cost; instead the user of the system is charged a small fee for every image passed from the camera to the face recognition service, and every time the door is unlocked. The application developer could also be paid based on application usage, i.e. the number of access attempts, successful or not.
The problem here is of course to manage the financial transactions. Even for this small application, there are five parties involved: the application developer/system integrator, the user of the system, the surveillance camera manufacturer, the cloud service provider, and, of course, the owner of the door. That is where we see a case for Calvin runtime operators: Someone who supplies and manages runtimes, coordinates legal agreements and financial transactions between the players, and truly makes Anything-as-a-Service a reality.