In this section you will find a brief description of the main terms used in the platform. Please make sure you learn this glossary to fully understand our documentation.
|Application (or Product)||a web-based (or MS Windows desktop) software product which can be sold in the Cloudesire Marketplace|
|Vendor||a user that offers his applications in the Cloudesire Marketplace|
|Application Version (or Product Version, or Plan)||for each application, the vendor can define one or more versions (e.g. silver, gold, platinum, etc.). Each version can have a specific recurrent license and/or a one-off setup price or can be offered for free. In addition, the vendor can specify custom metrics for his applications (eg. number of users, number of documents, etc.) specifying the related unit price; in this way, pay-per-use pricing models can be defined (eg. 10 USD per active user, 20 USD per document, etc.). Finally, the vendor can sell extra-resources together with the application version (eg. a 10-days pack of Technical Support, some hardware components, etc.)|
|Customer||a user that buys applications in the Cloudesire Marketplace|
|Order||when a customer buys an application, Cloudesire creates an order that contains the following information: duration (eg. 1 year, 6 months, etc.), nominee (the customer name), purchased application name, order type (can be normal, trial, sandbox, upgrade, renewal), total amount|
|Subscription||each order, Cloudesire creates a subscription that has a specific lifetime, depending on the order duration. In the case of renewal of a subscription, a new order is created (“renewal order”).|
|Invoice||during the subscription lifetime, Cloudesire issues a certain number of invoices to the customers, depending on the Billing Period (eg. every month, every 3 months, etc.). The Billing Period can be defined by the vendor for each application version.|
|Balance Report||a statement that is periodically provided to the vendor, containing a summary of all the revenues generated by the sales of his applications in a certain period of time (greater than the Billing Period). The revenues corresponds to the total amount of the applications licenses sold plus the pay-per-use application metrics revenues, minus the ClouDesire fee.|
2.Users, Functionalities & Permissions
In the following table are listed the all user levels supported by the platform, together with the correspondent (main) functionalities available for each of them.
|Super-Admin (platform administrator)||Admin (marketplace administrator)||Supervisor||Vendor||Distributor||Reseller||Customer|
|Cloud Providers: technical configuration||☑|
|Cloud Providers: pricing configuration||☑||☑|
|Sandboxing (provisioning simulation)||☑||☑||☑|
|Vendor Registration Review & Approval||☑||☑||☑|
|Product Onboarding Review & Approval||☑||☑||☑|
|Wholesale Product Pricing Configuration||☑||☑||☑|
|Sell-in Product Pricing Configuration||☑||☑||☑|
|Sell-out Product Pricing Configuration||☑||☑||☑|
|Extra-Resources & VAS Management||☑||☑||☑||☑|
In this section you can find a short description of the main Cloudesire modules. Modules include Cloudesire Engine, Back-Office and Marketplace.
The main components can be summarized as follows:
- Cloudesire Engine: it represents the “core” of the platform and consists in a set of multithread modules that uses messaging queues to enable asynchronous, distributed and redundant messaging among components, allowing enterprise integration patterns. Each modules expose a RESTful API layer that is used by the others and by the front-end interfaces (Marketplace and Back-Office).
- Cloudesire Back-Office: a responsive web application that allows users to manage different entities, according to their role: customers can see their orders status and check availability of their instances; vendors can manage their application catalogue, active customers, orders and running instances of their applications; administrator can manage the entire platform and receive updates from the monitoring and alerting systems.
- Cloudesire Marketplace: a responsive web application where a software vendor can publish its own applications, along with others vendors apps. Customers can browse the catalogue, compare products, rate and comment them, place orders or try an application (if the vendor allows it).
Cloudesire Engine contains:
- Cloud Abstraction Layer: a set of connection drivers, used to interact with private or public cloud providers APIs. It provides both heterogeneous hypervisors support (KVM, Xen, vmware) and public cloud connectors (see the list here).
- Cloudesire Deployer: it is used to create a new cloud instance for each purchased application, to instantiate the required virtual resources and to monitor step-by-step the deployment status: if something goes wrong, it will retry until success. The deployment process is described here.
- Cloudesire Monitoring: it consists in a scalable repository of system and application metrics that also provides aggregated real-time statistics and graphs.
- Cloudesire Backupper: it allows to backup and restore applications data using the cloud provider snapshots & restore APIs.
- Cloudesire Agent: a software component that is running inside every virtual environment created by the Cloudesire Deployer. It collects both the IaaS metrics (i.e. CPU, Network, RAM, SSD usage) and application custom-defined metrics (i.e. number of active users, numbers of created documents, etc.). If the ISVs application exposes them, custom metrics can be used to monitor application usage and enable pay-per use pricing models.
- Cloudesire DNS: provides the remote access of the applications and a custom application endpoint for each deployed instance.
Understand the Billing Module
Cloudesire provides a complete billing/invoicing/payments engine. This means that the marketplace can manage the entire process. This section will explain some main concepts of the billing/invoicing/payment process and will show some practical implemented use-cases.
Before you read this section, please take a look to the glossary to make sure you fully understand the terms that will be used in the following paragraphs.
Each Cloudesire invoice contains the following items:
- nominee: the customer name
- description: purchased application name
- setup costs: optional application one-off setup cost
- total: application recurrent licensing cost
- pay-per-use application metrics costs: specifying a unit-price for a custom metric allows Cloudesire to calculate the related incomes in a certain period of time (billing period) and issue an invoice to the customer. eg. 1.000,00 USD for 10 active users in the previous billing period
- extra-resources costs: Cloudesire supports 3 different pricing models for “extra-resources”, based on quantity usages. eg. 10 days of Technical Support, 5 hardware components to be used together with the application, etc.
- IaaS costs: VM instance, bandwidth, disk space
In the following screenshots, you can see some examples of invoices issued by Cloudesire:
These are the main billing rules followed by the platform:
- application licensing costs: at the beginning of each billing period (eg. the first day of each month) all the invoices containing the application licensing costs and the IaaS costs are issued in advance to customers at the beginning of each billing period (eg. the first day of each month). The one-off application setup cost is charged only in the first billing period;
- pay-per-use and extra resources costs: invoices containing the pay-per-use application metrics and extra-resources costs are issued to customers at the end of the billing period (eg. the last day of every month) ;
- trial orders: if an application is offered in trial mode, when customers use (try) it, Cloudesire issues an invoice to the vendor for the related IaaS costs. These costs are subtracted from the vendors’ revenues in the Balance Report;
- sandbox orders: when the vendor executes a deployment test before offering his application in the Marketplace (sandbox), Cloudesire issues an invoice for the related IaaS costs. Again, these costs are subtracted from the vendor’s revenues in the Balance Report.
Level of Configurability
- billing frequency: vendors can decide the preferred billing frequency (in months), for a every specific application version The billing frequency can also be short-living: in this case, the duration needs to be expressed in hours instead of months.
- minimum order duration: vendors can decide the minimum order duration for each application version. The minimum order duration is a multiple of the billing frequency.
- order duration: before purchasing an application, customers can choose the preferred order duration (which is a multiple of the minimum order duration). If the platform is configured to run using automatic renewals of orders, customers are not asked to choose the order duration.
Extra-Resources pricing models
Cloudesire supports 3 different pricing models for “extra-resources”, based on quantity usages: tiered scheme, volume scheme and stairstep scheme..
Tiered scheme means that every unit charge is calculated with its own tier price.
With tiered pricing, once you fill up a ‘tier’ you move to the next tier and start charging a different price.
Tiered pricing is different from volume pricing because tiered pricing defines a price per unit withing a range, while volume pricing defines a price for all units within a range.
- From 1 to 9 users: €5/user
- From 10 users: €3/user
Quantity bought 15 users, total amount: 9 * € 5,00 + 6 * € 3,00 = € 63,00
Volume scheme means that all units charge is calculated based on total count in the related tier.
Therefore, as soon as you hit a particular number, all units will cost the lower price.
Tiered pricing is different from volume pricing because tiered pricing defines a price per unit within a range, while volume pricing defines a price for all units within a range.
- From 1 to 9 users: €5/user
- From 10 users: €3/user
Quantity bought 15 users, total amount: 15 units * € 3,00 = € 45,00
Stairstep scheme means that the total cost is calculated based on price tier; charge is not per unit.
Therefore, vendors will propose different unit prices for various quantities of an item.
- From 1 to 9 users: €30
- From 10 users: €100
Quantity bought 15 users, total amount: € 100,00
The following screenshot shows an example of Extra Resources linked to a specific Product Plan.
Detailed instructions, explaining how to specify and manage Extra Resources during the onboading process, are provided in this section.
Cloudesire can manage orders with automatic renewal. In this case, when a subscription is about to exipre, the platform automatically issues a new invoice to the customer for the next billing period; then – if the customer previously decided to let the marketplace store his credit card data – Cloudesire contextually charges the customer.
If automatic renewal is disabled:
- a few days before the subscription expiration, Cloudesire notifies the customer to remind the expiration and creates an invoice that the customer needs to pay to use the application after the subscription expiration
- if the customer doesn’t renew his subscription (i.e. doesn’t pay the related invoice), Cloudesire stops (or better suspends) the related application’s instance and waits some days (the precise number is configurable in the platform) for the payment. If after this period the customer doesn’t pay the invoice, Cloudesire destroys the application instance and the customer will no longer be able to access the application.
System Administrators, Vendors and Resellers can generate a number of coupons for each given application version (plan).
Each coupon will have a unique hashcode and a period of validity. The hashcode is what customers need to enter in the coupon field to redeem the coupon when purchasing an application.
It’s possible to specify the e-mail address of a specific user and send the coupon only to him. If the coupon is created for a specific user, the platform sends him a communication containing the coupon. It’s also possible to distribute coupons outside the platform: users only need to know the hashcode to redeem the coupon.
Cloudesire allows to generate 2 types of coupons:
- discount: when the customer uses this kind of coupon, a discount is applied to the application price;
- fixed price: when the customer uses this kind of coupon, a fixed price (usually lower) overrides the original one for the given application version (plan). A typical use case is: the vendor doesn’t want to publish a public price for the application and wants to choose a different price for each customer.
Coupons can be:
- “one-time only”, meaning that each coupon can only be used one time and is not reusable (even if it is transferable from one customer to another)
- “reusable“, meaning that each coupon can be used more times (until its expiration date)
Furthermore, Cloudesire supports an additional type of coupon:
- extended trials: when the customer uses this kind of coupon, the default trial period length (e.g. 10 days) will be replaced with the one specified in the coupon (e.g. 30 days). A coupon of this type remains valid for all the customers receiving this coupon code. This rule does not override the general rule “only one trial for each product for each customer”. For each extended trials coupon, the system administrator can allocate a budget (or plafond) which will be decreased – by a certain amount – every time it will be used by a customer.
Cloudesire allows System Administrators, Vendors, Distributors and Resellers to create bundles as a composition of 2 or more products.
Of course a Vendor can only create bundles containing products belonging to his own catalog (the same for the Distributors and Resellers).
Each bundle plan is defined as a composition of products plans. Using a simple interface it’s possible to specify – for each of them – a discount percentage; in this way, the total price of a bundle plan is calculated as the sum of all the discounted prices of all the products plans “attached” to it.
On the Marketplace, a bundle is shown as a normal product, highlighting the discounts, while in the ordering page the customer can have a detailed view of all the prices and the savings.
Prepaid Bandwidth Management
- vendors can specify a certain amount of prepaid bandwidth for each application they sell in the Cloudesire Marketplace
- Cloudesire manages the bandwidth price for each supported cloud provider
- if the vendor doesn’t set a specific prepaid bandwidth amount to his application, Cloudesire associates a default prepaid bandwidth package (eg. 10GB)
- during the deployed application lifetime, if the bandwidth usage exceeds the 90% of the established limit, Cloudesire sends an e-mail notification to the customer, asking for a bandwidth upgrade order. If the customer doesn’t execute the upgrade, Cloudesire prevents access to the application.
Disk Space Management
- vendors can specify a certain amount of disk space for each application they sell in the Cloudesire Marketplace
- Cloudesire manages the disk space price for each supported cloud provider
- during the deployed application lifetime, if disk space usage exceeds 90% of the established limit, Cloudesire sends a notification email to the customer, asking for a disk upgrade order.
- Cloudesire allows the customers to buy backup plans.
- every backup plan includes to a maximum number of backups executions (configurable in the platform) that can be manually performed by the customers or scheduled
- a backup plan must be paid by the customer in advance
- if the customer needs to perform a manual backup when the maximum limit in the backup plan is reached, a new backup order is created and a related invoice is issued. In this case, the backup starts only when the invoice is paid.
- to date, the supported payment gateway are PayPal and Stripe
- after the sale of an application, when the customer pays the related invoice, Cloudesire automatically starts the application deployment process on the selected cloud provider
- if a problem occurs during the interaction with the payment gateway, Cloudesire allows the platform administrator to manually set an invoice as “paid” (in order to start the deployment process). This feature can be also useful to manage bank transfer payments (in this case, when the administrator sets an invoice as “paid” he can provide the deposit slip data using a specific input field)
In some particular business scenarios it should be useful to to let some vendors to issue invoices from themselves, without using the Cloudesire billing engine.
The platform allows the admins to mark a specific product / plan as “self-billed”.
In this case, when the user purchases a product, the platform “begins” the provisioning and doesn’t ask the customer to pay anything.
The real provisioning starts only when the vendor clicks on a specific button on the control panel for “declaring” (and taking the responsibility) that the “invoice is paid” and the application can really be provisioned to the end-user.
The platform logs that the vendor should pay the fee back to the platform owner.
The same functionality is also available for the resellers.
A reseller can can mark a sell-out price as “self-billed” for exposing the related product into his reseller-marketplace without enabling the payment functionalities on it.
3.3.Application Provisioning Module
Understand the deployment process
The deployment process on a specific cloud provider follows this workflow:
- Cloudesire calls a cloud provider chosen by the vendor asking for a VM instantiation (through the cloud provider APIs), having a specific “size” defined by the vendor (i.e. 2 cores, 1GB RAM)
- Cloudesire attaches a data disk to the previously created VM, having the size defined by the vendor
- Cloudesire installs all the application stack (databases, application servers, interpreters, libraries, etc.) needed by the vendor’s application for the correct execution (the application stack is declared by the vendor in the onboarding process)
- Cloudesire installs the vendor’s application and initializes the related databases into the VM deployed during the steps above mentioned
- Cloudesire creates a specific DNS entry in order to make the application reachable by the customer (e.g. https://application_name-order_id.apps.cloudesire.com)
- the end user (customer of the given application) receives a notification (via email and in its own control panel interface) with all the instructions needed to access its own instance of the application he paid for (URL, default login and password)
The deployment process of legacy applications (i.e. MS Windows desktop executables) that doesn’t have an automatic and unattended setup follows a different workflow: in this scenario, a pre-configured windows VM template is cloned by Cloudesire for each order. On the opposite, if the Windows desktop application provides an unattended setup, Cloudesire can follow all the previously described workflow, but the URL provided to the customer refers to a remote desktop connection (i.e. VNC, rdesktop)
Understand the Backupper Module
Cloudesire Backupper Module allows customers and/or vendors to execute or schedule applications data backups.
How the Backupper Module works
During the deployment process, Cloudesire attaches a data-disk to the previously created VM in which application source code and data (i.e. databases and uploads) are stored.
The backup process follows the following workflow:
- VM shutdown
- data disk snapshot execution (using the cloud provider APIs)
- VM restart
The restore process follows the following workflow:
- VM shutdown
- data-disk detachment and replacement with the previously stored snapshot (using the cloud provider APIs)
- VM restart
During these processes, deployed applications are not accessible (the downtime duration depends on the cloud provider execution time for snapshots/restore operations).
To avoid this, we are working on a new release of the Backupper Module that will attach a new data-disk to the VM before to start the backup/restore processes.
Before starting a backup, all the application data will be copied to this new disk, on which the snapshot will be subsequently executed. In this way, the application will be accessible during the snapshot creation and no shutdown of the VM will be required.
In the same way, the snapshot restore operation will be executed on this new disk, and once it is ready the two disks will be switched. In this way, the application will be accessible during the snapshot restoring and no shutdown of the VM will be required.