Purpose

Perfion is a single-tenant software solution, meaning that each customer has a complete environment with total control and flexibility, as compared to multi-tenant solutions. For a definition of single-tenancy, please refer to Appendix A.

In relation to hosting, the fact that one instance is installed pr. customer, means that there is a very big similarity between hosting Perfion on-premises and hosting Perfion via Microsoft Azure. In reality, the server configuration used in an on-premises installation can be repeated 1:1 in Azure. But more advanced options within Azure can also be used to host for example the Web Client as a service, rather than utilizing a traditional virtual machine.

If in doubt whether to choose an on-premises installation or a cloud installation, please refer to the more general “Perfion Hosting Guide”.

This document will focus on Azure and describing the similarities to an on-premises installation but will also discuss some (possible) differences in how Perfion can be hosted efficiently via Azure. The document will use very concrete examples of setups, followed by notes on sizing. Most of the considerations here can be extended to apply for other cloud hosting providers, but Azure will be the basis here.

Components of an installation

The Perfion solution consists of several different components. Examples are the database itself, the API Service, and the Windows Client. For a full list of components, refer to the “Perfion Hosting Guide”.

For simplicity, the example configurations in this document will focus on the most important and commonly used components, and leave out “peripheral” components such as the Asset Portal, or the Office Add-in.

The list of core components addressed in the following examples are:

• Database

• API Service

• Windows Client

• Web Client

Deployment model A: Database + VM

This first example describes a lean setup of Perfion in Azure, similar to how Perfion itself handles the hosting for customers who purchase our software as a SaaS model. This is the model used in cases where the customer delegates all hosting responsibility completely over to Perfion.

Although the description is very similar to the one in “Perfion SaaS”, it is repeated here in order to more directly compare with the deployment model B afterwards.

Database

On-premises background

The typical on-premises customer using Perfion, has hardware either in an own IT department or with a dedicated hosting partner. More often than not, the hardware will be virtualized servers, but that has no real impact.

The most central component in Perfion is the SQL database. That would normally be installed on a separated machine, sometimes with other databases on the same SQL Server.

Azure deployment

In theory, the on-premises situation above could be copied 1:1 to Azure, with the only real difference being the physical location of the hardware. This would be a completely valid and working scenario.

However, Perfion recommends installing the database as a separate Azure SQL instance, and not mixing the Perfion workload with other databases on one big SQL Server. This will make it easier to pinpoint bottlenecks and costs of each system, as well as enable dedicated scaling.

API Service + Web Client

On-premises background

The typical on-premises customer would use a Windows Server to be the operating environment for both the Perfion API and the Perfion Web Client. Both components are deployed in the Internet Information Server (IIS). As with the database, the Server can be shared or separate, but Perfion recommends a separate instance.

Azure deployment

In the deployment model A, the Azure setup is indeed exactly as the on-premises setup: One virtual machine running IIS, with both API and Web Client installed. No changes.

Windows Client

On-premises background

Most often, the Perfion Windows client will be installed directly on the user’s PC. The client uses PC resources to operate and connects to the database in a direct manner.

But in some organizations, it is chosen to use Microsoft Remote Desktop Services (RDS) to provide the user interface to end users. In this way, no local installation is required whatsoever, but the RDS and Perfion will use resources on a server machine. This can come in handy for e.g. users with Mac devices, or for users with weak network connection to the site of the database. It also gives more control in upgrade situations.

Azure deployment

Once again, the options in Azure are similar to the options on-premises.

The Windows Client can be installed on the end users machine, and connect directly to the (Azure) database.

Or, a virtual machine can be set up with RDS, which means users don’t have to install anything on each PC.

When a customer goes to Perfion and purchases our own SaaS solution, we utilize the second option. Here, we use the same virtual server that hosts the API and Web Client, to also host the RDS.

Deployment model A summarized

Model A requires only two Azure resources to be deployed:

• One Azure SQL

• One Virtual Machine

Behind the scenes, Azure will also require a setup network bandwidth, backup procedures, and a choice of geographical hosting region. But such elements are not Perfion-specific and Perfion has no special recommendations or advice on these topics.

Deployment model B: Database + Services

This second example describes a scenario where the possibilities in Azure are exploited slightly more, compared to model A. In essence, the aim of this model is to avoid the full virtual machine, and instead handle those tasks as individual Azure Services.

Database

See under deployment model A – no difference.

API Service + Web Client

In this model, the API Service as well as the Web Client are installed as separate Azure Services.

The potential benefits include the possibility to size/scale each service individually, and the combined cost of these services would generally be a little lower than the cost of one virtual machine.

Windows Client

Since the benefit of model B is in the elimination of the virtual machine, then it is natural conclusion to let the Windows Client be executed from each users PC, with a direct connection to the (Azure) database. This is the default mode of operation.

Deployment model B summarized

Model B requires a higher number of individual Azure resources to be deployed, but comes with added flexibility:

• One Azure SQL

• One Azure Service for the API

• One Azure Service for the Web Client

• <potentially more services, for connectors and other necessary components>

As with model A, Azure will still require the “fundamentals” of network bandwidth, backup procedures, and a choice of geographical hosting region. But such elements are not Perfion-specific and Perfion has no special recommendations or advice on these topics.

Choosing the right deployment model

There is no right or wrong choice, and Perfion strives to let customers choose freely.

For customers without own existing Azure competencies, deployment model A is generally recommended, solely for the simplicity that it offers.

Deployment model B can certainly be a good option for customers or partners with in-house Azure skills, but it is recommended to make sure the full picture is considered (for example: If the Asset Portal is in play and requires a virtual machine anyway, why not simply use model A and employ the same VM as already used for API/Web).

Azure Sizing

Since Perfion is by nature defined by the flexible data model and provides a great range of options for how the system works, it is not possible to give any 100 % fixed answer to the question of sizing.

The minimum recommendation can be seen in “System Requirements”.

Some general advice and considerations can be read in the “Perfion hosting guide”.

When Perfion hosts a SaaS solution for customers, we initiate a sizing evaluation based on the simplified ladder below, which applies to deployment model A above.

Disclaimer

Many different factors influence the actual experienced performance of a Perfion solution. Some of the most obvious are:

• Number of users

• Number of items in database

• Number of features in the data model

• General complexity of the data model (inheritance, item dependencies, validations, etc.)

• Setup of the scenes and grid views

• Dependencies to external source (for remote features)

• API calls or imports during user working hours

In general, it can be difficult for even experienced implementation consultants to accurately determine the sizing requirements for a customer, before the implementation is done. But a choice must be taken based on previous experience and known factors like the bullet list above. And it is recommended to utilize the flexibility of Azure to experiment by dialing up Azure size (and cost) while working with the customer to determine the sweet spot between added value and cost.

Appendix A: Single-tenancy

The following description is courtesy of Techtarget.com.

Introduction

Single-tenancy is an architecture in which a single instance of a software application and supporting infrastructure serves one customer. Single-tenancy is commonly implemented in software-as-a-service (SaaS) delivery models or in cloud services. In single-tenancy architectures, a customer -- called a tenant -- will have a singular instance of a SaaS application dedicated to them.

In a single-tenant architecture, the host provider will aid in managing the software instance and dedicated infrastructure while still lending nearly full control to a single tenant for customization of software and infrastructure. Some common characteristics of single-tenancy models are that they tend to provide a high level of user engagement and user control, as well as reliability, security and backup ability. Because tenants are in a separate environment from one another, they are not bound in the same way tenants using a shared infrastructure would be.

Potential customers would likely choose a single-tenant infrastructure over other possible options for the ability to have more control and flexibility in their environment for addressing specific requirements. 

How single-tenancy works

In a single-tenancy architecture, every tenant will have their own single database and software instance. This way, each tenant's data is isolated from one another. In addition, the architecture is designed to only allow one instance per SaaS server. Each piece of software may be purpose-built for the new tenant, or the tenant can customize the user interface (UI) after installation. Once the software is installed locally, tenants can typically customize the software to best suit what is needed for their specific environment, but they do not have access to any underlying code.

Each tenant's data should also have an isolated backup, so if there is any data loss, tenants should have an easy time restoring their data. In addition, tenants can typically choose when to install any available updates individually, instead of waiting for the service provider to do so.

Cloud adoption of single-tenancy architectures in cloud computing is common as well. In most cases, if someone is using a private cloud service or a third-party cloud offering, it is most likely a single-tenant system. This is because an individual would be the only customer with access to that instance, with security and management options as well as individual controls.

Open

Benefits of single-tenancy

Although single-tenancy architecture is used less often, it still has some noticeable benefits that keep it open as an option when deciding on a service architecture. Some benefits include:

• Single-tenant instances through a cloud service or SaaS.

• Data is independent of other potential tenants with the same provider.

• Data security. Even if there is a data breach to one tenant with the same service provider, another tenant would be safe from the breach since data is stored in a separate instance.

• Since all of a customer's data is separate, a large degree of customization is possible for software and hardware instances.

• Single-tenant instances are considered reliable, since performance is based on only one instance, instead of many from different tenants.

• Restore and disaster recovery. Isolated backups allow users to quickly enable a recovery if there is a disaster and data is lost.

• Single-tenancy may also lend itself to migrating from a host environment if needed.

Drawbacks of single-tenancy

With all the potential advantages to single-tenancy, it is still the less used option out of competing architectures, which could be due to some of its disadvantages. Drawbacks to single-tenancy include:

• Between setup time, resources, customization, and maintenance, hosting one SaaS instance per customer can come at a price.

• Since the tenant is normally the one to manage a single-tenant system, it then takes more time to update, upgrade or manage something.

• Learning curves may appear when first beginning to implement and customize a single-tenancy SaaS.

• In a less optimized system, not all resources may be utilized, which makes for a less efficient system.

Requirements for single-tenancy

Requirements needed in single-tenant environments include:

• If in a SaaS product or a cloud service, the service should be able to meet with whatever the requirements are for future workloads.

• Initial startup time. Single-tenancy involves significant startup time since the software has to be built or customized for each tenant.

• Resources for maintenance. Single-tenant environments tend to require more maintenance and upkeep, meaning end users should have the resources and time needed for the upkeep.

• Since the underlying code of a single-tenancy SaaS application is blocked off, major extensions and third-party integrations may require administrative support from the host service.

Multi-tenancy vs. single-tenancy

Single-tenancy is typically contrasted with Multi-tenancy, an architecture in which a single instance of a software application serves multiple customers. In a multi-tenant architecture, each customer shares the same database and application. Multi-tenancy is typically ideal for businesses that want an easier startup experience and fewer hardware requirements. The architecture has become an industry standard for enterprise SaaS environments. In comparison to single-tenancy, multi-tenancy is cheaper, has efficient resource usage, has a lower maintenance cost and a potentially larger computing capacity. 

Even though multi-tenancy has a lot of visible advantages over single-tenancy, the ability to make significant customizable changes to the software is hampered because the software is shared among other tenants. In addition, multi-tenancy can experience more downtime.