Think SaaS-y, even if you need to deploy on-prem.
Up until not so long ago, the state-of-the-art delivery model for software was On-Premise: the vendor delivered the software for download, to install it on the servers at the client’s premise. In the last decade or so however, primarily due to the rise of Cloud Computing, the SaaS based delivery model has become increasingly popular to the point where it is even the preferred model adopted by various enterprises.
Over the years, SaaS spending and adoption has just continued to rise. According to the Annual SaaS Trends report, in 2018 the average spend per employee for SaaS subscriptions ($2884) was higher than the cost of a new laptop ($1229 for an Apple Macbook Pro). Not only are businesses progressively adding more seats to their existing subscriptions, but the number of net new SaaS properties every year continues to rise.
It turns out there is SaaS for infrastructure as well!
Here I’m going to discuss the SaaS vs On-Premise delivery option for a specific class of applications that manage on-prem or cloud infrastructure and provide functionalities such as monitoring, provisioning, orchestration, cluster management, governance, security updates, etc. These applications interact with the data center or cloud infrastructure and may require companion software such as device agents that register with the SaaS application. Below we visit the typical IT concerns when it comes to implementing software solutions and examine how both SaaS and On-Premise compare against each other, with an emphasis on Infrastructure apps.
SaaS applications can be implemented much more quickly than packaged on-prem software. Users can get started instantly after having signed up for a subscription. Installation, configuration, and on-boarding of on-prem software requires time, resources, and money both for initial startup and ongoing maintenance.
However, it would be disingenuous to pretend that there is no separate installation of software required for infrastructure applications. These applications may require installation of companion software or configuration of proxies, tunnels to enable SaaS apps to access on-prem infrastructure. Additionally, installation of agents might be required. These components, though, are much more minor than what you are likely dealing with in full blown package software.
On-prem upgrades are often costly and time-consuming, where the IT staff owns the responsibility to plan, deploy, and validate upgrades. SaaS upgrades are easier to manage, iterative, and require little involvement of the part of internal IT staff.
Infrastructure apps sometimes have a device or server agent that needs to be compatible with the server version on SaaS. This has the potential of increasing IT involvement and responsibility. This can be managed by the SaaS vendor through good architecture design, one that utilizes a self-upgrading design where an upgrade of SaaS software automatically triggers an upgrade of required on-prem companion software components whenever required.
On-prem applications tend to offer more flexibility for businesses to customize their deployments. SaaS applications might not offer the same level of customization since generally SaaS-applications are multi-tenant and host multiple tenants/customers on the same instance.
However, the level of customization desirable for an application depends on the nature of the application itself. Consumer apps such as Slack and DropBox might require customization at the individual user level. For Infrastructure apps, customization tends to be more at the tenant or organization level and not at the individual user level.
SaaS requires very little to no IT support. The SaaS application provider takes responsibility for availability, security, HA and DR of the platform. IT involvement is generally for validation and customization purposes. On the other hand, for on-prem software, IT needs to take complete ownership of deployment, security, maintenance, and availability.
Infrastructure applications, specifically ones that interact with on-prem hardware do require IT to configure access, thereby increasing the effort required from none to marginal. The applications can largely circumvent this though by adopting an egress-only architecture, not requiring incoming access into the on-prem infrastructure and instead relying on outgoing connections originating from the on-prem devices.
SaaS pricing models are generally flexible, enabling businesses to subscribe and pay based on their usage. With SaaS applications there is no additional upgrade cost that needs to be budgeted, and SaaS applications minimize the cost related to IT support and maintenance.
Infrastructure apps do not change this equation and all SaaS cost benefits apply here as well. At times, such applications may include an additional fee for on-prem companion software which is paired to work with the main SaaS application. For example, there may be an on-prem region-specific orchestrator that is registered with the SaaS management portal. In such cases, the cost impact needs to be evaluated by adding the cost of subscriptions to the cost of these on-prem components.
Security and Compliance
On-prem solutions may require additional time and resources to properly secure. SaaS providers, in contrast, can potentially offer top-notch security and take care of the supervision of the servers and network. Enforcing baseline compliance policies setup for a tenant or organization is fairly straightforward in SaaS.
Sometimes, stringent policies around privacy, data sovereignty, and security may prevent some organizations from considering SaaS applications, but deep analysis of a SaaS application provider’s security, data isolation, and compliance procedures oftentimes addresses those concerns.
For Infrastructure applications, besides the general security and compliance concerns around data stored by SaaS apps, additional emphasis needs to be placed on operations performed on the on-prem or cloud infrastructure. Securing means of access to such devices, tuning level of access, ensuring provisioning operations do not expose vulnerabilities, etc are concerns specific to such applications.
Ops transparency may be limited with SaaS apps since a vendor team is in control of operations like backups, upgrades and so on, whereas for on-prem solutions, the IT team is in complete control of operations. However, this lack of transparency does come with the advantage of the fact that a SaaS provider with proper SRE and SLAs are managing operations on your behalf.
There are obvious benefits to choosing SaaS over on-premise such as time to value, operational cost savings etc but consumers should have a checklist of requirements for a SaaS offering to alleviate any concerns around data security and sovereignty. The checklist should be built keeping in mind the nature of the application and organization specific security and compliance policies.
On the other hand, if an on-premise solution is preferred because SaaS offerings do not satisfy the requirements or it’s just the policy in your organization, you can still make choices that get your implementation closer to a SaaS like environment. While an on-prem solution will always require IT involvement for operational aspects, the right on-prem product can make some of those operations much easier. An on-prem product that is enterprise ready with the following aspects built-in can simplify operations and minimize IT involvement.
Simplified Installation — Intuitive easy to use installer with detailed status reporting and appropriate error handling
Inline Product Upgrades — Ability to upgrade to newer product versions from within the product without having to download packages offline.
Ongoing Security updates — Timely and automated updates to product infrastructure to apply relevant security patches
High Availability — Ability to install product across failure domains for high availability. For example Virtual Machines deployed across compute clusters in a VMware datacenter.
Disaster Recovery — Built-in backup/restore capabilities with automatic failover and recovery.
Multi Tenancy — Built-in multi tenancy to provide sufficient isolation for users across teams/business units.
Governance Policies — Granular RBAC policies to easily onboard users and configure their usage.
Auditing — Built-in auditing to track user actions.
Simplified Log Management — Simplified retrieval and aggregation of product logs.