Qlik Sense Deployment Options – Our Qlik Luminary’s Guide

Ometis’ in-house Qlik Luminary Chris Lofthouse looks at Qlik Sense deployment options in his latest blog. 

Over recent years, Qlik has transitioned from a Windows, on-premise-only platform to offering cloud, on-premise, SAAS (Software as a Service) and hybrid architectures for Windows and Kubernetes (Linux).

While this caters for all the use-cases of new and existing Qlik Sense customers further future-proofing their investment, typically where choice is plentiful, understanding becomes inevitably that bit more difficult. Here at Ometis, we continually have discussions around the best architecture with our customers and due to the increase in possibilities, we constantly keep it under review. As a result, in this post I’ve condensed as much of our advise as possible.

Qlik Sense Deployment Options

Firstly, I want to be clear on the terminology I use in this post because, let’s face it, these things mean something different from one person to the next:

• On-premise: In Qlik terms, we are talking about deploying Qlik Sense on your own managed infrastructure – that being either a physical server, virtual machine or your private-cloud solution. Alternatively, it also includes public cloud solutions such as AWS, Azure, Google Cloud, etc. It is possible to use either Qlik Sense Enterprise on Windows or Qlik Sense Enterprise on Kubernetes.
• SaaS: Currently, Qlik has two SaaS offerings, both using Qlik Sense Enterprise on Kubernetes, these are Qlik Sense Business and Qlik Sense Enterprise on Cloud Services. Both take the hassle out of managing your own infrastructure and performing upgrades. Qlik Sense Business acts as a low-barrier to entry for small groups, teams and organisations. On the other hand, Qlik Sense Enterprise on Cloud Services offers more capacity for more data-demanding organisations and can be deployed independently or as part of a hybrid deployment.
• Hybrid: As you may have guessed, this is a mixture of the previous two aforementioned options. Specifically, it is QSEoCS (Qlik Sense Enterprise on Cloud Services) combined with one or more of the on-premise options. Therefore, as an example, this could be QSEoCS combined with a phyical on-premise machine using QSEoW (Qlik Sense Enterprise on Windows), or QSEoCS combined with QSEoK (Qlik Sense Enterprise on Kubernetes) hosted in the (public) cloud forming a multi-cloud deployment, and the possibilities go on.

Hopefully it’s become clear now but the real question that needs answering first is on-premise or SaaS?

Qlik Deployment – On-premise vs SaaS

There’s lots of information on the internet which goes into detail about the strengths and weaknesses of both options, so I’ll largely skip over those and focus on the main factors. With on-premise you gain more control, particularly over customisation to the deployment (I’m talking mashups and server-side extensions), as well as the obvious security benefits and dedicated known resources, but with that comes greater costs to provision the infrastructure, maintain it and the skills required to keep it going. Whereas with SaaS you have more freedom to access the solution whenever and wherever you are and get up and running quickly too, as it is on hosted infrastructure. However, with that comes security and data protection (GDPR) concerns for companies with more sensitive data.

As a rule of thumb, I typically begin the discussion with customers and prospects by asking questions that might rule out the SaaS-only option. The reason I start with SaaS as my go-to deployment is simple, as part of your Qlik subscription you get access to a cloud tenant, so why wouldn’t use it if it’s included? Well, there are reasons which we’ll go into now. Below, is a non-exhaustive list of questions that may rule out running SaaS-only:

• Currently, Qlik has data centers in Dublin, Ireland; North Virginia, USA; and Sydney, Australia. Are you restricted on where the data must reside to regions outside of the previously listed data centers in order to be within a countries data protection laws?
• Do you want to avoid specific countries data laws such as the US Cloud act, that entitles the US government to request data stored by most major cloud providers even if it is outside the United States? Qlik use AWS data centers.
• Are you looking to extend Qlik’s functionality with a value-added products, for example Qlik NPrinting, Qlik Data Catalyst, Qlik Data Catalyst for QVDs, Qlik Insight Bot, Qlik Alerting, NodeGraph, etc?
• Are you likely to exceed the SaaS deployment capacity limits?
• Does your IT policy dictate a SaaS approach?

Answer yes to any of the above and you are likely ruling your organisation out of a SaaS only deployment but that doesn’t mean you can’t still leverage your included cloud tenant through a hybrid deployment. Let’s now look at some example questions that may decide whether you go down an on-premise-only deployment:

• Do you have highly sensitive data, including PII (Personal Identifiable Information), that you don’t want stored on public facing infrastructure?
• Do you have sufficient spare capacity internally to host Qlik?
• Does your IT policy dictate an on-premise approach?
• Do you lack the means to automate the push of data to the cloud or open your firewall to on-premise sources?
• Do you have Big Data?

Answer yes to some of the above and you are likely pushing yourself down the on-premise deployment. Interestingly, I touched on the second-to-last question (regarding connectivity) here, instead of in the SaaS list. This was deliberate. In my experience customers are largely happy to whitelist the DNS name of the cloud tenant to allow it to connect to on-premise sources, or have the facility to push extracts of data to the cloud, so that isn’t typically a deal breaker for SaaS-only deployments, but if it becomes the only sticking point then we typically switch to a hybrid model. It is worth noting that with tools like Dropbox and Google Drive, users can store files locally on their machines which can be automatically synchronised to the cloud where Qlik can connect to and reload the latest data from.

What are the software differences between SaaS and on-premise deployments?

Although both deployments are called Qlik Sense and they share much of the same capabilities, there are some differences. As I pointed out earlier, the SaaS offering runs the Kubernetes version and the majority of on-premise deployments I come across run Windows. Let’s break this now into three parts; Qlik Sense Business vs Qlik Sense Enterprise on Cloud Services (the battle of the SaaS offerings), Kubernetes vs Windows and SaaS vs on-premise.

Qlik Sense Business vs Qlik Sense Enterprise on cloud services:

The main difference is in the deployment capacity and sharing restrictions. Qlik Sense Business only permits the use of five shared spaces, which offers the ability to collaborate in the creation and consumption of content and therefore limits the organisation to five groups of users. Qlik Sense Enterprise on Cloud Services removes the shared space limits, increases the deployment capacity restrictions and introduces the concept of ‘Managed spaces’, which offers completely governed access to content.

Kubernetes vs Windows:

In many ways this is the main difference of all three. When Qlik built the Kuberentes version they took the decision to rebuild the Hub and QMC (Qlik Management Console). Whereas the Windows version allows for granular security rules, and a clearer distinction between content creation/consumption and administrative tasks, the Kubernetes version shifts some of the administrative responsibility to the user. Looking at the interfaces below, it’s quite literally night and day based on the different options:

In short, most if not all administrative tasks relating to an application is conducted in the Hub of the Kubernetes version, including publishing apps, granting user access to streams/spaces, scheduling reloads, etc. Not all of this can be said for Windows, where you would create reload schedules in the QMC, for example. The benefit of the Windows version is that it permits multiple triggers created per application and it’s possible to implement task chaining too, and the ability to add more granular security rules. There is a real trade-off between simplicity and control here. I see a real benefit to both options but I’d have to evaluate on a case-by-case basis to say which is right for an organisation.

It is important to highlight at this point that streams (Windows) and Spaces (Kubernetes) are different too. In the Windows version you develop apps in your isolated work stream and distribute apps across streams. On the other-hand, in Kubernetes, you have the concept of shared and managed spaces which is great for multi-developer collaboration. In a nutshell, managed spaces are the stream equivalent, however shared spaces permit an element of collaborative working, where multiple users can create content, such as sheets, together. It’s worth noting that only the owner can amend the data, however it does open channels for more immediate feedback from end-users which is very useful.

SaaS vs Windows:

The main thing I want to point out here is the release cadence. For SaaS, it’s continuous, meaning they can update the platform as regularly as daily, weekly, etc. The reality is actually more monthly from what I’ve noticed. For Windows, it’s every ten weeks; February, April, June, September and November. Both are therefore updated quite regularly and in the most part the functionality is consistent between the two. However, over the last 12 months we have started seeing more and more disparity between them. Typically in favour of the SaaS offerings and Kubernetes – functionality is prioritised in SaaS, then comes to Kubernetes a short period of time after, followed by Windows (and in some cases not at all). Being open and honest, this can be frustrating, particularly when using a hybrid deployment.

Battling the myths

Talking to clients, there are a couple incorrect assumptions I often come across which I feel are worth mentioning.

• You can create QVDs in the cloud, you are provided a ‘Data files’ area where these can be created and consumed from. As far as I’m aware it’s not possible to create sub-folders though.
• As of February 2020 visualisation extensions are now possible to import into the cloud versions.
• As of March 2020 you don’t need your own IDP (Identity Provider) for QSEoCS, you can use your Qlik account instead.

How to decide the best Qlik Sense deployment option for your organisation?

This is one of those questions that is not straight-forward to answer and without an actual discussion I wouldn’t be willing to answer! For an idea, I’ve formulated a rough question flowchart which may help:

But should you find yourself wanting some friendly, tailored advice then please do not hesitate to get in touch, and remember if you found this post useful remember to like and share through social media.

You can find Ometis on Twitter, LinkedIn, Facebook and YouTube.

By Chris Lofthouse #QlikLuminary
Follow @clofthouse89