CloudML allows developers to model the provisioning and deployment of a multi-cloud application. CloudML is also inspired by component-based approaches in order to facilitate separation of concerns and reusability. In this respect, deployment models can be regarded as assemblies of components exposing ports, and bindings between these ports.


In this tutorial we will exploit the CloudML JSON syntax to specify a very simple deployment model. The objective is the following: specify the deployment of MongoDB on a small virtual machine. Fill the blank parts in the code snippets below!


A CloudMLModel consists of CloudMLElements, which can be associated with Property and Resources. A Resource represents an artefact (e.g., scripts, binaries, configuration files, etc.) adopted to manage the deployment life-cycle (e.g., download, configure, install, start, and stop). The three main types of CloudMLElements are Component, Communication, and Hosting.


You can specify the set of cloud providers you have access to in the list of Providers. In order to get access to the provider's API a file containing your credentials has to be defined and the path to this file specify in the credentials attribute. For specific cloud providers, the API's endpoint must be specified as a property attached to the provider definition. This is for instance the case for private instances of Openstack.
"providers" : [{
  "eClass" : "net.cloudml.core:Provider",
  "name" : "openstack-nova",
  "credentials" : "credentialsOpenstack",
  "properties" : [{
      "eClass" : "net.cloudml.core:Property",
      "name" : "endPoint",
      "value" : ""


A Component can be an ExternalComponent, meaning that it is managed by an external Provider (typically a PaaS, e.g., an Amazon Beanstalk container), or an InternalComponent, meaning that it is managed by CloudML.

Internal Component, type and instance

The following code snippet is used to specify a type of internal component called mongoDB. This component requires and execution platform, which, in this case, is simply an operating system. A resource is attached to this component type describing how to manage its life-cycle. A resource is typically composed of a set of commands, one for each state of the life cycle. Accordingly the possible commands are: uploadCommand, downloadCommand, installCommand, configureCommand, startCommand, stopCommand.
"internalComponents" : [{
  "eClass" : "net.cloudml.core:InternalComponent",
  "name" : "mongoDB",
  "resources" : [{
      "eClass" : "net.cloudml.core:Resource",
      "name" : "no name",
      "downloadCommand" : "wget -P ~",
      "installCommand" : "cd ~; sudo bash",
      "requireCredentials" : false,
      "executeLocally" : false
  "requiredExecutionPlatform" : {
    "eClass" : "net.cloudml.core:RequiredExecutionPlatform",
    "name" : "sl",
    "owner" : "internalComponents[mongoDB]",
    "demands" : [{
        "eClass" : "net.cloudml.core:Property",
        "name" : "OS",
        "value" : "Ubuntu"
Instances of component can be created from a component type. In the following we specify an instance called mongoDB1 of type mongoDB.
"internalComponentInstances" : [{
  "eClass" : "net.cloudml.core:InternalComponentInstance",
  "name" : "mongoDB1",
  "type" : "internalComponents[]",
  "requiredExecutionPlatformInstance" : {
    "eClass" : "net.cloudml.core:RequiredExecutionPlatformInstance",
    "name" : "sl948010596",
    "owner" : "internalComponentInstances[mongoDB1]",
    "type" : "internalComponents[mongoDB]/requiredExecutionPlatform[sl]"

External Component, type and instance

An ExternalComponent can be a VM (e.g., a VM running GNU-Linux) or a PaaS service. The properties minCores, maxCores, minRam, maxRam, minStorage, and maxStorage represent the lower and upper bounds of virtual compute cores, RAM, and storage, respectively, of the required VM (e.g., minCores=1, minRam=' 1024). The property sshKey represents the name of the SSH stored on the provider side and that will be used when the VM is created to enable connections using the correspondig privateKey. The property privateKey specifies the path to this privateKey.
"vms" : [{
  "eClass" : "net.cloudml.core:VM",
  "name" : "SL",
  "minRam" : "",
  "Region" : "",
  "minCores" : "",
  "minStorage" : "",
  "is64os" : true,
  "imageId" : "",
  "securityGroup" : "",
  "sshKey" : "",
  "groupName" : "sensapp",
  "provider" : "providers[openstack-nova]",
  "privateKey" : "",
  "providedExecutionPlatforms" : [{
      "eClass" : "net.cloudml.core:ProvidedExecutionPlatform",
      "name" : "s1Provided",
      "owner" : "vms[SL]",
      "offers" : [{
          "eClass" : "net.cloudml.core:Property",
          "name" : "OS",
          "value" : "Ubuntu"
In the following we specify an instance of VM called sensapp-sl1 of type SL.
"vmInstances" : [{
  "eClass" : "net.cloudml.core:VMInstance",
  "name" : "sensapp-sl1",
  "type" : "vms[SL]",
  "providedExecutionPlatformInstances" : [{
      "eClass" : "net.cloudml.core:ProvidedExecutionPlatformInstance",
      "name" : "s1Provided1309488529",
      "owner" : "vmInstances[sensapp-sl1]",
      "type" : "vms[SL]/providedExecutionPlatforms[s1Provided]"

Execute instances

A HostingPort represents a hosting interface of a component. A HostingPort can be a ProvidedHost, meaning that it provides hosting facilities (i.e., it provides an execution environment) to another component, or a RequiredHost, meaning that an internal component requires hosting from another component.
"executesInstances" : [{
  "eClass" : "net.cloudml.core:ExecuteInstance",
  "name" : "runOn1202166832",
  "providedExecutionPlatformInstance" : "vmInstances[]/providedExecutionPlatformInstances[s1Provided1309488529]",
  "requiredExecutionPlatformInstance" : "internalComponentInstances[]/requiredExecutionPlatformInstance[sl948010596]"

Generate your model!

You can now test it using the CloudML web editor!