How the Apprenda Platform Deploys Your Application

This section discusses at a deeper level how Apprenda deploys your application onto the servers that constitute your Apprenda environment. This topic does not discuss how to take advantage of an Apprenda feature or otherwise program your application, but rather provides a deeper knowledge of how the application will ultimately be deployed on the grid. 

A thorough understanding of the Getting Started section is recommended prior to reading this topic.

Introduction to the Deployment Process

Recall from the Application Fundamentals section that an Apprenda application consists of a specifically-structured ZIP file. The structure determines the tiers (user interface, .NET web service, Java Web Application, or database) to which each application component belongs. 

Apprenda, partly during upload and partly during publishing, will parse this structure to extract the various component tiers of your application and will statically analyze both the binaries and configuration of each to discover how your application components are related to one another. Apprenda creates a metadata map of your application that describes how the different tiers and components within tiers relate to one another. This map is useful to Apprenda in many different scenarios, including deployment and execution.

Once your application is uploaded, parsed, and mapped, Apprenda copies all files that make up your archive to the Platform Repository. The Platform Repository is a centralized location (typically configured during installation as a network path or share) that Apprenda uses to manage both application and node file assets. Once your application has been uploaded, you can promote the application to the Sandbox or Published stages via the Developer Portal, causing the items included with your application to be deployed onto the various servers making up your grid instance. 

The deployment process occurs in a matter of minutes, but the workflow that results in the safe and successful deployment of your application is quite complex. Apprenda deploys the actual components of your application to servers that are profiled to support that sort of tier in a location- and instance-transparent fashion. For example, your database will only be installed on a database server node, and the Platform will supply the necessary configuration information for the database so that user interfaces and web services (or Java Web Applications) may communicate with it.

How Apprenda Chooses a Server for Deployment

Apprenda deploys the actual components of your application to servers that are profiled to support that sort of tier in a location- and instance-transparent fashion. Among the servers that can support the component type, the Platform then filters potential deployment targets based on the following (in the order listed):  

  1. Required CPU and/or Memory (if Resource Throttling is Enabled)

If the Platform Operator has enabled Resource Throttling, the Resource Policy assigned to the specific application component is taken into account. In this case, the Platform calculates for each eligible server the number of slots available on each server. The number of CPU slots is calculated by taking the server’s total CPU capacity (CPU speed x Number of Cores), multiplying it by the allocation factor, subtracting the allocated CPU (based on the Resource Policies in effect for previously deployed instances), and dividing the amount into the CPU required by the component’s assigned Resource Policy. The same calculation is used to calculate the number of memory slots.

If no slots of either memory or CPU are available on any given server, it is removed from the list of potential deployment targets. If no servers are able to deploy the component instance, no deployment will occur and an appropriate error will be logged. 

If the Resource Policy assigned to the component is unlimited, or if Resource Throttling is disabled, no calculation is conducted; available memory and CPU slots will not be taken into account when considering deployment hosts.

  1. Cloud Affinity

On a Platform with more than one Cloud, Cloud Affinity may be set for an application. If set, all hosts that do not reside on the selected cloud will be filtered out of the list of potential target hosts.

  1. Application Deployment Policies

The Platform Operator may set one more Application Deployment Policies that may narrow down the list of potential target hosts. Deployment policies can be configured so that they “must” be enforced or so that they “should” be enforced. If there are no hosts that fit the conditions for a “must” policy, workload deployment will not occur. For “should” policies, the Platform will select a host that fits the policy if it exists, but will deploy to a host that does not fit the policy if no match can be found. It should be noted that the Platform will apply all “must” policies and then attempt to apply all “should” policies (in the order in which they are listed in on the Application Deployment Policy page in the SOC).

  1. Distribution Strategy (if Resource Throttling is Enabled)

Of the remaining potential deployment targets, if Resource Throttling is Enabled a target is chosen depending on the Distribution Strategy selected by the Platform Operator:

  • Balanced by CPU: The server with the most CPU slots available is chosen for deployment
  • Balanced by Memory: The server with the most memory slots available is chosen for deployment
  • Compressed by CPU: The server with the fewest CPU slots available is chosen for deployment
  • Compressed by Memory: The server with the fewest memory slots available is chosen for deployment

If the Resource Policy assigned to the component is unlimited, or if Resource Throttling is disabled, new workloads are deployed to a randomly selected qualified server (Apprenda chooses from among available web servers for UI instances, application servers for .NET WCF service instances, and Linux servers for Java Web Application instances).  For .NET UI components, and Java Web Application components, only one instance of a specific component can be deployed to a given server, so all servers already hosting a deployed instance of a component will be ruled out when Apprenda attempts to deploy a new instance of that component.  For .NET WCF service  components, however, a given server can host multiple deployed instances of a single component, so the number of and type of pre-existing instances on each server is not considered. 

How the Apprenda Platform Deploys Multi-Tenant Applications

The way in which Apprenda deploys applications to the servers that make up your infrastructure is rather complex, but permits many applications offered by multiple Development Teams to co-exist on the same set of servers in a safe and reliable fashion. In addition to all this, the Platform offers a variety of options for multi-tenant deployments. In Apprenda this means that an application that is intended to work for a single organizational unit can actually be deployed in such a manner that it can be used by many Organizations, or Tenants. Furthermore, the Platform can deploy the components that make up an application so that they are shared by the same Tenant.

Key Differences in the Deployment Process

The deployment process is generally the same for multi-tenant applications as it is for single-tenant applications, but user interfaces, Java Web Applications, and databases are provisioned and deployed differently depending on if and how a given Development Team wants them to be shared between multiple Tenants (e.g., should all Tenants share the same database?).

Before we dive into the specifics, we will first formally introduce the sharing features and terminology.

User interfaces, Java Web Applications, and databases are deployed in either an Isolated or Commingled fashion:

  • Isolated: Each Tenant has their own distinct user interface/Java Web App process and/or database partition
  • Commingled: All Tenants share the same deployed user interface/Java Web App process and/or database partition

Note that .NET services are always deployed in a Commingled manner by the Platform.

Scaling and High Availability

As you already know, Apprenda is capable of scaling application components, and this is still the case with multi-tenant applications. When Apprenda deploys your application’s components in a multi-tenant fashion, it is cognizant of the fact that multiple servers may need to host the same application component (in a shared or isolated manner) to handle scale. Thus, the notion of partitions and shards are introduced:

  • Partition: Any one instance of/process for any of your application’s components, depending on component type (e.g. a single database instance or UI process)
  • Shard: A Tenant’s individual isolation unit

The relationship between shards and partitions varies depending on the sharing level:

  • Commingled: Many Tenants are located on the same partition/use the same process
  • Isolated: One Tenant is located on a single partition/reserves a single process (a 1-to-1 mapping)

When sharing is enabled for an application component, there can still be multiple partitions/processes. This allows the Platform to handle scale and reliability concerns. Each component handles this aspect slightly differently, so see the specific topic for each tier for additional information. 

The following diagram illustrates the relationship between partitions and shards for a Commingled deployment:

Remember that Apprenda ensures each Tenant’s functional experience is isolated from other Tenants. This is accomplished both through actual transformations of the physical partition as well as runtime instrumentation. For example, a single database may end up hosting data for multiple Tenants, but database queries that your application executes are guaranteed to only return data for the Tenant making the database call, giving the Tenant a notion of isolated behavior.

Here are some items of note regarding shards and partitions:

  • Partitions from different applications can co-exist on the same server.
  • Multiple partitions of the same isolated database component can co-exist on the same server, although only one instance of an application’s commingled DB or user interface can be hosted on a single server.
  • Each tier (UI, Java Web App, or database) has its own rules regarding sharing and impacts on partition and shard creation.
  • Sharing is configurable on a per-application basis in the Developer Portal (if permitted by your Apprenda Platform Operator).

For .NET services, all instances are shared by all Tenants of the application. There is no deployment mechanic that is different for this application component on the Platform from a single-tenant application. For the varying deployment options available to databases, Java Web Applications, and user interfaces, refer to the appropriate tier below.