On-Premise Installation

An on-premise installation of the platform is one that is installed and managed locally--typically behind the organization's firewall.

Features and Benefits

An on-premise installation of the platform is typically used by large organizations to manage costs and to take advantage of additional features.

The fundamental benefits of an on-premise installation include:

Fixed cost

Although the initial cost is higher, it costs nothing extra to add additional users--and additional tenants, which can be a benefit for a very large and/or commercial organization.

Firewall protection

Running the platform behind the corporate firewall provides an additional layer of security and data privacy.

Deterministic upgrades

The version of the platform that is running in the cloud is upgraded once or twice a month. Those upgrades provide fixes and new features, but they may also introduce new issues, and may include interface changes. For an organization that requires maximum stability, an on-premise installation provides consistent behavior that is upgraded only when the organization deems it prudent.

Custom installation

The platform runs across multiple servers. For high-volume applications, many additional servers can be added to eliminate bottlenecks. An on-premise installation allows the organization to monitor server loads and customize the installation, adding additional servers wherever they are needed to maximize performance.

Application control

The applications that are available for installation by a tenant can be limited to those you select.

Additional features provided by an on-premise installation include:

Custom Domain

An on-premise installation is available at the domain you designate. For example: http://service.yourCompany.com.

Multiple Tenants

An organization can create multiple distinct tenants, selectively sharing data among them and automatically updating applications. A commercial venture could have multiple independent clients for a single application. Or a large organization could have different tenants for different departments, effectively isolating them from one another while sharing data in strictly determined ways.

Multiple Service Portals

Each tenant can have only one copy of the ServiceDesk application, primarily because external customers use the same URL to access the Service Portal to create and track cases, peruse a knowledge base, or engage in community interactions. Since there is only one URL per tenant, there is only one portal for customers to access. With an on-premise installation, an organization can circumvent that limitation, by creating a different tenant for each application that needs a Service Portal. Data can then be shared between the applications using Tenant Data Sharing Policies.

Broadcast messages

All users see the broadcast message when they log in, for as long as it is in force.

Custom Java Libraries

The organization's libraries can be integrated directly into the platform--for example, to access enterprise applications.

Introspection and Reflection libraries

The standard Java libraries that provide these advanced features expose public cloud users to unnecessary risk. But while leaving them out provides an extra layer of protection for cloud users, it also introduces some limitations for Java programmers. For example, to build a general-purpose data display tool, it is necessary to ask "What kind of object is this?", and then use the appropriate display mechanism for say, a HashMap or an ArrayList. But the libraries needed for that purpose are not available in the public cloud. (They're only needed for the most sophisticated of applications, but when they're really needed, they're indispensable.)

Learn more: