During my career in different organizations, though I had the opportunity to architect multiple SaaS applications and most of them on AWS, I was not aware that I was already following most of the best practices. Only recently when I had a chance to view the Architecting Next Generation SaaS Applications on AWS by Tod Golding in AWS re:Invent 2016, I came to know the reality.
From the SaaS models which Tod had referred to, I had gone through the Silo, Bridge and Pool over several projects and had been bitten by most of the cons when using Silo I had experienced the maximum complication on the Agile deployment. Since I learned everything from my own experiences at that time, automated deployments or what is known as Continuous Integration and Continuous Deployment using standard tools was not known to me. And mostly I used to re-invent the wheel, using shell, Perl or PHP scripts. Skewed releases across tenant installations were mostly the nightmares.
From the lessons learned overview of a SaaS product, the high-level reference architecture is as follows. Though there are more to achieve in the final product, this overview is just to brief on the SaaS Architecture.
This architecture follows a hybrid tenancy model, where tenants who require strict isolation will be onboarded through a specific front end application which will trigger the onboarding function. The onboarding function leverages the AWS Organisations to create multiple accounts, and the tracking is kept in a main tenant master table.
Activities that may take more time should be pushed to the background with notification on status as to when it gets completed by using queued processing. External Service access or AWS Account creation will take more time and these are shown as using queued process. Notifications could be of push or status updates polled by client applications.
The myriad of services including but not limited to, billing, monitoring, statistics, data recovery, exporting etc are left out intentionally.