Qlikview as PaaS, IaaS and SaaS Service
QlikView is an in-memory software platform and so speed of access to RAM is a key factor in delivering good performance to users. Similarly, availability of CPU power to perform aggregations on the fly and produce content for users is also key. Virtualization technologies place some restrictions of speed of access to RAM compared to physical servers and can also limit the number of CPUs available to a single machine; this is reflected in the maximum size that cloud servers can be with regard to RAM and CPU. This can mean that not all QlikView deployments are suited to being virtualized and so it is important to size a deployment of QlikView when considering use of cloud.
With QlikView this would mean all users would view the same QlikView apps but perhaps the data they see within those applications would be different.
QLIKVIEW AND IAAS
IaaS is a common cloud model used by QlikView customers; indeed QlikTech’s own demo.qlikview.com and other services are run from the IaaS model offered by Amazon EC2. This model allows QlikView customers to deploy infrastructure suitable for their environment and have full control over what QlikView applications they host in the environment and how they configure it.
With QlikView in a PaaS model, a customer could implement QlikView onto a hosted PaaS vendor’s technology. For this type of implementation, QlikView requires a Windows platform to run on. One such PaaS option is Microsoft’s Windows Azure. It is possible to package the QlikView product along with customer - or partner-built apps and deploy onto the Azure platform and so enable customers to be free of the infrastructure (i.e. hardware, network and OS) management.
End user access to QlikView hosted on Cloud:
In this kind of deployment there is no customization required for QlikView, just a simple configuration; however it does require that the customer has in place an SSO system that can make use of reverse proxy.In this type of setup the only device that ever physically touches the cloud server is the reverse proxy. No users will ever directly touch the cloud server or even know that it is a cloud server. This mechanism could serve both internal and external users and is an excellent approach for conforming to what can be the standard way of integrating security within an organization.
SAML (Security Assertion Markup Language) and federated security such Active Directory Federation Services can be used security systems that can make use of secure tokens to sign users into a range of systems as shown below.
With Active Directory Federation Services (ADFS) it is possible for users to seamlessly log in to a non-domain cloud server without being prompted to log in as their internal Windows credentials are used during the process of logging in. This gives an excellent user experience and ADFS is often implemented within organizations alongside their regular Active Directory which means there is no requirement for an additional SSO product or set of users.
In some cases there is no security system to integrate with beyond perhaps a known list of user IDs and passwords. In these cases a straightforward login page can be created in a similar way to the method previously mentioned to ask for, and validate, a user ID and password before logging them into QlikView. The user directory could be anything like Active Directory, LDAP, SSO systems, Databases (SQL, Oracle etc), Web based systems such as Windows Live, Google accounts or Facebook login.