Below you will find certain Apprenda-specific vocabulary and paradigms that will be helpful in understanding other portions of our documentation. For ease of use, we’ve broken these up into two groups:
Account: Means through which an organizational unit and its individual members access the Platform’s functionality. There are two types of accounts:
A Development Team account provisions and grants access to linked Developer and Account Portals. A Development Team account is required to configure and publish applications on the Platform.
A Tenant account provisions and grants access to the Account Portal only. This type of account is used to create and manage Users for applications that take advantage of the Platform’s authorization or multi-tenancy capabilities. Tenants can sign up for an application themselves (or be signed up on the Developer’s behalf).
Account Administrator: Apprenda User created when Tenant or Developer account is provisioned. Use this account to create or import additional Users and manage security permissions for other Users. Once other Users are created, it is possible to transfer this designation to another User within the same account.
Add-Ons: Plug-in service modules that extend the Platform’s default functionality. Platform Operators create and manage Add-Ons in the System Operation and Developers can provision and consume individual Add-On instances for their guest application in the Developer Portal.
Clouds: Collections of servers and SQL nodes that are grouped together in the Platform’s infrastructure. Each Cloud is capable of independently hosting all levels of a deployed application (UI, service, and database), but shares a single Core Database and Repository with the rest of the Platform infrastructure.
Developers: Users who have been granted access to the Developer Portal through one or more Development Team accounts. Developers can publish applications on Apprenda through a Development Team, and Tenants can then subscribe to them.
Tenants: Organizational group that subscribes to applications through the Apprenda Platform. Apprenda maintains information about the Tenant, such as the Account Name, and all of this information can be accessed via the API. Each Tenant can have multiple individual Users.
Hybrid Cloud: A Platform that is hosted across two or more Clouds, and the servers/database nodes that comprise the Platform are categorized by which Cloud they belong to. For more information, please see the Hybrid Cloud documentation.
Platform: Short-hand for a specific instance or installation of the Apprenda Clound Platform (which may include more than one Cloud, making the Platform instance a Hybrid Cloud environment).
Platform Operator Person (or people) with permission to configure a Platform instance. Certain Platform-wide settings, like Resource Utilization policies or the types of Application Settings and Presentation Models available for selection by Developers, are configured by a Platform Operator. Configure additional Platform Operators in the System Operations Center (SOC).
Provisioning: When a Developer or Tenant account is first created on the Platform, that account is provisioned for the Account/Developer Portal. Likewise, when a Tenant account is onboarded to a multi-tenant guest application, the account is provisioned for that application. Provisioning refers to the notion that the Tenant consumes physical or logical resources on the Apprenda instance. The exact resources consumed depend on the deployment settings of the application being accessed. During provisioning, any combination of an application’s physical components may be deployed as part of the provisioning request as well as logical representations configured to furnish the requested access.
Resource Utilization Tracking & Throttling: Resource allocation and utilization tracking on the Apprenda Platform is designed to give Platform Operators the real-time knowledge they need to make informed capacity-planning decisions based on actual Resource Utilization as consumed by guest applications within the structure of Resource Policies offered to Development Teams; these Resource Policies also limit the resources a given guest application can consume. In addition, a Platform Operator can set resource limits per Development Team, thus ensuring that no one team monopolizes resources on the Platform.
Application Archive/Package: A ZIP file with a specific directory structure containing your application components. For .NET applications, an archive can be created from a Visual Studio solution using the Apprenda Cloud Shell, Apprenda Archive Builder. Archives for .NET and Java applications can be created manually as per the instructions here.
Application Settings: Many aspects of how an application is deployed and behaves on the Apprenda Platform can be controlled through its Application Settings, which are configured in the Developer Portal.
User Access Model (also known as Application Services Level): The User Access Model determines who can access an application. The values below build on each other in that higher-level User Access Models such as Multi-tenancy require lower-level values such as Authentication and Authorization. Below is a brief description of how your application will be deployed based on the User Access Model selected. Note that in some Platform items (such as the Deployment Manifest), “User Access Model” is called “Application Services Level,” and the available settings have different names. These alternate setting names have been included below in parentheses.
Anyone (None): the application is deployed as a single-tenant application with no Platform-regulated restrictions. For example, if the application’s website is publicly accessible, anyone will be able to launch the application. If it is restricted to an internal network, anyone with network permissions to access the site can launch the application.
Authenticated (Authentication): the application is deployed as a single-tenant application, and the Platform will restrict access to Platform Users. This means that all registered Users on a given Platform is able to launch the application.
Authorized (Authorization): the application is deployed as a single-tenant application, and the Platform will restrict access to Platform Users who have been granted explicit access rights to the application. The Development Team that deploys the application controls which Platform Users can launch and access different parts of the application through controls in the Developer Portal.
Multiple Tenants (Multi-tenancy): the application is deployed as a multi-tenant application, and the Platform will restrict access to Platform Users who have been granted explicit access rights to the application. User access is controlled through subscriptions configured through the Account Portal, and can be either configured by the Development Team that deploys the application or can be left for potential User groups to self-provision.
Presentation Model: This setting determines how User Interfaces are deployed and accessed. For applications with Multi-tenancy, you can choose either a Commingled UI deployment model, which will map all Tenants to one website, or an Isolated UI deployment model, which will create a unique website for each Tenant. Applications with a User Access Model of Anyone, Authenticated, or Authorized are limited to the Commingled UI deployment model, as multi-tenant website creation is not relevant for these applications. Each deployment model offers more than one URL scheme (unless your Platform Operator has restricted these choices).
Database Deployment Model: This setting determines how Tenant data is stored. Typically, the elected approach has both significant development and deployment implications. Using the Platform, Developers always write their database as if the application is being used by a single customer. the Platform defers application storage architecture to a deployment-time decision rather than something architects and engineers concern themselves with at development time. The Platform allows for two data storage strategies:
Commingled – Multiple Tenants have their data stored in the same database and schema. Apprenda transforms the schema automatically, allowing it to separate the data. This provides the highest Tenant density (available only for applications with Multi-tenancy that are using MS SQL Server as their persistence layer).
Isolated: Specifics will vary depending on whether the application uses MS SQL Server or Oracle for the persistence layer:
Isolated Schema: Each Tenant is assigned a completely different schema per application. This is not as efficient from an operations perspective nor as dense as the Commingled model but it is also not as sparse as full Isolated Database model and slightly more efficient (only available for applications using Oracle as their persistence layer).
Isolated Database: Each Tenant is assigned a completely isolated database per application. This is the least dense of the three strategies, but often is necessary due to either government regulation or industry expectation (only available for applications using MS SQL Server as their persistence layer).
Apprenda transforms the application’s physical database structure to fit the chosen model. Application code at the user interface or service layer is written in a single Tenant fashion, including SQL queries against the database. The application code executes equivalently against either deployment model. Scale-out concerns are fully taken into account so database queries execute on the appropriate server without your application having any awareness of this.
Cloud Control: Within certain limits set up by the Platform Operator, Developers have the ability to manage a diverse selection of resources backing application deployment, such as Web Hosting of unique access URLs, management of deployed component instances, oversight of customer Data Storage, and partitioning of Tenant data. These resources can be accessed through the Cloud Control Panel associated with each version of an application that is in the Sandbox or Published stage.
Contexts: Apprenda manages Users, Tenants, Providers, subscriptions, etc., but gives your application the ability to access information about these items. To do this, Apprenda derives Context for each application request and exposes it in our API. For example, Context would be obtained while looking up the currently-logged-in User’s name so it can be displayed in the user interface or checking Users’ subscriptions to see if they have access to a certain feature.
For a list of current Contexts used in Apprenda and their applicability to writing application code, see the Contexts page of our documentation.
Entitlement Definitions (available for applications with Authorization and Multi-tenancy): Developer-defined collections of plans for how an application will be made available to Tenants. They must be configured for applications with Authorization and Multi-tenancy, and can be used to determine access to certain functions of an application. Entitlement Definitions consist of plans, which are combinations of application Features and non-application Components that can be optioned on to a base plan (non-application Components could include 24/7 support, service guarantees, forum access, etc.).
Features & Editions (available for applications with Authorization and Multi-tenancy): An Apprenda application can be programmatically divided into sets of Editions and Features. Features are small, uniquely labeled blocks of application code that are intended to be metered; they are sections of code that perform some transaction that requires access control based on the defined subscription owned by the current runtime User. A Feature can be either declared via attributes at the .NET service or Java Web Application level or can be explicitly defined via calls to the Apprenda API. Apprenda supports four types of Features:
Toggle: These Features are those that are considered “on” if a user is subscribed to use the Feature or “off” if they are not. This is the simplest Feature type in Apprenda. An example of this Feature in use is a CRM application that offers the ability to “Generate Reports,” but that removes that functionality if the Feature is not included in the subscribed plan.
Boundary: These Features may require that some upper or lower boundary be adhered to during execution. Boundaries are defined by a double value type, and at runtime a User’s subscribed boundary value can be checked against a runtime value. An example of this Feature is an HR application that allows resume uploads of up to only 1 MB in size.
Limiter: Some applications require the ability to track a rolling count that can be compared to some upper maximum. If the rolling count is less than the upper maximum, a certain action is allowed. If the maximum is reached, the action is blocked. For example, consider a project management application that will allow a User to have up to 10 open projects at any given time, but no more. If a User has 8 open projects, 2 more projects can be opened. Once 10 open projects are reached, project opening is blocked until at least one is closed or the upper maximum is upgraded.
Block: Block Features allow an application to support pre-allocated quantities of some action where a Tenant can “stockpile” a quantity of that action and deduct from it as it performs the action. For example, a marketing campaign management tool may define the e-mailing of campaign letters as a Feature. A User can procure a block quantity of e-mails. Each time an e-mail is sent, one unit is deducted from the block. Once the stockpile is exhausted, the User would have to upgrade the Feature by procuring more units.
See the Features page of our documentation for information on how to incorporate Features into your application code.
Editions are Provider-defined collections of Features for a specific application. Usually they are groups of Features that are conceptually linked together and offered as large functional groups. Defining an Edition allows Providers to restrict the Features that will be available in subscription plans for an application. Editions are not required; however, once an Edition has been configured for an application, in order to include a Feature in a plan, that plan must be linked to an Edition that contains the desired Feature.
Runtime Binaries: Runtime Binaries represent the code that will be deployed when an application is promoted to Sandbox or Published status. This application version will be based on an uploaded Deployment Archive file, which will contain the components of the application including a combination of .NET user interfaces, WCF web services, Windows Services, Java Web Applications packaged as WARs, a database creation script, and/or an onboarding script.
Securables (available for applications with Authorization or Multi-tenancy): Securables are pieces of code that a Development Team has marked as governed by Apprenda’s access control system. A Securable is noted by name, allowing multiple pieces of code to be controlled by a Securable of the same name. Generally, Securables are mapped by name to real-life verbs, such as “Save Invoice” or “Generate Report”. Users in Apprenda can belong to a variety of Roles defined by the Tenant that owns their User profile. Through the Account Portal, a Tenant can map their defined Roles to published Securables for the applications they subscribe to. For example, if an application makes reference to Securables named “Save Invoice” and “Generate Report”, the Account Portal will display an Access Control Matrix (ACM) with an X-axis defined by their defined roles and a Y-axis defined by the two aforementioned Securables.
At runtime, Apprenda merges application code queries to the mapping defined by the Tenant through this matrix and the current User’s Role membership defines to instruct the query as to whether access should be allowed. Similar to Features, Securables can be declared via attributes at the service level, or can be directly queried via the API for finer-grained control. Apprenda supports two types of Securables:
Standard Securables will not change unless a Development Team makes changes to an application’s code through the release of a new version of the application.
Runtime Securables are a special type of Securable built in to some—but not all—applications. The list of Runtime Securables will change as Users access and change an application. For instance, a version of the Taskr sample app with enabled Runtime Securables allows certain Users to create and secure tags.
See the Securing Your Application via Roles page in the Developer Topics section of our documentation for information on how to incorporate Securables into your application code.
Single- and Multi-tenancy: To enable specific use cases, Apprenda automatically transforms certain parts of an Apprenda-built application at deploy time to give your application’s architecture a single-instance, multi-tenant dimension. For other parts of the application, Apprenda relies on runtime instrumentation to accomplish its tasks. Various Developer topics in the Apprenda Platform documentation explain design consideration aspects of this functionality in greater detail.
The Apprenda Platform also supports application deployment in a single-tenant fashion, and allows Developers the option of regulating access to them by requiring Platform authentication or explicit User authorization.
Subscriptions: For an application deployed with Apprenda’s Multi-tenancy capabilities, subscriptions are the primary access control mechanism for an application. Users cannot access a multi-tenant application without a subscription to it. The subscription also can designate what Features of an application are available to the users.