BaaS (Back-End-as-a-Service): Single, multi tenant and serverless SaaS architecture

How Marionette software is created, managed, and operated

Our customers represent the different companies that have purchased Marionette software. Each of these customers is essentially running in a standalone environment where they have installed Marionette (and more specifically - where Marionette has been installed by our devops). 

In this mode, each customer’s installation is treated as a standalone environment that is dedicated to that customer. This means that customers view themselves as the owners of these environments, potentially requesting one-off customisation or unique configurations that support their needs. Our customers can control which version of Marionette they are running. 

It's easy to imagine how this dynamic impacts the operational footprint of us as a software provider. The more we allow customers to have one-off environments, the more challenging it becomes to manage, update, and support the varying configurations of each customer. This need for one-off environments requires us to create “dedicated teams” that provide separate management and operations experience for each customer. This model generally introduces incremental expenses for each new customer that is onboarded. We use the ability to provide one-off customisation as a sales tool, allowing new customers to impose requirements that are unique to their environment. While the customer count and growth of the business remains modest, this model seems perfectly sustainable. As TuneX begins to have broader success, however, the constraints of this model begin to create real challenges. Imagine, for example, a scenario where TuneX’s business reaches a significant growth spike that has we adding lots of new customers at a rapid pace. This growth will begin to add to the operational overhead, management complexity, cost, and a host of other issues. Imagine what it would mean to add 10 or 100 new customers in this model. I assume you haven't forgotten what our devops does. Do we believe that god loves our devops with an unconditional love? Ultimately, the overhead and impact of this model can begin to fundamentally undermine the success of a software business. The first pain point might be operational efficiency. The incremental staffing and costs associated with bringing on customers begins to erode the margins of the business. However, operational issues are just part of the challenge. The real issue is that this model, as it scales, directly begins to impact the business’s ability to release new features and keep pace with the market. When each customer has their own environment, we must balance a host of update, migration, and customer requirements as they attempt to introduce new capabilities into their system.

This typically leads to longer and more complex release cycles, which tends to reduce the number of releases that are made each year. More importantly, this complexity has back-end team devoting more time to analysing each new feature long before it’s released to a customer. Back-end team begins to be more focused on validating new features and less on the speed of delivery. The overhead of releasing new features becomes so significant that back-end team becomes more focused on the mechanics of testing, and less on the new functionality that drives the innovation of their offering. In this slower, more cautious mode, team tends to have long cycle times that put larger and larger gaps between the inception of an idea and when it lands in the hands of a customer. Overall, this can hinder our ability to react to market dynamics and competitive pressures.

Back-end as a service: a kind of work on the mistakes

Well, we are going to turn to a model that allows us to create a single, unified experience that allows customers to be managed and operated collectively. The term SaaS is used to describe a business and delivery model. SaaS is an environment where all of our customers are managed, onboarded, billed, and operated through a shared model.

Adopting a “service” model is more than just marketing or terminology. In a service mindset, we will find ourself moving away from aspects of the traditional product-based approach to development. While features and functionality are certainly important to every product, SaaS places more emphasis on the experience customers will have with our service.

What does this mean? In a service-centric model, we think more about how customers are onboarded to our service, how quickly they achieve value, and how rapidly we can introduce features that address customer needs. Details associated with how our service is built, operated, and managed are out of our customer’s view. In this mode, we think about this SaaS service as we would any other service we might consume.

The Application Service Provider (TuneX) is essentially “shrink-wrapping” the Marionette software to business users via the internet, giving users a user-friendly and feature-rich experience with zero investment in maintenance.

SaaS applications can quickly add functionality to client applications with minimal investment in in-house development. Furthermore, integration is usually a breeze to ensure short time-to-value, thus enabling faster time-to-market with optimal quality.

The microservice architecture (our main SaaS architecture pattern) is powered by Application Programming Interfaces (APIs). All functions are broken down to independent modules that can be deployed separately as required. The APIs then allow these modules to communicate with each other and sync their independent processes to work as one single entity. Each service can be upgraded, updated, and scaled separately for added flexibility.

The customer environments are renamed to tenants. This notion of a tenant will be foundational to SaaS. The basic idea is that we have a single SaaS environment, and each one of our customers is viewed as a tenant of that environment, consuming the resources they need. A tenant could be a company with many users, or it could correlate directly to an individual user. All of the tenants in this environment are running the same version of Marionette. New features can be deployed to all tenants by a single, shared process.

Single-Tenant Architecture (SaaS architecture pattern). It basically caters to one customer at a time. The meaning of this is clear – there is a dedicated software instance, single infrastructure, and one database that is serving the entity that is paying for the service. There is no sharing whatsoever and the entire development environment is dedicated to one client at a time.

Open

Multi Tenant Architecture (SOA). Unlike Single-Tenant architecture, the Multi-Tenant variation is more focused on sharing resources, especially software instances and databases. However, each tenant’s data is protected and saved in different places for obvious reasons. The financial benefits of this methodology are clear – having multiple customers allows to lower the environment and infrastructure costs significantly.

Open

So we have the infrastructure of our SaaS environment, and tenants that consume the infrastructure of that environment. The amount of resources consumed by each tenant can vary. These tenants are also managed, billed, and operated collectively.

Single vs Multi Tenant SaaS Architecture

Single-tenant architecture performs better on the security front, which also makes it easier for businesses to demonstrate ongoing compliance. The security risks are simply more isolated. We also have more control on what’s going on the customisation and personalisation fronts. But that’s where the advantages more or less end when it comes to single-tenant SaaS architecture.

Single-tenant SaaS architecture allows seamless and smooth cost-sharing for serviceability, ongoing governance, and deployments. Resource utilisation is significantly improved and so is the adding/onboarding of new customers. Furthermore, scaling up becomes much easier since we have more computing capacity and more free resources on-demand to get the job done fast.

Multi-Tenant vs Multi-Instance Architecture. The multi-instance SaaS architecture is another variation. Just as the name suggests, there is no resource-juggling involved with this methodology. There are separate software instances (data items) that simply run parallel to one another. Unlike multi-tenant scenarios, there are no buffers or remote machines involved, which significantly improves performance.

Another advantage multi-instances have over multi-tenancy is that data is completely isolated, which means that there are minimal security risks involved. Each team has its private database and ecosystem, which means that there is little to no incentive for hackers. Scaling up is also much easier and so is availability, since single faults can lead to multiple downtimes in multi-tenant environments.

Multi-instance setups have their downsides. They’re less cost-effective and are harder to maintain and deploy frequently, an important DevOps requirement.

If we have customers looking for extremely high levels of reliability, security, and customisation, single tenancy might be the way to go. It is also easier to migrate to new environments and perform quick backups (and recoveries). Just keep in mind that the SaaS route will come at a price, literally. These SaaS ecosystems are often under-utilised and very costly to configure, manage, and maintain. Our customer requirements and behaviours should dictate our SaaS architecture choice. This is the only way to achieve sustainable growth and steer clear of situations where our development team has to rebuild everything from scratch. SaaS is a profitable, smooth, and manageable methodology. But this is valid only if we minimise operational costs and work.

Multi-tenant SaaS architecture is the better option if we want to create a scalable business model that is flexible and versatile. Here are some benefits.

Lower Maintenance Requirements – All ongoing maintenance costs can be baked into our pricing models. Updates and patches apply to all users.
Cost and Resource Saving – Everything is shared – databases, applications, services, and resources. The result – lowered operational costs.
Feature Rich and User Friendly – Onboarding is significantly faster and easier. Self-service features enhance customer experience and brand performance.
Improved Efficiency – While this requires the right infrastructure and tools, all users can ideally get the same level of service and performance.
Better Scalability – All of the aforementioned benefits allow multi-tenant centric businesses to scale up faster thanks to the added elasticity.

Note: make sure that we are secure and compliant with the latest data privacy laws like GDPR, CCPA, and other ones relevant to our geolocation.

Serverless architecture can operate as a BaaS (Back-End-as-a-Service), where the application’s backend is primarily on the cloud. It can also be a FaaS (Function-as-a-Service), where the application runs the code via various event triggers. In other words, functions are evoked on-demand, which allows businesses to enjoy a wide range of benefits.

Here are just a few of them.

Quick(er) Deployment – Zero provisioning needs. Automatic scaling.
Integration – Agile-friendly, works well with microservices, less complex.
Focus on UI/UX – client development teams can focus on features/frontend.
Flexible Infrastructure – Buy servers on-demand. Scale up (or down) fast.
Better Latency – Access points all around the world for better performance.

A well-planned and executed SaaS architecture can have high levels of fault tolerance and allow you to make sure disaster recovery will not be a disaster.

Summing Up. Here are the top three ways to make sure our SaaS app will succeed:

Self Service – Make your SaaS application as self-serving as possible. The more our customer needs to contact the support team to get things done, the less likely he is to stay with our brand. Registering, setting up a password, learning about new features, and eventually upgrading memberships – all of these actions should be user-friendly with the end-user in mind.
Multi-Tenancy – Once our SaaS application is able to serve more than one customer, we can enjoy more flexibility. This means we can scale up faster with no technical or operational constraints. Our application/s should also have the ability to accommodate new third-party applications and external tags for added functionality and customisations benefits.
Microservices – Embracing microservices will help us further simplify our ecosystem for easier and smoother maintenance (and upgrades). It will also become easier to pin-point issues and solve them without painful downtime or roll-backs that can damage our brand reputation.

Architectural considerations for identity in a multi tenant solution

Identity is an important aspect of any multi tenant solution. The identity components of our application are responsible for both of the following:

Verifying who a user is (authentication).
Enforcing the user's permissions within the scope of a tenant (authorisation).

Our customers might also wish to authorise external applications to access their data or to integrate to our solution. A user's identity determines what information a user or service will get access to. It's important that we consider our identity requirements, in order to isolate our application and data between tenants.
Note the authentication and authorisation services, within multi tenant SaaS applications, are usually provided by a third-party identity provider (IdP). An identity provider is usually an integral part of an identity as a service (IDaaS) platform. Building our own IdP is complex, expensive, and difficult to build securely. Building our own identity provider is a real headache.

A few words about the pricing strategy

Though there are no hard and fast pricing rules, as the SaaS business model has evolved, several proven pricing strategies have emerged.

The freemium model allows users to choose between free and premium features. Typically, an app’s core features cast a wide net and appeal to the widest possible audience. To bring in money with such an app, it’s necessary to convert free users to paid (or “premium”) users by offering an advanced set of features for a one-time or monthly fee.

The pay as you go model works the following way: the more features users need, the more they pay. This model works well with software companies like Amazon that charge users for the number of API requests their app sends to the server within a particular period of time. SMM platforms or accounting apps can also be monetised this way: the price will depend on the number of scheduled posts or generated invoices.
Tiered pricing aims to offer different packages for users depending on their needs and budget. The idea of this pricing model is similar to the previous: the more features our customers use, the more they pay. However, the revenue for us is more predictable as we provide monthly packages.

How to design, deploy, and architect our multi-tenant BaaS application in the cloud

SaaS solution includes some services that give us the ability to manage and operate our tenants through a single, unified experience.

The overall landscape of a SaaS architecture

The application plane of a SaaS environment is where the multi-tenant functionality of Marionette resides. SaaS application represents the tenant experience/application for our solution. This is the surface that tenants touch to interact with our SaaS application. Then there are the backend services that represent business logic and functional elements of a SaaS solution. These are microservices or some other packaging of our application services. Provisioning of resources for tenants during onboarding is placed in the application domain, because the resources it must provision and configure are more directly connected to services that are created and configured in the application plane.
The core services within the control plane represent the collection of services that are used to orchestrate your multi-tenant experience. These services are global to all tenants.
Administration application represents a web application, a CLI, or an API that might be used by a SaaS provider to manage the multi-tenant environment.

That may sound alarming, but it has long been known that back-end services are really a mishmash of many different functionalities and it is not very interesting now. Hence, it makes no sense at all to discuss Application services here, but there are the typical services in the control plane that are used to onboard, manage, and operate a SaaS environment. It may be helpful to further highlight the role of some of these services to highlight their scope and purpose in a SaaS environment. Now I would like to indicate in general terms how this construction can be carried through. The following provides a brief summary of each of these services:

Onboarding – every SaaS solution must provide a frictionless mechanism for introducing new tenants into our SaaS environment. This can be a self-service sign-up page or an internally managed experience. Either way, a SaaS solution should do all that it can remove internal and external friction from this experience and ensure stability, efficiency, and repeatability for this process. It plays an essential role in supporting the growth and scale of a SaaS business. Generally, this service orchestrates other services to create users, tenant, isolation policies, provision, and per-tenant resources.

Billing – as part of adopting SaaS, we embrace new billing models. We may also explore integration with third-party billing providers. This core service is largely focused on supporting the onboarding of new tenants, and collecting consumption and activity data that is used to generate bills for tenants.

Metrics – we rely heavily on our ability to capture and analyse rich metric data that brings more visibility to how tenants use their system, how they consume resources, and how our tenants engage their systems. This data may be used to shape operational, product, and business strategies.

Identity – SaaS systems need a clear way to connect users to tenants that will bring tenant context to the authentication and authorisation experience of their solutions. This influences both the onboarding experience and the overall management of user profiles.

Tenant – this service provides a way to centralise the policies, attributes, and state of tenants. The key is that tenants are not individual users. In fact, a tenant is likely associated with many users.

Admin user management – our SaaS must support both tenant users and admin users. The admin users represent the administrators of a SaaS provider. They will log into our operational experience to monitor and manage your SaaS environment.

The core steps to build a SaaS MVP

Full-scale SaaS solutions are budget-, resource-, and time-consuming to build from the start. MVPs has much lower budgets yet are great for checking if our product’s core functionality is appreciated by end users. We require an MVP as a basic version of BaaS that contains only the most essential features needed to meet the needs of early customers.

Some must-have technical qualities

The first thing we need to do when building a SaaS solution is make sure our customers know their data is secure — especially if we’re using public cloud services. Our system is gathering and processing personal data, therefore we need to ensure that only the minimum required data is collected and that it’s thoroughly protected. We have to protect data from unauthorised access from the outside and guarantee that users won’t be able to access the data of other users. Techniques we may want to use here are multi-factor authentication, encryption, multi-tenancy, and separate databases for each user. Other side is how to make sure we use secure libraries and other third-party components.

SaaS systems usually service a huge number of users, and this should be reflected in the architecture, even at the MVP stage. Our MVP is designed to handle a big number of users. Our way of solving this issue should be built into the software architecture, making our SaaS project inherently scalable. For example, we can use multiple instances of software when capacity is exceeded. By planning the application’s scalability at the early MVP stage, we save yourself from troubles and extra expenses later.

Users need to feel comfortable using our SaaS solution. Well additional features and visual design are critical factors for proper user experience, but when it comes to an MVP, they’re less important. Many users will be able to overlook user interface flaws and the absence of basic features if the product is focused and answers their needs. However, one thing people will not be able to overlook is performance. We need to create a fast and responsive system capable of reacting to user actions in a psychologically comfortable 300 milliseconds or less. In some cases, heavy optimisation will be required, but this is one area where we shouldn’t cut corners, even for an MVP.

Some clouds can be better than others depending on our project’s specifics and goals. We should wisely choose a cloud provider during the MVP stage so that later we can easily and conveniently expand our SaaS solution to a full-scale product without needing to migrate it to another cloud. To do that, Big D, please pay attention to pricing options, storage terms, supported tools and frameworks, and other computing specifics. Note that cloud providers and developers share responsibility for data security in the cloud. So make sure to check service-level agreements for areas of cybersecurity responsibility for cloud vendors and application developers before you choose a provider. Leading cloud vendors like AWS, Microsoft Azure, and Google Cloud offer convenient development environments, a variety of tools, and different deployment options to help us build an efficient SaaS solution.

TL;DR: Planning our Minimum Viable Product

Step 1: Identify and understand the business needs. Identifying the customer pain points

• Users can easily register and use our service without any assistance from the admin or support team. Additionally, set-up details, including uses for each function, should be available on-demand within this same software itself, so there’s no need to request help outside its boundaries. User registration process is done manually in MVP.

• Easy servicing of many customers on one platform. Multi-tenant BaaS is an architecture that allows for the easy servicing of many customers on one platform. This makes it possible to share resources like code, infrastructure, and even database instances among all users in our company, which means we can expand services without increasing costs or making things difficult by maintaining multiple apps simultaneously.

• A capability of integrating with other applications, so it’s essential that BaaS provides standard APIs and helps integrate it seamlessly into existing processes without disrupting them too much or creating additional work – if at all possible.

• The responsibility of securing data solely lies with the developer who created it, so we must ensure multiple tenants on shared infrastructure don’t share accesses or experiences unless intended by them specifically – no matter how well protected an app seems.

• Pricing model development. Choosing the right monetisation strategy for our SaaS MVP: we offer a 30-day free trial and/or 69-day “a buck per day test drive“

• etc.

Step 2: Defining BaaS components (described above)
Step 3: Decide what features to build. Prioritising the features

• Tenant isolation solution

Users can share servers and databases in multi-tenant environments. Our tenant’s privacy depends on our authentication mechanisms and SaaS tenant isolation strategies. How can we separate tenant data in our environment? Popular types of isolation include:

Virtualisation model means dividing tenants into clusters with isolated infrastructure sources. Silo-based isolation has the highest maintenance costs and is more typical of single-tenant SaaS apps.
Pool model. Users share the infrastructure and resources based on the database load and resource consumption.
Bridge model. A combination of virtualisation and pool models. For instance, tenants can share a database or a server but use isolated microservices.
Tiered model. Isolation is based on the customer’s subscription tier. For instance, free plans offer a single shared infrastructure, but upgrading to a premium tier gives access to isolated environments and additional resources.

• API keys to restrict access to specific API methods and/or all methods in Backend API (mechanism for controlling and managing access to Backend API).

An API key is a token that a client provides when making API calls. There are several possible places where API keys can be passed in our API design. As with all API requests, use HTTPS (TLS, the successor to SSL) to ensure that data is encrypted in transit. The most popular choice for including API key in headers. x-api-key is a custom header convention for passing client's API key.

GET / HTTP/1.1 Host: dev.marionette.dev X-API-KEY: abcdef12345
Our API can use the Authorization header to handle the API key, usually with the Bearer keyword. This method is also used for other tokens, such as those generated by OAuth. The client must send this token in the Authorization header when making requests to protected resources: Authorization: Bearer abcdef12345

Note: though the header has become the preferred location for API keys, there are non-header methods still used by many APIs. As a developer using APIs, you may spot these methods in the wild (Query String, Request Body Parameter, front-end JavaScript APIs). As an API designer, you’ll probably want to stick to the headers. In any cases, we have to take additional steps to secure the API calls. This is important because the API keys are essentially public, as they are easily discoverable if you view the source. Define the 401 “Unauthorized” response returned for requests with missing or invalid API key.