Purpose

Perfion is a single-tenant software solution, meaning each customer has a dedicated environment with full control and flexibility. Unlike multi-tenant solutions, where multiple customers share the same infrastructure, single-tenancy ensures in managing updates and configuration. For a definition of single-tenancy, please refer to Appendix A.

greater customization, security, and independence

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 fact, the same server configuration used for an on-premises installation can be replicated1:1 in Azure. However, Azure offers additional capabilities that go beyond traditional virtual machines - for example, the Perfion Web Client can be hosted as a service.

If you are uncertain in doubt whether to choose an on-premises or a cloud hosting, please refer to the “Perfion Hosting Guide” for a broader comparison.

This document will:

• Provide concrete examples of Azure-based setups and detailed notes on sizing

• Discuss potential differences between on-premises and Azure hosting

• Offer insights on efficient Perfion hosting in Azure

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.

While the focus is on Azure, many of these considerations are also applicable to other cloud hosting providers.

Components of an installation

The Perfion solution comprises multiple components, including the database, API Service, and Windows Client. A complete overview can be found in the “Perfion Hosting Guide”.

To keep this document concise, the example configurations will focus on the key components most frequently used, excluding “peripheral” components such as the Asset Portal, or the Office Add-in.

The following examples will cover the core components:

• Database

• API Service

• Windows Client

• Web Client

Deployment model A: Database + VM

This initital example outlines a lean setup of Perfion in Azure, mirroring the approach Perfion uses for customers opting for our SaaS model. It applies to scenarios where the customer entrusts all hosting responsibilities entirely to Perfion.

While the description closely resembles that of “Perfion SaaS”, it is reiterated here to facilitate a direct comparison with the deployment model B that follows.

Database

On-premises background

A typical on-premises Perfion customer operates with hardware managed either in their own IT department or through a dedicated hosting partner. In most cases, this hardware consists of virtualized servers, though this has no significant impact on the setup.

The core component of Perfion is the SQL database, which is typically hosted on a dedicated machine—sometimes alongside other databases within the same SQL Server instance.

Azure deployment

In theory, the on-premises setup described above can be replicated 1:1 in Azure, with the only real difference being the physical location of the hardware. This would be a completely valid and functional scenario.

However, Perfion recommends installing the database as a separate Azure SQL instance, and not mixing the Perfion workload with other databases on a single,large SQL Server. This approach allows for more efficient identification of bottlenecks, clearer cost tracking for each system, and enables dedicated scaling

API Service + Web Client

On-premises background

In a typical on-premises setup, a Windows Server is used as the operating environment for both the Perfion API and the Perfion Web Client. Both components are deployed in the Internet Information Server (IIS). While the server can be shared or separate, Perfion recommends using a dedicated instance for optimal performance.

Azure deployment

In the deployment model A, the Azure setup exactly mirrors the on-premises setup: a single virtual machine running IIS, with both API and Web Client installed. No changes are made in this scenario.

Windows Client

On-premises background

Typically, the Perfion Windows client is installed directly on the user's PC, where it utilizes local resources and connects directly to the database.

However, some organizations opt to use Microsoft Remote Desktop Services (RDS) to deliver the user interface to end users. In this setup, no local installation is needed, and both RDS and Perfion rely on the resources of a server machine. This approach can be beneficial for users with Mac devices, those experiencing weak network connections to the database, or when greater control is needed during upgrades.

Azure deployment

In Azure, the options mirror those available in an on-premises setup.

The Windows Client can be installed on the end users' machines, directly connecting to the Azure database. Alternatively, a virtual machine can be configured with RDS, allowing users to access Perfion without needing to install anything on their individual PCs.

For customers using Perfion’s SaaS solution, we adopt the second approach. In this case, the same virtual server hosting the API and Web Client also serves as the host for RDS.

Deployment model A summarized

Model A requires the deployment of just two two Azure resources:

• One Azure SQL

• One Virtual Machine

Behind the scenes, Azure will also require network bandwidth setup, backup procedures, and the selection of a geographical hosting region. However, these elements are not specific to Perfion, and we do not provide particular recommendations or guidance on these topics.

Deployment model B: Database + Services

This second example presents a scenario where Azure's capabilities are leveraged more extensively compared to model A. The goal of this model is to avoid the use of a full virtual machine, instead utilizing individual Azure Services to handle specific tasks.

Database

Refer to deployment model A – no difference.

API Service + Web Client

In this model, the API Service and the Web Client are deployed as separate Azure Services.

The key benefits of this approach include the ability to size and scale each service individually. Additionally, the combined cost of these services is typically lower than the cost of running a single virtual machine.

Windows Client

Since the primary advantage of model B is the elimination of the virtual machine, it naturally follows that the Windows Client should be run directly on each user's PC, connecting directly to the (Azure) database. This setup represents the default mode of operation.

Deployment model B summarized

Model B requires a higher number of individual Azure resources to be deployed, but offers increased 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>

Similar to model A, Azure will still require the basic setup of network bandwidth, backup procedures, and the selection of a geographical hosting region. However, these aspects are not specific to Perfion, and we do not provide particular recommendations or guidance on these matters.

Choosing the right deployment model

There is no definitive right or wrong choice, and Perfion aims to provide customers with the freedom to choose the best option for their needs. For customers without existing Azure expertise, deployment model A is generally recommended due to its simplicity.

Deployment model B can be a great option for customers or partners with in-house Azure knowledge. However, it is important to consider the entire setup carefully. For example, if the Asset Portal requires a virtual machine, it might make sense to use model A and share the same VM for the API/Web, rather than opting for the more complex model B.

Azure Sizing

Given that Perfion is defined by its flexible data model and offers a wide range of configuration options, it is not possible to provide a definitive answer for system sizing.

The minimum requirements are outlined in the “System Requirements”.

For general guidance and additional considerations, please refer to the “Perfion hosting guide”.

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

Disclaimer

Several factors can influence the actual performance experienced with a Perfion solution. Some of the most notable include:

• The number of users

• The number of items in database

• The number of features in the data model

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

• The configuration of scenes and grid views

• Dependencies on external sources (for remote features)

• API calls or imports during user working hours

Generally, accurately determining sizing requirements before the implementation can be challenging, even for experienced consultants. However, a decision must be made based on prior experience and known factors such as those listed above. It is recommended to leverage Azure’s flexibility, adjusting the Azure size (and cost) during the process, while collaborating with the customer to find the optimal balance between added value and cost.

Appendix A: Single-tenancy

The following description is provided courtesy of Techtarget.com.

Introduction

Single-tenancy refers to an architecture where a single instance of a software application and its supporting infrastructure are dedicated to serving one customer. This model is commonly used in software-as-a-service (SaaS) and cloud service environments. In a single-tenant setup, the customer - referred to as a tenant - has an exclusive instance of the application designed specifically for them.

In this type of architecture, the service provider is responsible for managing the software instance and its dedicated infrastructure while allowing the tenant a high degree of control over the customization of both the software and the infrastructure. Key benefits of single-tenancy include enhanced user engagement, full control for the tenant, as well as increased reliability, security, and backup capabilities. Since each tenant operates within its own isolated environment, there is less risk of interference or resource sharing issues that are common in multi-tenant systems.

Customers often opt for a single-tenant infrastructure when they require greater control and flexibility to meet specific operational needs, as it offers a more tailored and secure environment compared to other hosting options.

How single-tenancy works

In a single-tenancy architecture, each tenant is provided with their own dedicated database and software instance, ensuring that their data is completely isolated from other tenants. In addition, the architecture is designed to only allow one instance per SaaS server. The system is designed so that only one instance runs per SaaS server, and each piece of software can either be purpose-built for the new tenant or customizable to fit their needs after installation. Once the software is deployed, tenants typically have the ability to modify the user interface (UI) to align with their specific requirements, though they do not have access to the underlying source code.

Each tenant's data should also be backed up separately ensuring that in the event of data loss, recovery is quick and straightforward. Tenants usually have the flexibility to decide when they want to install available updates, giving them control over the timing of such changes, rather than waiting for the service provider to implement them.

Single-tenancy is also common in cloud environments, particularly in private cloud services or third-party cloud offerings. In these cases, the system is designed so that an individual customer is the sole user of the instance, which allows for better security, management, and customization options, with complete control over their environment.

Open

Benefits of single-tenancy

Although single-tenancy architecture is less commonly used, it offers several significant hat make it a viable option when selecting a service architecture. These advantages include:

• Single-tenant instances through a cloud service or SaaS

• Data independence: Tenant data is kept separate from that of other users, even when hosted by the same provider, ensuring clear boundaries.

• Data security: In the event of a data breach involving one tenant, other tenants remain unaffected due to the isolated nature of each instance.

• Customization: The separation of each tenant’s data allows for greater flexibility in customizing both software and hardware instances to suit specific needs.

• Reliability: Since performance is based on a single tenant's instance rather than a shared one, single-tenant setups are considered more reliable, as they are not impacted by the activity of other tenants.

• Restore and disaster recovery: With isolated backups for each tenant, restoring data after a disaster is faster and more straightforward.

• Migration flexibility: Single-tenancy also facilitates easier migration from the hosting environment if necessary, as each instance is self-contained.

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, which include:

• Cost: Setting up, maintaining, and customizing a separate instance for each customer can be expensive in terms of time, resources, and effort.

• Management responsibility: Since the tenant typically manages the system, it requires more time and effort for updates, upgrades, and ongoing maintenance.

• Learning curve: Implementing and customizing a single-tenant SaaS system can come with a steeper learning curve, especially for new users or administrators.

• Inefficiency: If the system is not optimized, some resources may go underutilized, making the system less efficient overall.

Requirements for single-tenancy

The requirements for single-tenant environments include:

• Future workload capability: In a SaaS or cloud service setup, the service should be able to accommodate future workload requirements as the system scales.

• Initial startup time: Single-tenancy typically involves a significant startup period, as the software needs to be built or customized for each tenant individually.

• Resources for maintenance: Single-tenant environments often demand more ongoing maintenance and management, so end users must have the necessary resources and time for upkeep.

• Administrative support for extensions: Since the underlying code is restricted in single-tenancy SaaS applications, implementing major extensions or third-party integrations may require assistance or administrative support from the host service.

Multi-tenancy vs. single-tenancy

Single-tenancy is often compared to multi-tenancy, an architecture where a single instance of a software application serves multiple customers. In a multi-tenant setup, all customers share the same database and application instance. Multi-tenancy is particularly beneficial for businesses looking for a quick startup and reduced hardware requirements. It has become the industry standard for enterprise SaaS solutions due to its cost-effectiveness, efficient resource utilization, lower maintenance costs, and the potential for greater computing capacity.

Despite its many advantages, multi-tenancy comes with some drawbacks. The main limitation is the reduced ability for significant customization, as the software is shared among multiple tenants. Additionally, because multiple customers rely on the same infrastructure, multi-tenancy can experience more downtime compared to single-tenancy.