First Things First
“Almost all of the market segments with enterprise software are being driven by the adoption of Software As A Service (SaaS)“, Gartner, January, 2020. Whether you are already a SaaS provider, or a founder in the very early stages thinking of becoming one or maybe an old good enterprise who is toying with the idea of SaaS migration – this post is written especially for you.
SaaS requirements and implementations tend to vary depending on the use case, there is no one size fits all! But, as you will see, the patterns and principles, which are part of AWS SaaS Factory, are sustainable, reusable and demonstrate the best practices for building SaaS solutions.
So now that we know that SaaS solutions are booming, let’s crack it!
As trivial as they may sound, these three must-do tips can save you a lot of headache if you choose to go through SaaS migration:
- Build the case for you and for your customers that justifies this migration. What will make your SaaS offering more attractive for your customers than your existing COTS products?
- Do not get mislead, SaaS migrations are not led by technical professionals alone, business and technical experts shall work closely together to assess the implications on both ends. E.g., how are you going to tier different levels of tenants in your system? That effects both, technical and business decisions.
- Map the areas that are important to address as part of a SaaS migration (e.g., tenant isolation). Make sure you are up to date with the relevant best practices. To move faster and in the right direction, consider acquiring support from a partner if/as needed.
To meet your SaaS requirements, you most probably want to redesign and optimize certain pieces of your system, that’s your ‘Target System Architecture’ and more on that later on. In this post we explore the layers outside-in starting with the satellites, the SaaS Enablers.
Be aware that, technically speaking, the design and implementation of these SaaS Enablers are far from being agnostic to the SaaS model your target system architecture uses.
The SaaS Enablers
SaaS Enablers are those capabilities we acquire, which surround the ‘Target System Architecture’. They are key for you to meet the business objectives of your SaaS solution. Make sure you focus on the SaaS Enablers first!
| Onboarding |
In the SaaS model we aim for an automated tenant onboarding and provisioning experience. This is your way to guarantee a reliable, consistent, secure and scalable tenant onboarding. Registration form/API is used to collect all of the tenant configuration data before launching the onboarding process. This process executes the onboarding steps needed to introduce a new tenant into the system. If your system is integrated with a billing system, the onboarding process is also used to provision the billing account for the new tenant. Obviously, your solution for tenant onboarding shall not ignore the reverse process of tenant offboarding.
| Identity |
Your system architecture probably already implements identity solution. For the sake of your SaaS model, you want to extend the identity solution to securely connect user’s identity with the identity of its tenant via tenant-context – that’s your SaaS identity.
The SaaS identity is attached to all interactions with the SaaS environment, allowing you to reliably resolve and apply this context across all the services of your target system architecture, for example, to support tenant-isolation, tenant-level data partitioning, authorization, monitoring, metering, usage & analytics, SLA, etc.. Also, keep in mind that your authorization scheme shall distinguish between system identities and tenant identities. For example, a system user is an administrator of a SaaS provider and has access to data of all tenants, whereas a tenant user is constrained to managing configuration and data that is part of their environment only.
Make identity and isolation an early priority in your migration plans!
| Deployment Automation |
Support a zero down time model, a single code base and one fully automated deployment for all tenants (customization, if supported, is metadata/configuration driven, e.g., feature toggling). This best practice allows you to support frequent, consistent and reliable deployments with minimal impact on customers. For most environments deployment automation is highly recommended, For SaaS environments, where new features/patches are deployed frequently, it is kinda a must-have capability.
| Management & Monitoring |
It is essential to have a single pane of glass, a multi-tenant aware dashboards & alarms, to monitor your SaaS environment so you can quickly respond to operational events, which may otherwise impact the availability of your SaaS environment, e.g., that could be the outcome of noisy neighbors. You would also want to introduce management functionality at the tenant level like, configuration, administration, enable/disable, deactivation, change plan, etc.
Practically speaking, not managing your tenants collectively, is not really an option. The complexity involves in building that varies depending on how you choose to design your target system architecture. The nature of your tenant partitioning model, the compute model you’re using, and any number of other factors could influence your approach to assembling your multi-tenant aware management & monitoring solution.
Tenant-aware logging and metrics, is a must-have capability!
| Metrics & Analytics |
Optimizing your SaaS environment is an ongoing process. Make sure that tenant-aware metric data is collected, aggregated and made available to a range of roles within your SaaS organization, enabling immediate insights into key usage, consumption and activity trends that shape both business and technical direction.
This data is used to shape architecture strategies, pricing models, product roadmap, and operational efficiency.
Instrument for metrics even if you start with just a few, the key is to build the foundation. Collaborate with stakeholders to identify those metrics that give them the visibility and insights they need to run the business.
| Metering & Billing |
Define and collect metering records reflecting the usage at a tenant level. Feed your billing system with these records to generate charges and produce the bill. But how do you know your pricing and tiering strategy and tenant consumption are aligned? You measure tenant consumption and correlate the two, pricing with cost footprint, this helps shape the granularity of your metering strategy, e.g., bandwidth, number of users, storage usage—these are all flavors of billing models that are used to correlate tenant activity with some billing construct. Remember that metering is targeted at capturing just those metrics that are meant to derive a tenant’s bill – they may not map to the notion of tenant infrastructure consumption, which is focused squarely on determining the actual cost associated with each tenant’s activity.
The Target System Architecture
Tenant Isolation Concepts & Considerations
Isolation is a foundational element of SaaS and every system that delivers a solution in a multi-tenant model should ensure that their systems take measures to ensure that tenant resources are isolated. What is considered “enough” isolation? It depends.. for example, some high compliance industries require that every tenant have its own database. How do we design for isolation? Once again, it depends on what your target system architecture is like, the compute (e.g., containers, serverless, ec2 instances, etc.), the network, database and storage – while there are many approaches to achieving tenant isolation, the realities of a given domain may impose constraints that require specific flavor of isolation.
| Silo Isolation |
| P R O S  | easier to meet security & compliance requirements via strict tenant isolation assist in preventing cross-tenant access; no noisy neighbor concerns; tenant cost tracking, the coarse-grained nature of the silo model provides us with a simple way to capture and associate infrastructure costs with each tenant; limited blast radius, any failures that occur within a given tenant’s environment will likely be constrained to that environment, tenant-level availability; tenant-level tuning is simpler and it also allows you to statically configure your pricing and tiering strategy; no/minimal architecture adaptation is required, which often found as a significant advantage when the desire is leaving an existing legacy architecture intact; |
| C O N S  | agility is compromised, the highly decentralized nature of the silo model adds complexity that impacts your ability to easily manage, operate, and support your tenants; onboarding automation is cumbersome, the provisioning of a new tenant will require the provisioning of new infrastructure and, potentially, the configuration of new account limits; cost efficiency – opportunities for saving are limited; deployment is cumbersome and poses some challenges especially with larger number of tenants; scaling issues arise mainly due to AWS quotas limits and operational inefficiencies, which are the result of managing dedicated infrastructure per tenant; |
| Pool Isolation |
| P R O S | agility – with shared infrastructure model you get all the natural efficiencies without performing one-off tasks on a tenant-by-tenant basis; cost efficiency – your system scales based on the actual load and activity of all of your tenants; simplified operations – with the shared infrastructure model the centralized management is usually natively built |
| C O N S | noisy neighbor is a concern, you should design your architecture to limit these impacts (e.g., via throttling, access policies, etc.); tenant cost tracking – in a silo model, it’s much easier to attribute consumption of a resource to a specific tenant; blast radius – having all of your resources shared also introduces some operational risk, all or nothing availability; Due to security & compliance considerations customers may be unwilling to run in this model; |
| Bridge Model of Isolation |
The bridge model is more a hybrid model that focuses on enabling you to apply the silo or pool model where it makes sense. The pros and cons of the bridge model basically derive from the trade-offs of silo and pool models for each resource/layer of your architecture.
| Tier-Based Isolation |
Figure 12 demonstrates a scenario where there’s a mix of silo and pool isolation models that have been offered up as tiers to the tenants. Beware that If too many of your tenants fall into this model, you’ll begin to fall back to a fully silo’ed model and inherit many of the challenges that we outlined.
Similar to the bridge model, the pros and cons of the tier-based model derive from the trade-offs of silo and pool models for each resource/layer of your architecture.
While picking your favor tenant isolation concept(s) – be cautious, keep in mind the various trade-offs they bring to the table, mainly in these areas of pricing and tiering strategy, security & compliance, opportunities for cost saving, noisy-neighbor, cross-tenant access, leaving an existing legacy architecture intact, etc.
Also keep in mind is that an application that is properly designed using Pool Isolation gives the business the flexibility to decide how and when to apply any of the tenant isolation concepts (e.g., silo, pool, etc.). While targeting Pool Isolation, you can still support Silo Isolation (see Figure 13) – strive to support multiple tenants on day one!
Common SaaS Migration Models
If you design a new product, do not miss the opportunity to design an AWS cloud-native, multi-tenant SaaS solution with all the best practices.
What if there is a business case for your company to introduce a new multi-tenant version for an existing product such that they both evolve in parallel? For the new version of the product, it is a no-brainer, we redesign it as a proper AWS cloud-native, multi-tenant solution, one that meets all these SaaS best practices. The next part is a bit tricky. The approach we take to evolve both versions, the single-tenant and the multi-tenant, is to build new features as first-class citizens (AWS cloud-native, multi-tenant, etc.) of the multi-tenant version of the product and adopt this exact code base into the legacy version of the product (see Figure 14).
Sometimes, the reality and constraints lead us to continue maintaining our legacy architecture and make some compromises, which we do not want to make in a random fashion. This is where our common models and value systems come to play. It is by no mean an exhaustive list of migration models, and yet we probably can say, with high level of confidence, that these few are the main flavors.
Note! regardless of the migration model you choose to follow, these points are very much relevant:
- Building and integrating SaaS Enablers with your entire target system architecture and making them a priority is one of your most critical tasks to complete
- As part of your target system architecture design, there are quire a few decisions for you to make, e.g.:
- How would you design and build the SaaS enablers?
- How would you design and build tenant-routing functionality (e.g., DNS-based, API & tenant-context-based, etc.)? How do you plan to leverage your solution for identity (SaaS enabler) to enable tenant-routing functionality?
- How do you plan to support tenant-aware logs, metrics and analytics, metering?
- How do you plan to support tenant-aware partitioned data access?
- How do you plan to move away from one-off versions toward a universal version of your application?
- What isolation mechanism serve you best? AWS VPC? AWS Account?
Some of the most common migration models partially retain the legacy architecture. However, the SaaS enablers are all tenant-aware and they deliver results based on tenant-context. It basically means that you may need to consider a way to inject the multi-tenant constructs into legacy code (see Figure 15).
| Silo Lift and Shift |
You may have a one-off solutions for each of your customers that run on-premise. If your primary goals are to reduce the risk and minimize the migration effort then with the Silo Lift and Shift model we move all these silos of stacks into a universal representation and with minimal / no changes and then we try to lift and shift this workload to AWS. Our attention and effort are focused on building the SaaS enablers while retaining most of the legacy architecture. When it comes to legacy architectures, technical folks often have a love-hate relationship as they strive for constant improvement and modernization. However, it is important to note that for some businesses, this specific model of Silo Lift and Shift, is quite appealing simply because it is good enough in terms of scale and cost and it also allows to move faster with the migration.
| Layer-By-Layer |
Unlike in the case of the Silo Lift and Shift model, with the Layer-By-Layer model you clearly get the chance to optimize your target system architecture and become more scalable & efficient. You incrementally pick the layers you choose to transform into multi-tenant. Some layers are simpler to migrate using this approach than others. For instance a web tier in a traditional three tiers application is likely to have less tenant context in it, it should not have a lot of coupling and dependencies between tenants and it can basically be pulled out of the monolith with minimal / no impact. However, the application layer would require significant effort to migrate (see Figures 20, 21).
| Service-By-Service |
Unlike in the case of the Layer-By-Layer model, with the Service-By-Service model you gradually carve out capabilities from your existing system and redesign them from scratch as multi-tenant, cloud-native services that carefully adhere to the SaaS best practices. This model fits best to organizations, which are willing to invest to get their solution to that end-state of a modern, cloud-native, multi-tenant architecture with all the benefits that follow while the legacy architecture is eliminated entirely. However, since this migration model is incremental, the legacy architecture shall run in a complete harmony, side-by-side, with the new services we introduce. Note that carving-out functionality from a monolith and transforming it to an autonomous (Micro-) service can be a real challenge, especially at the data layer. Things like SQL JOIN statements, inter-dependencies and tight-coupling inside your monolith, are the kind of challenges you should identify and use to prioritize the low hanging fruits, in other words, try to surface those capabilities that are relatively straightforward candidates for the Service-By-Service model.
Figure 22 illustrates the Service-By-Service model where the new modernized, multi-tenant services are implemented as Microservices and the existing traditional three-tier web application is migrated and deployed using silo isolation.
Figure 23 presents a variation of the previous Service-By-Service model example. In this example we further optimize our target system architecture as we carve out the web tier from the monolith and then we apply the Layer-By-Layer model by turning it to a multi-tenant construct.
Redesigning the web tier to support multi-tenancy as illustrated in Figure 23, indeed boost your ability to scale and it also makes things more efficient but there is a greater opportunity for modernizing your target system architecture. Figure 24 presents a second variation of the Service-By-Service model example. This time we eliminate your web-tier altogether and replace it with the AWS S3 (for serving static web resources) and AWS API Gateway to support your web app via Restful API.
| Which SaaS Migration Models To Use? When? |
Assuming that our ultimate goal is to end up with a modern, cloud-native, multi-tenant target system architecture, Figure 25 illustrates a multi-phase plan to meet this end-state. In phase #1 we use silo lift and shift to move faster (short TTM) with minimal effort; In phase #2 we either take a more conservative transformation and use the layer-by-layer model first to make our web tier multi-tenant or we move directly to the service-by-service migration model.
Which SaaS migration model you should use and when, is really a question for your business to answer. We can definitely point out that each migration model has its challenges and opportunities as listed in Table 3.
| Lift & Shift | Layer-By-Layer | Service-By-Service | |
|---|---|---|---|
| P R O S | TTM; Minimally invasive; Security & compliance (strict-isolation); | Incremental; Moderately invasive; Quick wins; | Incremental; Full modernization; Scale, availability, agility; |
| C O N S | Agility; Cost; Manageability; | TTM; Manageability; Cost | TTM; Data model migration; Complexity (invasive); |
This Doesn’t End Here…
We touched on some key points pertaining to AWS SaaS migration journey from business and technical angles while trying to answer the key questions of what does it take to become a SaaS provider and what are the main strategies. Although we’ve made some progress, this is just the tip of the iceberg, if you want to go deeper on AWS SaaS, I’d advise you to explore the AWS SaaS Factory Program web site and watch the recording of this excellent breakout session: “AWS re:Invent 2019: SaaS migration: Real-world patterns and strategies (ARC371-P)“.
Cloud Solutions Architecture Talks 