Platform Server and Data Storage Roles

The infrastructure that constitutes your Platform can take on varying hosting roles.  For servers, these roles are determined by the following:

  1. The OS (Windows or Linux)
  2. The underlying software on the server (e.g. IIS), which determines what the server *can* host
  3. The options you choose during installation, which determines what that server ultimately *will* host

For data storage hosts, these roles are determined by the following:

  1. Database management software (e.g., MS SQL Server or Oracle RDBMS)
  2. Storage accessibility via network paths and accounts with appropriate permissions (Platform Repository)
  3. The options you choose during installation

These roles and their functions are described below. For more information on services and processes related to each role, please see What is Apprenda, Physically Speaking?

It should be noted that one server may take on multiple hosting roles, and that not all roles are essential for required Platform functionality. Non-essential roles have been marked as “optional” below.


All essential Platform functionality can be hosted on Windows servers. This means that a single Windows server with IIS and SQL Server is capable of hosting a Platform installation.

Application Server 

All Windows Application Servers host Apprenda Windows Host service. The Windows Host enables the hosting of WCF and Windows services, thereby allowing both key Platform and guest application service components to be hosted on these servers.

Web Server 

Windows Web Servers are frontend web servers that host .NET based UIs through IIS. Via portals, the Platform allows developers and Platform operators to create ad-hoc web farms for .NET guest application UI workloads at any time (as long as there is sufficient infrastructure).  The sum of your Windows Web Servers represent the compute power of your Platform specifically for hosting .NET guest application UI workloads.

It should be noted that all Windows Web Servers are capable of hosting WCF and Windows services. This is necessary for the nodes to host the Presentation Controlling Services (see the Apprenda Software Inventory below), which allows management of .NET UIs in IIS. As such, all Windows Web Servers will also be marked as Windows Application Servers (described in the section above) after installation even if they were designated as Web Servers only in the Apprenda Installer.  By default, however, the Platform will deploy WCF/Windows services to Web Servers only if there are no dedicated Application Servers available.  

Load Manager

On the Platform, the Load Manager (best described as a reverse proxy) serves as the initial receptor of an incoming HTTP requests.  IIS configuration on the Load Manager is managed by the Apprenda Load Manager Service, a Windows service that creates and modifies URL Rewrite rules as various guest app components are deployed to internal frontend content servers.  The Load Manager Service ensures the appropriate routing of inbound requests based on request URL patterns.

Platform Coordination

Coordination of guest application workload deployment is handled by these nodes. The servers run a custom implementation of Apache ZooKeeper, running as a Windows service. Per the Apache ZooKeeper website, ZooKeeper is “a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.” On Apprenda, the Platform Coordinator Nodes maintain knowledge of the topology of guest application workloads across all nodes, as well as any shared configuration in use by Apprenda components.

An optimal Platform installation requires an odd number of Platform Coordination Nodes, as a majority of extant Platform Coordination Nodes ((n+1)/2, where n=the number of nodes) must be up and running in order for the Platform to function properly. 


These nodes house the Apprenda Caching Windows Service, a distributed Redis-based in-memory caching implementation for all Platform Windows and Linux servers.  Each Cache node will run one instance of the ApprendaCaching Windows Service, as well as one or more instances of the redis-server executable.  The number of redis-server instances per server is configured as part of the installation process; each port specified will result in an instance of redis-server running on that port, with a per-redis-server-instance memory limit corresponding to the value specified in the Installer.  It should be noted that the values for memory limit, ports, and Cache password will be the same for all Cache nodes on a given Cloud, but may vary from Cloud to Cloud on the same Platform. 

The ApprendaCaching Windows Service acts as a wrapper for the redis-server instances, and ensures the proper number of instances of redis-server are running on the specified ports.  If a redis-server instance crashes, the ApprendaCaching Windows Service is responsible for restarting it on the appropriate port.

It should be noted that when data is being cached, our caching implementation uses a hash algorithm against the key to determine which redis-server instance (identifiable by Cache node and port) the value should be stored in and then sends the value to that redis-server instance only. Values for a given key will only ever be stored on a single corresponding instance. This ensures that different values for the same key are not stored in different places, but it also means that values are not replicated in any way.  Therefore if the redis-server instance that a key was stored on crashes or is otherwise unreachable, all data cached in the instance will be temporarily lost until the instance is restored.  

Storage Controlling Services Host

It is necessary that at least one Windows Application Server per cloud host Apprenda’s Storage Controlling Services, which interfaces with SQL Server and Oracle to configure databases. These servers are required to have SQL Server Management Objects (SMO) 2012 installed.  At installation, the Platform will mark any Windows Application Servers with SMO installed as capable of hosting the Storage Controlling Services and will deploy this component to those servers.  It will install the required SMO version (11.0 or higher) on a single Application Server if no suitable host is found. 


Linux Servers (Optional)

Linux Servers host Java Web Application components, which are deployed and managed on top of individual Java container instances (including Tomcat 6, Tomcat 7, and JBoss 6) by the Apprenda Linux Container. Linux Servers may also host other container technology (such as Docker) when configured to do so, and may also host generic Linux Services.

Data Storage

MS SQL Instances

The Platform manages MS SQL Server instances on your behalf to provision and configure guest application databases. Any number of SQL Server instances can be managed by a single Platform, and SQL instances can be added to the Platform at any time for capacity.  In addition to providing storage for guest applications, an Apprenda managed SQL Server instance is necessary for housing the Apprenda Core Database, which contains data necessary for Platform functionality.

Ideally, MS SQL instances should be configured on separate nodes that do not serve as Apprenda servers (i.e., they do not host WCF services or other application components), and may be configured as a failover cluster; however, in smaller Apprenda installations and single-node Apprenda Express installs, a SQL Server database instance may be housed on an Apprenda server.

Oracle RDBMS (Optional)

The Platform manages Oracle RDBMS installations on your behalf to provision and configure storage for guest applications. As far as the Platform is concerned, Oracle RDBMS installations are OS agnostic. Ideally, Oracle should be configured on separate nodes that do not serve as Apprenda servers (i.e., they do not host WCF services or other application components).

The Platform Repository

The Platform Repository is a network share that will serve as the central storage location for all Platform and guest application binaries. The share may be located on a SAN or NAS (this is recommended for production installs), or can be housed on a Windows server. Upon workload deployment, binaries that are needed for local execution are copied to the target server from their respective locations in the Platform Repository.