Its the perfect time to be building SaaS (Software as a Service) applications. Businesses are more likely to outsource certain processes these days in order to stay lean.

If you are building a SaaS application in 2020, you’re in luck. There just couldn’t be a better time for doing this.

However, the Software as a Service landscape is witnessing several changes right now. These changes affect how you build your tech stack along with your business model.

In this article, we’ll quickly go through these shifts and understand how we can make our SaaS application ready for 2020.

Lets Start With Some Context

It’s important to understand the changes we are witnessing in the SaaS market before we start talking about tech. Here it goes:

1] Speed and performance need to be first class citizens.

Building applications on the cloud has never been easier. In order to stand out, we need to deliver features faster than our competition while keeping up with customer expectations.

However, speed isn’t the only factor we must consider. Maintaining a superior customer experience is equally important.

But here’s the catch.

We need to do all of this with a high degree of reliability and performance while keeping the costs low. This puts a lot of strain on our tech stack.

The database quickly becomes the bottleneck in most cases.

The only way out is using technologies specialized for a particular use case which can squeeze out every bit of juice from our infrastructure.

2] You need to be ready to deliver on premise.

The industry is moving rapidly towards this ownership model.

Due to the growing security concerns, companies want to have more control over their data. This, by definition, extends to the applications handling this data.

What this means for you is that you may be asked to deploy your entire SaaS application on the client’s cloud environment.

This seems to go against the principles of SaaS. I mean, what about the whole as a Service thing right?

Like it or not, this is what we’ve come to.

You might find a “Dedicated” pricing tier for several SaaS applications these days. Deployment to custom environments is precisely what they are referring to in most cases.

More importantly, we cannot turn down a sale when the opportunity arrives, right? 😜

3] Your tech stack cannot be static.

This is more or less an extension to the previous point.

A client may have their own tools setup which they might be familiar with. They would appreciate the fact (and might even demand) that your app work with their software.

A classic example would be using the databases of their choice.

It does make sense from their perspective. I most certainly wouldn’t use a software based on HDFS that I have absolutely no idea about. 😅

I know switching out a database could have implications. For example, you might lose out on performance.

But they aren’t building a planet-scale SaaS application like you. It’s a single-tenant application for them.

So what does this mean for you?

Each one of your microservices should work with virtually infinite number of databases. Okay okay, infinite might be a bit too much, but you would have to support the most common ones.

We need to be prepared to support the client’s environment to the best extend possible.

Finding A Way Forward

I understand that there are a lot more factors involved here.

We haven’t even touched upon the subject of specialized infrastructure requirement as in case of AI or image processing.

I will try to tackle the aspects mentioned above in this post. Hit me up on twitter if you wish to have detailed discussions on this subject.

1] Decouple business logic from technologies.

High quality features require the use of specialized technologies.

You cannot expect Postgres to crunch through terabytes worth of data. Similarly, MySQL wasn’t built to handle full-text search at scale.

Such use cases require niche technologies.

For example, data warehouses like Big Query and Druid can be used for serving analytics while Elasticsearch can take care of… well… search! 🤣

Now before you go all crazy and start exploring all the cool tech I’ve mentioned, consider this.

Your team will have to be diverse enough to use these technologies in production.

For a SaaS startup in its early stages, this could be taxing.

More importantly, the overhead of administration for a diverse tech stack is huge. Things like deciding and documenting which feature is built using what and managing permissions can be a lot to handle.

The solution is using a data layer to decouple business logic from specific technologies.

Time to break this down.

Generally, our SaaS application talks to technologies like our database directly.

While we do not need to manage things like databases this days, we still need to learn how to use it.

This works fine in the initial days. But as our applications and customers demand more and more, we need to incorporate more and more technologies.

An example would be splitting high volume data (like messaging and logs) to a NoSQL database like MongoDB.

But this means our teams need to learn how to use MongoDB. That’s a lot of effort!

Let’s try another approach instead.

What if your business logic or code would talk to a service instead of the database directly. Let’s call this service a “Data Layer”.

Now imagine if this Data Layer could talk to multiple databases while exposing a consistent API. It would be the Data Layer’s responsibility to initialize the necessary drivers and fire the appropriate queries for each database.

This means we don’t need to go out and learn how to use each database as long as we familiarize ourselves with the Data Layer’s API.

Sounds cool right?

Space Cloud is one such data layer. To be more precise:

Space Cloud is an Open Source Firebase + Heroku which lets you develop, scale and secure serverless applications.

Space Cloud offers a consistent GraphQL API for each database it supports.

This is precisely what we need.

As long as we can use Space Cloud, we don’t need to worry about learning all the databases it supports.

In addition to database interoperability, Space Cloud’s GraphQL API can be accessed securely from the frontend as well. No need to rewrite monotonous CRUD APIs ever again!

2] Kubernetes all the way.

Containers are a great way to make our applications vendor agnostic. This enables us to deploy to any environments which support containers.

And what’s the best way to run containers? Kubernetes!!!

Kubernetes has become the defacto for running containers. Each cloud provider supports a managed Kubernetes offering. It not that difficult to run Kubernetes on-premise either. There is a managed service for that too.

I can go on and on about why Kubernetes is so awesome! But let’s start with a reality check first.

Kubernetes is hard!

It took me months to become confident enough to use it in production.

I’m sure you can figure it out in 2 weeks! But I’ve got a burning question.

Why should you?

Why should you spend time tinkering with Kubernetes? Don’t you have a startup to run? Don’t you have a product to build?

I’m sure you know what’s coming.

Space Cloud helps you with deploying your SaaS application to Kubernetes as well.

It natively integrates with Kubernetes, so you don’t have to worry about it.

It doesn’t matter if your SaaS application is a monolith or a bunch of microservices. All you need to do is space-cli deploy, and off you go.

Space Cloud will deploy you SaaS application to Mars if it has to. We are one step ahead of Elon Musk in that regard. Why do you think we named our startup Space Up Tech? 😜

In addition to all this goodness, Space Cloud integrates with Istio as well. This means you get all the awesomeness of a Service Mesh by default.

Did I mention that all of this works with Docker too?

You can develop your SaaS application on your laptop using Docker and expect everything to work exactly the same on Kubernetes.

3] Time to go tech agnostic.

Using a Data Layer tends to solve this problem quite well.

Building our SaaS applications against a Data Layer like Space Cloud means that we can switch out the underlying database without having to change the code.

Here’s an example of querying the users table where email is equal to user@example.com in Mongo and Postgres using Space Cloud.

For Postgres:

{
  users( where: { email: { _eq: "user@example.com" } } ) @db {
    name
    email
    dob
  }
}

Here’s the same query for Mongo

{
  users( where: { email: { _eq: "user@example.com" } } ) @db {
    name
    email
    dob
  }
}

Notice any difference? I would be surprised if you do since they are exactly the same queries.

The difference is in what @db is actually referring to. In one case its Postgres while in another its Mongo.

You can literally switch out the underlying database without having to change any code whatsoever.

This applies for microservices as well provided their APIs remain consistent.

Now that’s what I call API consistency.

Wrapping Up

As this point, I think we can declare Space Cloud to be the platform to develop modern SaaS applications

Yeah, yeah! I’m getting a bit ahead of myself. I’m sorry!

But I know you see some merit in that claim. Don’t you?

You don’t have to take my word for it. Try Space Cloud out for yourself. It’s open-source after all. Here’s a step-by-step getting started guide you can try out.

Don’t forget to share this post and leave us a star on GitHub!