For mature enterprises, planning, building, and managing foundational cloud technology platforms accelerate value for their internal clients. Once these enterprises reach a certain size and level of dependency on technology, establishing these foundational platforms help eliminate complexities, boost the effectiveness of its use base, and help adhere to compliance standards across the enterprise.

Building these foundational platforms as a SaaS (Software as a Service) enables organizations to maximize their client experience and Return on Investment (ROI).

Here is a sample SaaS Journey Framework that breaks down the path to SaaS success into four distinct phases (Business Planning, Product Strategy, Minimum Viable Service, and Launch/Go-To-Market), each representing a critical stage in the move to SaaS.

At a broad level, SaaS Journey Framework allows you to accomplish the following:

In the rest of the sections, we will get into each key pillar of success, as you build out your Cloud Platform as a Service. These key pillars of success can both be treated as a set of design principles and also as recipes for success.

Content Overview

Multi-Tenant Experience

When you design your Cloud Platform for housing multiple tenants, you may want to take advantage of the economies of scale that come with sharing infrastructure resources across tenants. Simultaneously, the tenants require some of the resources to be dedicated to them.

Different SaaS models such as Silo, Pool, and Hybrid provide different levels of multi-tenant experience and workload isolation.

In scenarios where you must comply with strict workload isolation for teams, choose Silo model. In scenarios where you would benefit from economies of scale (for example, a common set of VPCs, subnets, and NAT Gateway for a set of customers), choose Pool model.

Immaterial of which model you choose, each environment managed by your platform still relies on a shared identity, onboarding, and operational experience where all tenants are managed and deployed via a shared construct. This is where a Control Plane based operation comes in to help.

Control Plane

Control Plane is a management and operations layer that houses central SDKs and CI/CD Pipelines and operates across multiple accounts.

It is a critical part of your multi-tenant strategy that ensures that all your Infrastructure as Code pipelines (including On-boarding pipelines) are unified, and managed through a central account (Single Pane of Glass).

With Control Plane, you can:

Tenant Workloads Isolation

When you build and operate a multi-tenant platform as a service, you must ensure that each tenant is prevented from accessing another tenant’s resources.

The following strategies help in enforcing workloads isolation:

In AWS, IAM Policy Conditions element and IAM Policy Resource element are excellent ways to enforce both ABAC and NBAC.

Beyond tenant workloads isolation, ABAC (using Tags) also allows you to measure the cost impact of individual tenants.

Designing multi-tenant experience for your platform as a service requires deliberate planning. The above patterns and techniques (Silo/Pool/Hybrid, Control Plane and Authorization strategies) should help you in coming up with a robust design.

On-boarding and Identity Foundation

There are several channels (sign-up page / GitHub Pull Request etc.) through which you may want to onboard tenants for your platform. Most often, tenant onboarding is initiated directly by tenants, but this could be a provider-managed process too.

Immaterial of the channel, this step often requires the orchestration of a number of components to successfully provision and configure all the elements needed to create a new tenant.

For example, let’s take a scenario where we have decided on our authentication strategy as IAM with MFA.

When a Team (composed of a set of users) is on-boarded, the platform may perform the following steps:

  1. Create IAM User for each user within a team & attach the tag team name to the user with an appropriate value.

  2. Attach IAM User to one or many IAM Groups, depending upon the persona attached to the user in the request.

  3. Create Team Execution Roles with appropriate permissions that underlying cloud services will use for execution. For example, the platform may create separate Team Execution Roles for SageMaker & Glue.

  4. Create AWS SNS Topic for a Team as well as for each user. These topics can then be used for sending notifications to the team or a user.

  5. Attach common policies that govern platform usage across all users. For example, mandate MFA before any service is accessed through Console or CLI.

By pre-packaging all preventive permissions and team-specific resources (like execution roles) during on-boarding, you can deliver a secure, governed yet easy-to-use and repeatable on-boarding process that just works.

Self-Service

Self Service is a key pillar that unlocks accelerated delivery by empowering consumers to launch cloud resources and pipelines with little or no intervention from administrators.

Enabling Self-Service on Cloud Platforms is hard since you need to simultaneously satisfy two goals that are seemingly contradictory:

AWS offers a couple of interesting models for self-service that you can embrace.

CI/CD Pipelines as a Service

CI/CD Pipelines as a Service offers a toolchain standard to be re-used by application teams. In this model, end-user teams launch a governed deployment pipeline from AWS Service Catalog.

The workflow for this model is as follows:

Key Benefits:

https://twitter.com/kelseyhightower/status/953638870888849408?s=20&embedable=true

Centrally Managed Products

This model allows end-user/consumer teams to provision resources managed by a central operations team as self-service.

In this model, Cloud platform engineers publish infrastructure portfolios to AWS Service Catalog with pre-approved configuration. This locks down how infrastructure is configured and provisioned.

For example, consider offering S3 Bucket as a Service. In this case, the workflow would be as follows:

Key Benefits

With Centrally Managed Products & CI/CD Pipelines as a Service models, platform admins can provide superior self-service to end-users while adhering to the highest levels of security, standardization, and compliance.

Security by Default

Security is a key pillar that provides multi-fold benefits, especially when you are launching a platform as a service. Building all capabilities and services with Security by default principle ensures that hundreds of teams in your organization use these products, without worrying about managing security in the cloud.

Below are a few strategies to ensure that platform offerings are secure by default:

By establishing preventive guardrails, including DevSecOps in all builds, protecting data privacy in the capabilities offered, and isolating team workloads, you can deliver an exceptional security by default that works for teams at scale.

Conclusion

Cloud Platforms as a Service provide agility and innovation to mature organizations. By treating them as full-fledged SaaS services with the help of the SaaS journey framework, and also coming up with a solid architecture with the help of the above-mentioned pillars, organizations can unlock exceptional service experience and also increase agility.

“Platforms and platform thinking aren’t cure-all solutions. They’re conduits and catalysts for your strategic goals. To harness their full potential and realize their full value, they must be designed and built with your unique goals in mind.” — Rachel Laycock, Global Managing Director, Enterprise Modernization, Platforms and Cloud

References

Also published here.