Over the past several decades a debate has raged between software as a service (SaaS) and on-premises (or in VPC) software delivery models. Both approaches make sense depending on the use case for the reasons that will be described below, however, enterprises should carefully evaluate each in order to determine the approach that best meets their needs.  

Another approach, called hosted software, attempts to bridge the cost and IT gaps between SaaS and on-premises software. Hosted software delivery models require vendors to operate software installations individually for each enterprise, giving each enterprise its own instance of the offering. This might sound like the best of both worlds, but considerable differences still remain between SaaS and “hosted” delivery. 

This blog aims to address two things: 1) Examine the differences between SaaS and hosted software delivery models in general; and 2) Understand how these two models compare when applied to Kubernetes management & operations, specifically Rancher (hosted software) and Rafay (SaaS).

This blog is not intended to provide a detailed feature comparison between these two vendors. Both vendors help companies overcome Kubernetes management & operations roadblocks. However, companies researching Kubernetes management and operation solutions should find this blog informative as they make vital decisions about the Kubernetes management vendor to partner with, and which consumption model is right for them.

First, let’s define the key characteristics of both SaaS and hosted software.

What is Software as a Service (SaaS)?

A fundamental tenet of SaaS is multi-tenancy. A single instance of the software runs on servers in the cloud and can be consumed by multiple companies in parallel.  Because the customer count may be dynamic, SaaS applications are designed to automatically scale and are typically metered by some consumption model that suits the given industry. SaaS enables software consumption over the Internet (i.e., delivery is from the cloud) without the cost, complexity, and IT management overhead associated with hardware and network management, scalability and availability, disaster recovery planning, etc., that are typically involved with on-premises (or in VPC) software.

The growth and adoption of SaaS in the enterprise can’t be understated. Recent research finds that the SaaS market is still growing by 18% per year globally. 

Why do enterprises choose SaaS? 70% of CIOs claim that agility and scalability are the top two motivators for using SaaS applications, but there are more reasons, including: 

• Deployment time: time to value is fast with SaaS, with deployment time measured in hours or days vs. months
• Robustness and reliability are included with an uptime guarantee
• Zero technical preparation and work from the enterprise is required, e.g.:  
  • No input is needed from the customer for sizing of service
  • No software installation & updates
  • Zero hardware sizing
  • Guaranteed network access and redundancy
  • Backup and data isolation
• Abstraction from the necessary hardware and related infrastructure
• Multi-Tenancy: Multiple users and groups can leverage the same application with isolation boundaries
• No upfront costs and flexible pay-as-you-go pricing model
• No need for hiring expensive and hard-to-find teams of technical experts

Although SaaS customers share a common infrastructure, logic exists so that each tenant has access to a separate and isolated view of the solution backed by SLAs to ensure reliability, governance, and security.

Another key benefit is that the SaaS vendor manages software feature improvements, patches, and security updates. Once done, every enterprise employing the service benefits without worrying about compatibility issues or testing with the underlying infrastructure of the solution. In the early days, one con of the SaaS approach was the lack of control and customization. However, with the advent of headless services and robust APIs, this is less of a concern today.

Net-net, the SaaS deployment model has made it much easier and cost-effective for enterprises to consume critical business and IT applications.

What is Hosted Software?

One step removed from on-premises software, hosted software requires enterprises to purchase a software license but rely on the software vendor to install, host, and maintain that software on dedicated hardware in a data center or in the cloud. The data center or cloud could be owned or provisioned by the customer (i.e., a private cloud), the vendor, or a third party. Typically, companies may have to play a part during some portions of the setup process, including infrastructure sizing, networking configuration, and testing. In addition, depending on the solution adopted, other components might be required such as databases, authentication services, firewalls and backup software. Because a new instance of the software needs to be set up for each customer, time to market for the initial install and future upgrades are typically longer than simply signing into a portal online.  

The technical work involved and total cost of ownership (TCO) comparison between SaaS and hosted software has been discussed for years. While they have similarities, distinct differences are essential to understand when choosing the optimal approach for your business. Let’s now compare and contrast the implications of SaaS vs. hosted software delivery models as they apply to Kubernetes management & operations market. 

How Hosted Software Differs From SaaS for Kubernetes Management & Operations

In order to alleviate the cost and overhead associated with on-premises software while claiming some of the benefits of SaaS, traditional software vendors have begun offering their products as hosted software. However, if a solution is designed from the ground up to be consumed by one team at a time, there is virtually no way to retrofit that to be multi-tenant SaaS. Multi-tenancy is too fundamental a paradigm to be plugged into an offering after the fact.

In the Kubernetes management and operations market, an excellent example of this is Hosted Rancher offering. Why is Rancher providing this option? Because, in Rancher’s own words, installing and operating a hosted Rancher controller can be quite burdensome for customers (source of two examples: www.rancher.com): 

“Focus on Day 2 operation”
“Teams can focus on deploying and managing more clusters and let our expert team handle the operational overhead of SUSE Rancher Hosted.”

“Lower Total Cost of Ownership”
“Offloading the overhead for managing your SUSE Rancher Hosted control plane not only reduces operational risk but is better economics.”

As a result of day 2 complexities involved with their on-premise Kubernetes management software, Rancher has developed Hosted Rancher. However, Hosted Rancher software was not designed to be SaaS. As a result, a team of operations personnel at Rancher manages one or more dedicated instances per Rancher customer. 

Here are several examples highlighting how Hosted Rancher compares to what enterprises should expect from a cloud-native, SaaS delivery model for Kubernetes management & operations:

 1. Multiple Tenants with Isolation

It is extremely common for enterprise operations teams to require separate environments with isolation boundaries for development, QA and production purposes. With a SaaS offering such as from Rafay, the ability to create an unlimited number and separate tenant/organizations is available to enterprises at no extra cost. 

The only way to achieve this with Hosted Rancher is to request another hosted instance of the controller, adding more complexity and cost. It is common for Rancher customers to run multiple controllers, each requiring their own maintenance and support.

2. Infrastructure Sizing

The supporting infrastructure needed to host a Rancher controller for an enterprise with 5 clusters is not the same as a customer with 50 clusters. As a result, the Hosted Rancher operations team will need to perform both initial and ongoing planning of the infrastructure required to operate numerous Rancher controllers. 

What happens if you need to scale the number of clusters on short notice? The underlying controller infrastructure can’t simply be scaled up automatically. Additional costs, along with the complexities of adding new resources, will invariably appear.

3. Timely Software Updates

Another item that should be considered with the Rancher hosted software model is the maintenance strategy (i.e., patches & upgrades). With SaaS, upgrades and enhancements are implemented once by the software vendor and are instantly made available to all customers. With Rancher’s hosted software model, this simply cannot happen given that each hosted instance is an independent instance per customer. This means Hosted Rancher controllers will be upgraded one at a time, and there is no guarantee that your instance will be upgraded in the timeframe you desire.

Instant patching and updates can be critical for customers, especially when new security vulnerabilities are identified. With a SaaS offering, all tenants are protected immediately with a single update. 

For bug fixes, all tenants will immediately benefit from the update when a patch or hotfix is published. With Rancher Hosted, the software update will be scheduled for some future date because it would be almost impossible to roll this out to all Rancher hosted instances simultaneously. 

4. Licensing Limitations

Hosted Rancher is only available to Rancher customers licensed with a Platinum support SKU. True SaaS offerings do not have any such limitations because the marginal cost of providing access to an additional customer is low. With SaaS, onboarding a new tenant/customer takes just a few seconds. In fact, eligible users should be able to sign up for a free trial and try the solution themselves. 

5. Technical Limitations

Other technical limitations are amplified significantly when a vendor offers a hosted software option. For instance, Rancher’s hosted software does not support the use of cloud credentials with IAM Roles for Amazon EKS lifecycle management. This may not be a showstopper for self-hosted Rancher deployments, but this is a critical security because AWS strongly recommends the use of IAM roles when engaged with 3rd party services (SaaS or hosted).

6. Security Posture and Compliance

For SaaS offerings, security and compliance is an important concern. As a result, enterprises can expect SaaS offerings to have SOC-2 Type 2 compliance and a continuously improving security posture for their service including but not limited to regular penetration tests, daily vulnerability scans of software components, and much more. It would be cost-prohibitive and impractical for a hosted software solution like Hosted Rancher to do this for every hosted customer instance. 

Which Kubernetes Management & Operations Deployment Model Is Ideal for You?

Ultimately, enterprises need to choose their preferred deployment model. 

Many enterprises are going to require air-gapped deployments and will prefer to deploy software on-premises or in a VPC. Both Rancher and Rafay support this option.

But if your business prefers to consume software as a service, there is really no upside in using a hosted offering. If you are ready to leverage the real power of Kubernetes without the challenges and delays of hardware sizing and procurement, software installation, configuration and maintenance of 3rd party hosting, sign up for a free trial of Rafay today.