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.
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.
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):
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.
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.
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).
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:
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.
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.
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:
Note that .NET services are always deployed in a Commingled manner by the Platform.
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:
The relationship between shards and partitions varies depending on the sharing level:
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:
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.