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.
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:
Hopefully it’s become clear now but the real question that needs answering first is on-premise or 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:
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:
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.
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.
Talking to clients, there are a couple incorrect assumptions I often come across which I feel are worth mentioning.
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