IaC in SaaS World

The SaaS world often deals with the challenge of delivery of software to their end customers typically this delivery happens on dedicated infrastructure. Depending on the need one can opt for various models for tenant isolation.

AWS Recommends 5 Models to do tenant isolation

1. Tenant Isolation at Account Level.
2. Tenant Isolation at Amazon VPC Level.
3. Tenant Isolation at VPC Subnet Layer.
4. Tenant Isolation at Container Layer.
5. Tenant Isolation at the Application Layer.

Out of these models Model, d and e will typically run on infrastructure which is created only once may be subjected to no or very few changes. Onboarding of new customers in models d and e is generally easy and less time-consuming as either we have to spin up a new container or make changes in the application.

The challenge lies in the first 3 models where we have to provide infrastructure for onboarding customers. Since for each new customer deployment we have to create new infrastructure and this infrastructure needs to be created keeping all security standards. If you are doing this infrastructure creation task manually there is scope for introducing security breaches.

Typical challenges while managing infrastructure for your SaaS deployments are as follows

1. Each new deployment infrastructure should have security group rules.
2. Infrastructure sizing should be precise.
3. Proper tagging of resources to keep billing simple.
4. Automated infrastructure monitoring for newly provisioned infrastructure.
5. Decommission infrastructure when not needed.
6. Audit changes to already created infrastructure.

These are some of the examples that we can definitely tackle by using IaC. In one of my projects, we used Terraform by Hashicorp to tackle the infrastructure creation problem. We were using AWS Cloud Formation earlier as it was a natural fit for us as every deployment for our customer was on AWS and it CF was our first love. Later on, we had some requirements to do multi-cloud deployments on different cloud providers hence we switched to terraform.

However, the deployment we were having was a mix of models suggested by AWS

1. Small clients

For small clients, we were provisioning infrastructure which was separated by subnets. It was using the same VPC for all clients hence the responsibility of the IaC component was only to provision EC2 instances and set up ALB, Route53, Cloud watch metrics in the same subnet.

1. Medium size clients

Some end clients are required to allow access to infrastructure to install additional 3rd party software. e.g. Jasper to pull data from their existing deployments for such 3rd party integration they often wanted to open ports that were only needed for their purpose. Having common VPC to host all clients were of course not a feasible solution in this case, though we could have solved this problem by having different Security groups instead we decided to go with AWS’s Tenant Isolation at Amazon VPC Level model. For each deployment, IaC code will spin up a new VPC, set up a new SG based on the client’s need, and since its there dedicated VPC blast radius is reduced to only one client.

1. Enterprise clients

Enterprise clients always push to have their infrastructure provisioned in a dedicated account. They often need to give access to their team members to this account. Creating a new AWS account for doing SaaS provision is actually a good idea. However, when you have multiple accounts for troubleshooting we need to often switch between these accounts.

Tips and Tricks While Operating in Multiple AWS Accounts

Using tools/services like AWS extend switch roles to toggle between AWS accounts which you already have access to or AWS Control Tower to govern compliances across all accounts becomes really handy.

AWS Extend Switch Role is a chrome plugin that will allow you to quickly switch between your AWS accounts under one umbrella. In our use case, all customer accounts were provisioned under the master AWS account, and for troubleshooting, we need to switch between more than one accounts often,

Sample configuration for this plugin looks like this

For all the above use cases, we created a dockerized version of our terraform script which can accept the parameters according to use cases.

This docker container we can run on demand whenever we want to do the provisioning.

Challanges in Containerzied Terraform

1. Since we were running docker image on demand every execution was generating a new tfstate file. We had to keep track of it because during decommission phase we need the exact tfstate file back. We were uploading the current tfstate file on s3 and in DB we used to store mapping for it. e.g.for this deployment this is the s3 path of tfstate so that later on while decommissioning we will get it back from s3.
2. For creating the AWS account we need a new email address you can’t have the same email address for the root account for more than 1 AWS account. Creating a new email id for each AWS account can be costly as enterprise plans of Microsoft/Google charge you per email id e.g. for Synerzip’s Gsuite account it’s 10$/id all we need is just an email id, not services related to Gsuite we solved this by creating only 1 email id and kept adding an alias to it.
3. Once infra is created all this infra information needs to be used to do application deployment. The output that Terraform generates has tons of information so we had to massage this output and pass it to the application whose task is to do the deployment. Once terraform finished its task it will store massaged output in s3 and will inform the application via SQS.

IaC solves lots of challenges of provisioning in the SaaS world. It allowed us to do deployments in a secured and tested way. Also resulted in the reduction of onboarding time for end customers.

About the author

Dipesh Rane

Dipesh works as a Solutions Architect with Excellarate and looks after the DevOps and Cloud practices. He loves working with engineering teams and is always enthusiastic to learn with them to build innovative solutions using cutting-edge technologies.