In a previous article, SaaS may be the Path, I looked at how adopting a SaaS model for a product, business or service is not a predominantly technical challenge, and how the business case needs to be built with this in mind. We might look at this strategy in greater depth in future articles, but here I’m going to look at the challenges of preparing a SaaS offering in the cloud from a technical point of view.
When it comes to a SaaS offer, the first topic that will guide the design is: how will the multi-tenancy be built? Answering this question means understanding the multiple dimensions in which a SaaS offer unfolds (some of these dimensions are outlined in the AWS SaaS Enablement Framework):
- Tenant Definition. The definition of a tenant must be clear, reflecting the nature of your client’s business, what metrics are relevant to them when using your solution, and enabling transparency in usage analytics.
- Tenant Isolation. One of the first discussions to take place with your client is about the security of the solution, isolation from other tenants and how data is managed and partitioned.
- Tenant Observability. If, in the definition of the tenant, we say that usage needs to be transparent, the service monitoring and observability being delivered is fundamental, ensuring that each tenant is making proper use of the solution, the solution is working properly, and the provider is able to anticipate any incidents.
- Tenant Configuration. Each client will require different parameterization, customization and integration capabilities, and this strategy needs to be clear globally when defining a tenant, because choosing to add capabilities on demand could generate incompatible versions between tenants and pose future challenges to scaling the solution.
- Tenant SLAs. The SaaS solution is measured by the result it produces within the customer’s reality. The SLAs provided must support this objective.
- Tenant Provisioning. The main concept behind SaaS may be self-service, therefore, provisioning must be considered and must support the agility that the customer seeks when incorporating the solution.
It is important to emphasize that even for solutions that choose to work in stand-alone or single-tenant implementations, all of the above dimensions apply, since in a SaaS model, it is important that the concept of tenant is well defined, with an adherent measurement strategy and observability, as well as configurable and highly automated provisioning.
Once this base of requirements to be met has been established, the architecture to be adopted comes into play, which introduces some additional important considerations:
- Security. There must be a clear security strategy in place for the solution, including in its multiple layers, in transit, at rest and in perimeter, encompassing identity management, threat detection, and event correlation.
- Data and protection. More than thinking only about security, it is important to think about data protection and management. With a significant amount of regulations, laws, standards, and customer awareness on this subject, the data management and classification strategy must be clear and observable.
- Scalability. In a SaaS model, customer consumption is most often measured based on business variables, so the scalability and elasticity architecture need to be optimized to reflect the cloud resources usage, compatible with the customer’s consumption on the platform, generating traceability that will give solidity to the result produced.
- Application architecture. For new SaaS solutions, there is a very interesting trend involving the use of serverless services, such as AWS Lambda. This trend is geared toward realizing the benefits of an application with an event-driven architecture and natively supports the previous solution point, scalability and elasticity. But it is important to keep in mind that this is not the only alternative and in most cases there will be combinations with microservice-oriented architecture, orchestrated in containers.
- Storage. As the customer no longer looks at infrastructure aspects in a SaaS model, storage management intelligence, tiering implementation based on time or information relevance, backup strategy, disaster recovery, analytics for reports and searches now must be transparent, which can determine the competitiveness and the observed solution quality.
- Versions and Customizations. The final aspect I would like to address requires perhaps the most extensive discussion, as the SaaS solution often needs to support a lot of parameterizations, a good level of customization and good flexibility for integrations, with a very clear API strategy. All of these factors make version management and the release of new features – as well as the removal of legacy features – a very complex task, and very time-consuming when it comes to rollout for multiple tenants.
This article is already longer than was initially intended and I believe that so far it has raised more questions and points of reflection than effective solutions for this journey of building a new business in SaaS. So, I’ll interrupt the discussion at this point, before returning with a follow up article to cite some accelerators when thinking about a SaaS ecosystem, which will help resolve many of the challenges introduced in this article.
