Platform.sh as a SaaS development and management platform

The Software as a Service (SaaS) model operates by treating each customer as a tenant of the application. To use the SaaS application, each tenant is usually required to pay a subscription. There are three main tenancy models for a SaaS application:

• Multi-tenant architecture: All customers share the same application instance and database, but their data is logically separated and isolated.

• Single-tenant architecture: Each customer has their own instance of the application and database, running in their own environment.

• Mixed-tenant architecture: This model combines both architectures above. 

In this article we'll focus on specific challenges brought about by the single-tenant model, including developing, deploying, and keeping up-to-date several instances of the SaaS application. 

Just another web app

First things first: a SaaS application is, at its core, just another ordinary web application. As such, the product engineering team that works on it can’t help but benefit from the features offered by Platform.sh, provided we can support all the components of their tech stack—which we most likely can. Refer to this list of stacks we support (keep in mind there are more than the ones mentioned here!). In fact, some of our clients are SaaS companies employing the multi-tenant model, benefiting from the excellent features our PaaS provides to their engineering teams. 

But how can we push the boundaries by leveraging Platform.sh for scaling and managing single-tenant SaaS applications? 

Single tenant: a fleet of web applications

Enabling organizations to run thousands of apps and websites easily is already part of our mission.

The peculiar thing about a single-tenant SaaS application is that the many instances resulting from the serial deployment of the same app will all share the same codebase.

Yet, by default, each Platform.sh project is backed and driven by its very own git repository. At first glance, this would seem to suggest that managing a single-tenant SaaS model on Platform.sh might actually be a nightmare! 

Thankfully, that is not the case. 

If your SaaS is single-tenant, then the main pain point is that you need to build automation and pipelines to: 

• Deploy new instances of your SaaS application every time a new subscription is purchased
• Test new features and pre-releases on production-like environments
• Roll out new releases/code changes to all the active instances of your SaaS application

We already know that Platform.sh helps with a lot of that. What I want to show you today is how to leverage two of our features that will make all of that even easier.

Enter source integrations and source operations

Source Integrations allows you to keep your code in a third-party repository that’s then linked to your Platform.sh project. The result is that whatever happens on that repository is automatically reflected on the project’s repository. The hidden power of this feature is that you can also link the same third-party repository to as many Platform.sh projects as you like. 

Since, however, that feature may have limits (for instance, GitHub has a limit of 20 webhooks per repository), our very own Source Operations feature completes this picture. Both features can be used together and in a complementary fashion.

So, for example, you can now have 10, 100, 1000 projects all driven by the same git repository. 

And that opens up new possibilities. 
 

Create a new instance

A new customer comes along and buys a subscription to your SaaS application. 

When using Source Integrations all you have to do is to (a) create a new empty project, and  (b) create a new integration between the repository that holds your SaaS app’s codebase and your project. This latter action will effectively deploy a new instance of your SaaS application to the newly created project. 

Don’t worry, you may automate this by using either our CLI or our API. For example, you could run something as simple as the following from a CI tool:

$ platform project:create --region='eu-2.platform.sh' --title='A SaaS' --environments=1 --storage=5 --default-branch=main --plan=development --org=’your-org’ --yes

$ platform integration:add --type github --repository your-org/your-repo --token TOKEN -p project_id_from_previous_command

Or you could use our API to build the functionality above directly into the software that is processing your purchases.

Similarly, with Source Operations, one must essentially create an empty project and then initialize the main environment with a template already configured to use Source Operations to pull the code down from the repository where development occurs.

Develop and test

One of our flagship features is the ability to clone production into a non-prod environment in a matter of minutes, whenever we branch off the main branch (the one that powers the prod environment). That affords the developer the luxury of having a live-like environment where they can deploy and test their feature changes. 

When a source integration (for example, GitHub) is active on a Platform.sh project, the default behavior is that a feature environment is created whenever a new pull request is issued. If more than one project is linked to the same external repository, then that happens for each of those projects, provided the integration is configured to do so on each of them.

Indeed, if you create all your source integrations according to the default settings, the result will be that every time you issue a new pull request on the repository that holds the code for your SaaS application, all the instances on Platform.sh connected to that repository will create a new environment. 

Now, you might want that, or you might not—you are free to configure each integration as you prefer. 

That said, you probably want to reserve a specific pool of your instances for testing, so that you don’t end up creating too many environments every time you issue a new pull request! As a matter of fact, we have already seen how external tools like GitHub will likely have a limit on the number of projects that can be linked to a repository. 

Now seems like a good time for me to suggest a strategy to you: use Source Integrations to link your development repository to the instances you want to use for automated testing, and instead use Source Operations for all your other instances, where new releases can be pulled down when ready and tested.

Roll out new features to production

Regardless of how many instances you have chosen to test your changes, at some point those changes will be ready. For the sake of simplicity, let’s assume you have chosen to use a micro-release model. For example, every pull request that you have is a new release candidate on its own, and merging it will result in the changes going directly to production, whether they are instances linked with Source Integrations or Source Operations. 

(This might seem scary, but if you keep your changes small and you have lots of automated testing, it’s actually a very productive and lean way of rolling out new changes.)

As I was saying: at some point those changes will be ready to merge. And when you do merge them, the new commits will be pushed to those instances linked via Source Integrations, and eventually land to the instances pulling down updates via Source Operations.

The result is the same either way: the new release of your SaaS application is instantly rolled out to all active instances of your application on Platform.sh. Job well done!

Leverage the power of the ROI 

Platform.sh is uniquely positioned to provide  two more benefits you can take advantage of  here at Platform.sh.

1. You can  leverage the power of the massive ROI that it will afford you while building your SaaS offering
2. You can choose to get into the PaaS market yourself, via our OEM programme

And…they are not mutually exclusive. You can do both at the same time! And when you do, that’s when you are in a truly unique position—you can offer a seamless upgrade path from the SaaS version of your product to the PaaS version. In a single-tenant model, that essentially means giving your customer access to the very same Platform.sh project that has been behind their application’s instance all along! 

How neat is that? 

Why not get in touch and make it happen? 

I am sure that by this point you feel the same way I do: if you are in the SaaS market, Platform.sh is an incredible solution that will address a plethora of needs. 

And if you are thinking of offering both a SaaS and a PaaS version of your product, then Platform.sh becomes the perfect solution. Get in touch! Together, we can make it happen!