Applications

Create an Application

An Application is composed of one or more Services. The number of services will depend on your application architecture. For example some 3-tier applications may have a few services, or even a single service, where as Microservices style applications may have hundreds of services.

To create an Application, you will need to provide a name, for the application, and an optional description. You can now add services to your application. See:

You can also define dependencies between applications. If Application A depends on Application B then services from Application A can talk to services from Application B. You can control precisely which of the services can communicate with each other by specifying an Application Routing Policy. Defining dependencies between applications can be usefull when sharing common services such as a database between multiple applications.

Service Affinities

Service Affinity rules are used to manage how services are placed, in relation to other services. Multiple affinity rules can be defined for each application. They define if services must be grouped together on the same host or if they must be deployed on separate hosts. Affinity rules are optional. When there is no affinity rule specified, services are placed on host solely based on the placement type specified in the resource selection policy. There are three affinity types supported:

Affinity Type Description
Same Host Services must be placed on the same host. The selected host can be shared with other services.
Unique Host Services must be placed on the same host. The selected host cannot be shared with other services
Different Hosts Services must be placed on different hosts. The selected hosts can be shared with other services

Affinity rules take precedence over the placement type specified in a resource selection rule. A given service can only appear in one rule of type “Same Host” or “Unique host”.

Creating Affinity rules

To create an affinity rule, select the application to which the rule applies, the list of services, the list of environment types applicable for this rule and finally the affinity type.

_images/create-affinity-rule.png

Updating Affinity rules

Affinity rules can be updated after being created. The new definition for a rule will take effect only when a new environment is created or when an existing environment is scaled up.

_images/edit-affinity-rule.png

Affinity rules Example

_images/affinity-rules-example.png

In this example, the first rule specifies that deals, ratings, wishlist and loyalty services must alway be placed on the same host when the application is deployed in a staging environment or in a production environment.

The second rule specifies that payment, orders and customer services must be placed on the same host when the application is deployed in a staging environment or in a production environment.

The third and fourth rules specify that the shopme-gateway services should never be placed on the host running either the deals service or the payment service.

Finally the fifth rule specifies that when the application is deployed in a sandbox environment, all services must be placed on the same host.

Scaling & Recovery

Scaling rules manage how many instances of each service should be deployed in an environment, and if auto-recovery is enabled for the services.

Service scaling rules can be specified when an environment is created or directly as part of the blueprint of an application. When added to an application blueprint, scaling rules are used as the default scaling rules when creating new environments. A scaling rule specifies the number of service instances to be deployed. The system will guarantee that the desired number of service instances is running at all time. If a service instance dies or is shutdown by a user, the system will automatically restart a new one.

_images/create-scaling-rule.png

In this example, the scaling rules specifies that when the application is deployed in a production environment, the wishlist and the catalog services must be deployed with three service instances each.

Service Routing

By default, an Application has one routing policy defining how the application services can communicate with each other. In the example below we specified that all the services from the shopme application can talk to each other except for the orders service which cannot communicate with the ratings service:

_images/application-routing-policy-1.png

If your application dependes on other application, then one Routing Policy per required Application is added to your application definition. In the example below, the shope application depends on MongoDB and ElasticSearch. The shopme application has a total of three Routing Policies: one for its own services, one controlling the communication between the shopme application and the Elasticsearch cluster and another one defining the communication between shopme and MongoDB.

We show in this picture the details of the Shopme/Elasticsearch Routing Policy. None of the shopme application services can talk to elasticsearch, except for orders and custtomers:

_images/application-routing-policy-2.png

Import or Export an Application

You can export an application blueprint as a JSON file. This file can then be shared, versioned, or archived in any tool of your choice:

_images/export-application.png

You can also import a previously exported application blueprint.