Technology Overview

Perfion is a Microsoft Partner and uses Microsoft Azure as the backbone of our Perfion SaaS service offering. This provides several valuable characteristics, via world-class virtual hardware provided by Microsoft Azure:

• 99.9%+ uptime

• Dynamic scaling options

• Best-in-class security measures

All the known components in a Perfion installation still exist in the cloud deployment.

• The database is deployed on Azure SQL.

• The API, scheduler and web client will run on a virtual server.

• End-user access can be supported in multiple ways, by either installing the Perfion application locally on Windows, streaming the application on both Windows- and Non-Windows system or accessing the application through a browser.

Azure Topology

Each customer will have their own dedicated Azure resources allocated to run their solution. All servers, both application- and database servers, provisioned for a customer are dedicated to that customer, ensuring that there are no “noisy neighbors” that can impact the performance of the solution. Apart from a few resources, needed by Perfion to manage the solutions, each customer is completely isolated. This means that one customer cannot access the resources from another customer while it also allows for full control over resource allocation, sizing, network-based integrations, firewall rules and the overall maintenance schedule of the solution. See also Appendix A about single- vs multi-tenant solutions.

Figure 1 shows, high-level, how a customer is deployed in Azure. The Azure region will be agreed upon with the customer and depends on where the users are located. A Perfion SaaS environment consists of two main components, an application server and a SQL database. Additionally, one or more front-end desktop machines may be added as described below.

The application server hosts the Perfion API, Perfion Web Client and the Perfion Application Server. Depending on the customer requirements, the application server may be accessible via the Internet and thus allow for external access to the Perfion API and the Perfion Web Client.

As an add-on, a file share can be made available to support certain integration scenarios.

Azure Recovery Services Vault is used for backup of customer data. Backup includes both servers, file shares and databases and thus allows for a complete recovery of the solution.

To manage access and to operate the resources, Perfion uses the Azure AD domain services and Azure Bastion. Azure Key Vault is used for storing and governing access to the necessary secrets, such as passwords and SSL certificates.

Neither partner nor customer need to worry about the Azure setup, which is handled by Perfion. However, since the infrastructure is not shared with other customers, the flexibility is still present. Perfion or a partner can access and adjust individual parameters of the database, the scheduling service, the network connectivity, or the IIS which hosts the API and web client.

Azure Topology - with managed Perfion Windows Client

As an add-on to the standard topology described above, Azure Virtual Desktop may be used to support end-user access to the Perfion Windows application. Azure Virtual Desktop also allows administrators to access the Windows desktop directly, should that be necessary.

With the Azure Virtual Desktop add-on, one or more front-end desktop machines will be configured to the Perfion Windows client. These are the machines that users will connect to through Azure Virtual Desktop. Azure Virtual Desktop ensures that connections from users are distributed across the machines that are allocated to the customer and thus ensures that all users can expect a similar experience in terms of performance.

To support users may roam across different machines, an additional Azure file share is used to store the user profiles.

Connection to on-premise systems

As per default, the components comprising a customers Perfion SaaS environment is isolated from other customers environments. The setup allows all outbound traffic originating from the Perfion SaaS environment towards the internet. Traffic will, per default, be routed using Microsoft Azure default routing. This means that traffic originating from the application server will use the application server’s static IP address. Traffic originating from the managed front-end servers, which do not have static IP addresses, will use one of Microsoft’s generic IP addresses.

To allow the Perfion SaaS environment to access remote (e.g. on-premise) systems, Perfion supports two basic solutions:

1. IP filtering, optionally via NAT gateway
   Using IP filtering rules, via whitelisting IP addresses from the Perfion SaaS environment in the firewall of the remote system, traffic may be allowed to flow. Note that, per default, the managed front-end servers do not have static IP addresses. If necessary, Perfion can setup a NAT gateway which will ensure that all traffic originates from a well-known IP address.

2. VPN gateway
   If the remote system infrastructure does not support IP filtering, Perfion can alternatively setup an IPSEC Site-2-Site VPN tunnel between the Perfion SaaS environment and the remote system’s network. This will allow traffic from both ends to flow directly via a secure network tunnel. This requires that the remote system infrastructure supports site-2-site VPN tunnels via a VPN gateway in the remote network.

Usage scenarios

Perfion SaaS supports multiple different scenarios for accessing the application. These can be combined and thus support different kind of users from the more occasional “read-only users” to the more full-time administrative users.

1. Perfion Web Client

2. Perfion Windows client installed locally

3. Azure Virtual Desktop – Remote App Streaming

4. Azure Virtual Desktop – Web Client

Perfion Web Client

A customer may choose to make the Perfion Web Client available on the Internet or may choose to only allow access to the application from certain internal IP-addresses. Either way, users can then access the Perfion Web Client using a modern browser. Using the Perfion Web Client is a good choice for the read-only-, occasional- and light editor users.

Depending on customer, the users can authenticate using Azure AD- or local Perfion credentials.

Perfion Windows client installed locally

Even though the Perfion application is hosted in the cloud, depending on the customer requirements and the chosen hosting solution, it is possible to access the application from a Windows client installed locally. A local installed client may be a good option for heavy users that run large imports from local files.

Connecting to the database in the cloud is very similar to configuring the application to access an on-premises database. Perfion will supply the name of the SQL server, database and the credentials needed to connect.

Once connected, the application will run exactly as if the database was hosted on-premises. Please note though, that the network latency may be longer depending on where the database and client is located and how far the data needs to travel.

Azure Virtual Desktop – Remote App Streaming

Azure Virtual Desktop supports so-called Remote App Streaming, which means that the application runs remote but is being streamed to the local machine making it appear as if it was running locally. Using Remote App Streaming is a good choice for editor users that need to full editor experience and access to local resources like disk drives.

To use this feature, the users need to have the Azure Virtual Desktop client installed on their machine. Clients can be downloaded for both Windows, iOS, Android and macOS systems. Please see https://docs.microsoft.com/en-us/azure/virtual-desktop/user-documentation/ for download links and system requirements.

To access the application, users need to sign on with credentials supplied by Perfion. Azure Virtual Desktop does not, as this time, support federation with a customer’s existing AD. The application can however be configured to save the user’s credentials and thus providing a relatively seamless sign in experience. Once signed in, the user will see the application made available to him/her.

Once running, it will look and behave very similar to a locally installed client. Azure Virtual Desktop supports saving shortcuts locally, for quicker access.

Azure Virtual Desktop – Web Client

Azure Virtual Desktop support accessing the applications using a modern web browser like Microsoft Edge, Safari or Google Chrome. Please note that, currently, the Azure Virtual Desktop web client does not have mobile OS support. Using the Azure Virtual Desktop is a good choice for users that need a full editor experience but does not need to access local resources.

To access Azure Virtual Desktop, the user simply needs to go to https://rdweb.wvd.microsoft.com/arm/webclient and sign in with the credentials supplied by Perfion.

As the Azure Virtual Desktop web client does not require any installation, accessing the Perfion application this way may also be a good option for shared computers.

Service Levels

End-user/application support

The Support Agreement for SaaS customers is identical to the Support Agreement for perpetual or subscription customers. Please refer to the customer-specific agreement for details about SLA’s and ways to interact with the Support team.

Infrastructure support

As part of the Azure offering, Microsoft guarantees the service- and availability levels for the resources that Perfion use to deliver the service to the customer. On top of this, Perfion cooperates with a ISO27001 certified hosting partner, Sentia Denmark A/S, to provide 24/7 monitoring and operational service desk for infrastructure related incidents.

Licensing

Licensing of a Perfion SaaS solution includes both licenses, infrastructure, operations and maintenance and will depend mainly on two variables:

• The Perfion version (entry, business, enterprise) and any additional licensed modules

• The agreement timeframe (longer timeframe = lower monthly cost)

The actual prices can be requested from Perfion, or from any official Perfion partner.

Services

When opting for Perfion to host your solution, several things will be handled as part of the SaaS contract. Other tasks will still be the responsibility of the customer (or implementation partner), most often because the decision to do these tasks should remain with the individual customer.

To ensure high uptime for SaaS customers, limiting the access to the environment

The responsibility matrix below can be used as a reference:

Special limited access can be requested through Perfion ticket system for partners or certain SUPER users. Currently Perfion may require that some SUPER users have access to the SQL server database in order to make changes that isn’t possible in the Perfion UI, and if a customer solution does require such changes a temporary limited access can be requested to selected SUPER users that will be allowed access to SQL server through SSMS. When requesting access to SQL server the request should include a use case for which this access is required once the request is approved access will be granted.

Maintenance / Upgrade

Perfion Operations will during the year offer to upgrade customer environments to ensure most optimal user experience and performance. It is also possible for customers and partners to request upgrades in between main releases. All upgrades are scheduled with the customer and Perfion Operations to plan environment downtime.

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.

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.