Bring-Your-Own-Account as a Service - Deploy SaaS on customer’s chosen infrastructure

A recent trend has surfaced among our B2B SaaS customers and potential clients: the desire to implement their services within the infrastructure of their end customers, whether it's in the cloud or on physical servers.

This may appear counterintuitive, especially considering the prevailing belief over the past 15 years that the cloud was the solution for nearly everything. However, when you consider the increasing emphasis on security and cost control, such demands make perfect sense.

‍

Here’s the why

In simpler terms, some customers believe that the data they entrust to a B2B SaaS provider is so critical that it should be stored on their secure private cloud or even on their premises. Additionally, from a cost perspective, this approach allows them to maximize their previous investments in cloud services or their own data centers.

Ideally, the math should work out perfectly. The customer doesn't pay extra for capacity they already have, and the vendor doesn't incur additional infrastructure costs, leading to improved gross margins.

‍

The tricky part

However, offering this capability is not straightforward for SaaS providers. It typically involves project setup, resource allocation, delays, and potential additional costs. Actually, most of these customer requests are eventually abandoned due to the higher costs quoted by the vendor, delays, and security concerns.

‍

The how

As you might have guessed, a solution has emerged: infrastructure agnostic Internal Developer Platform (IDP). An IDP provides developers with an environment where they can create, enhance, test, and deploy their code and applications, irrespective of the underlying infrastructure and in compliance with preset IT policies. For container-based applications, an IDP abstracts and enhances Kubernetes, allowing developers to work with multiple clusters without managing them directly. This represents the current state-of-the-art evolution of DevOps practices.

Here's the clever part: Imagine interacting with Kubernetes clusters across multiple clouds through a single pane of glass. Instead of handling individual configurations and requirements for each environment, a pull-based operator is installed on each cluster. Because it operates on a pull basis, it establishes a secure connection to the control plane from the local network, meeting even the strictest security standards. As a result, the vendor can manage the remotely hosted application seamlessly, as if it were in-house, without incurring additional costs.

Concerned about vendor lock-in? You're right to be cautious. mogenius has developed its pull-based operator based on an open-source tool called punq, which is licensed under Apache 2.0. Deploying this operator is straightforward through a transparent helm chart, giving customers full control. punq offers all the necessary visibility and control over the cluster, should the customer need to take over operations.

In essence, any B2B SaaS vendor can benefit from this solution by simply implementing an IDP that offers "Bring Your Own Cloud as a Service" on top of their existing CI/CD pipeline or as a replacement for it.

‍

Going further

But that's not all. Let's reverse the problem. If you're a large enterprise using dozens of SaaS solutions for daily operations, some of which handle critical data, while others do not, this IDP could be a game-changer. All these solutions consume cloud resources that could count towards the commitment you negotiated with a major cloud provider instead of self-sourcing or using the marketplace without BYOC. By implementing an IDP, you could provide central access to your SaaS vendors, enabling them to build, deploy, maintain, and monitor their services on your private infrastructure according to your rules.

For further information or to start a free trial, please check our dedicated solution page

‍