Private SaaS, a New Paradigm

The software-as-a-service (SaaS) method of delivering software has revolutionized our industry. With the SaaS market expected to grow from $3 trillion to $10 trillion by 2030, the future is bright. Organizations are increasingly adopting SaaS applications because they are managed and run on the providers’ servers. This offloads the responsibility to manage the infrastructure, availability, security and performance of software applications.

While this enables customers to simply rent the software and pay for only what they use, using SaaS isn’t always possible. Some verticals of SaaS, such as developer or security tools often have to interact with the organization’s codebase or production environment — this can be an absolute no-go for organizations with proprietary algorithms or sensitive data, especially in the fintech, health care, and government industries. Yet enterprises in those industries still need to use cutting-edge technologies and cannot afford outdated software.

In response, some software vendors offer their products as a self-managed version so that companies can keep it running within their infrastructure perimeter, satisfying the security and data protection needs. But setting up, running and scaling tools can be a complicated and resource-intensive task that companies may not want to take on. They take time and resources away from focusing on building their core product.

That’s why I believe there is a need for a new paradigm.

What’s Private SaaS?

Private SaaS is a variation of SaaS where the provider runs the software within the customer’s network but takes responsibility for managing and securing it. The provider’s private SaaS framework takes care of reliability, availability, upgrades and Day 2 operations. It splits the control plane and the data plane, allowing customer data to remain within their network.

Because the software is fully managed by the provider, the customer does not need to handle deployment, configuration, reliability, security, disaster recovery and upgrades. And since software data remains within the organization’s network, organizations have control over where to keep the data and how long to retain it, helping to achieve compliance with SOC2, HIPAA and GDPR. Finally, for tools dealing with a lot of data, such as log management and ETL, private SaaS can eliminate a lot of data transfer costs.

👁 Image

👁 Image

SaaS model:

• The vendor’s “Data Plane” (where the apps and software for each customer are hosted and running) is in the vendor’s network.
• The infrastructure — machines, memory, CPU, disk — is, therefore, provided by the vendor.

Then, for the vendor’s “Data Plane” to receive updates, the agents running on for each customer coordinate with the vendor’s Control Plane (which also resides in the same vendor network).

Private SaaS model:

• The vendor’s “Data Plane” lives in an environment within Customer A’s network and is therefore managed and controlled by Customer A.
• The infrastructure — machines, memory, CPU, disk — is provided by Customer A.
• Only the vendor’s “Control Plane” (which is responsible for what updates go out to the “Data Plane”) lives within the vendor’s infrastructure, while the tools and apps reside in the customer’s infrastructure.

OpsVerse Use of Private SaaS

At OpsVerse, we provide a managed DevOps tools platform that allows companies to use open source software such as Argo, Grafana, Jaeger and Prometheus. Our private SaaS offering is quite popular, with over 55% of our customers using it. This is mainly due to customers who desire to keep their data in house. From an information security (InfoSec) perspective, launching tools via private SaaS can enable them to remain compliant with data protection rules or any regulations they must meet.

An example is when customers run Argo CD via private SaaS. In order to understand why, we must first understand what Argo CD provides and how it works.

Argo CD is an open source, GitOps-based “continuous delivery” tool rapidly gaining in adoption and popularity. The term GitOps refers to a set of practices to manage infrastructure and application configurations using Git as a single source of truth. Argo CD — the “continuous delivery” part of the flow — monitors Git and ensures that the state of the infrastructure matches.

Therefore, Argo CD needs access to organizations’ Git repositories and production infrastructure (such as Kubernetes), where it needs to operate changes — which are both highly vulnerable assets. With private SaaS, both of these components stay within the organizations’ own networks, delivering the level of security that InfoSec teams want.

👁 Image

How to Build a Private SaaS

Building a private SaaS product can open up a new market for a company, but it is not without challenges.

One of the main challenges is to know the health of the private SaaS application. To ensure quality service, a vendor must have strong observability capabilities.

This includes collecting signals for:

• Metrics — to see application trends and set alerts.
• Logs — to see what exactly the apps are doing.
• Traces — to see which components of the app may act as bottlenecks.
• Events — to look for underlying infrastructure changes.

This can be achieved by implementing telemetry for all components of their applications. This ensures that the service is always up and running and allows vendors to know when to ship updates or maintenance for the parts running in the customer perimeter.

Another challenge is pushing out updates to applications running in private Saas. If network configuration does not allow egress and ingress to and from the customer perimeter, the vendor should duplicate the management cluster into the customer’s perimeter, so the agent never has to leave the perimeter when polling. This approach will keep the vendor’s auto-update framework consistent, but the customer will have an additional burden to operate the management cluster in coordination with the vendor.

If the customer’s network configuration only limits ingress from outside their perimeter, then a vendor-provided agent living on the customer’s perimeter is required. This agent will poll the vendor’s management cluster, download and install updates.

Solving issues on the customer’s cluster during an automatic update could also be a challenge. Vendors should ensure that the customer runs diagnostics and sends the report to the vendor for troubleshooting.

Private SaaS Is Just Getting Started

Government regulations for data security and privacy are ever-evolving, and compliance is always a challenge for engineering teams. It is estimated that 66% of countries have some sort of data privacy and consumer rights legislation, so we should expect that using SaaS will be increasingly challenging.

Organizations that cannot use SaaS are turning to OSS that they deploy and assemble in house, and the rise of Internal Developer Platforms (IDP) reflects this trend. However, they generally don’t have the time, bandwidth and skills required to develop subject-matter expertise to reliably run, maintain, and secure open source software. And for good reasons. A recent report found that 48% of organizations with more than 10,000 employees are challenged by complying with government requirements, and 30% reported that the security of their OSS stack was a top priority.

That’s why we believe the private SaaS concept is needed, and we are already seeing companies using similar methodologies. Do you think there is a need for this new concept? Are you building a product based on similar principles? Reach out to us! We’re happy to share what we’ve learned and to learn from others.