Deployment Stamps 101
This blog is part of the series where we discuss 101 concepts from Ground Zero for an audience that has limited starting knowledge. This article comes in the Intermediate-Level Series since it involves understanding the of Deployment Stamps, which is used as a pattern to scale heterogenous workloads in a multi-tenant setup. This pattern allows isolation of tenants needs — data, compute and other deployment blocks.
Some of the earlier blogs in the 101 Series are as follows:
CORS 101
Circuit Breaker 101
Priority Queues 101
Async Communication 101
Databases 101
Database Design 101
Deployment Strategies 101
What is Deployment Stamp?
Deployment Stamp derives its name from the term “rubber stamp” since its helps scaling large, distributed workloads using smaller replicable units, referred as service unit/scale unit. Each unit can they serve traffic for 1 — N tenants depending on the isolation criteria picked up for division of resources. This pattern helps limit multi-tenant platform from any Cloud resource provider limits when scaling out their production environment with growing customer needs.
Other advantages of using this pattern include cost optimization, low latency with geographical distribution of workloads, deployment/system update blast radius reduction etc. Due diligence should be given to non-functional requirements for selecting timestamps to avoid exceedingly small or exceptionally large stamps in production.
End 2 End Flow
Each Stamp unit is mapped to at-least one Tenant and in some cases multiple tenants if the workload i.e., TPS and Lifetime Data Needs outweighs cost-implications of hosting the tenants separately to unique stamps. Also, in cases the tenants have compliance needs such as HIPAA , PCI data etc, it is always advised to host tenants separately to isolate Access Management and Auditing needs.
Tenants to Stamp Mapping
Traffic Routing
Sequence Flow
- All Tenants call the Global Load Balancer Endpoint. which is always available across regions.
- The Global Load Balancer routes the traffic to the geographically nearest Regional Load Balancer.
- The Regional Load Balancer queries the Database which consists of the tenant to stamp mapping for all the use-cases.
- In case, the stamp deployment is in the same region as the Regional Load Balancer, the same regional network path is chosen to serve E2E traffic.
- In case, the stamp deployment is in a different region as the Regional Load Balancer, the Global Load Balancer routes the traffic to the correct regional network path.
Advantages
- Blast Radius Reduction – In case of outages, only given stamps and tenants are affected ensuring independence to other tenants.
- Rollouts – Platform updates can be done separately, and hence giving tenants flexibility to avoid updates in Business-critical time periods.
- Cost Benefits – In certain cases running two smaller copies of Cloud Services is beneficial to Cloud Costs vs scaling to a higher custom SKU following non-linear pricing model.
- Scalability Limits – Most cloud services come with limits on a single instance of the offering, hence having multiple-tenant partitioned instances can help isolate from growing data needs.
Summary
We discussed basics of the Deployment Stamp which is a reliable pattern for hosting a platform serving tenants having different business needs, geographically distributed and have independent scaling and versioning requirements to ensure performant end to end SLA’s are met. Different Cloud vendors have their own choice of the Global and Regional Load Balancers to setup custom Traffic rules to ensure high availability of the Platform. Some of the popular choices to achiever the same are Azure Front Door, Azure API Management, AWS Accelerator etc.
For feedback, please drop a message to amit[dot]894[at]gmail[dot]com or reach out to any of the links at https://about.me/amit_raj.
