Thread by @thinkshiv

Today, we are excited to share the public (re)launch of our private cloud. First, a technical primer of this new @auth0 Private Cloud Platform auth0.com/blog/a-technic… from @TBrightB1. A 🧵 on the why, the how, and what's next (1/n) #developers #identity #multicloud #platform

@auth0 @TBrightB1 Let's begin with why we began this platform modernization journey. For context, @auth0 has been in a hyper-growth mode for many years. This is why we ended up with two platform stacks serving (1) Multiple tenants (2) Single (dedicated) tenants (2/n)

@auth0 @TBrightB1 Each platform stack had its merits. Multi-tenant (aka public cloud) ➕'s:
Immutable Infrastructure ✅
Autoscaling ✅
New features can be launched in a timely manner ✅
Excellent Observability Stack ✅ (3/n)

@auth0 @TBrightB1 Multi-tenant➖'s:
Environment creation was slow - the current process was infrequently used and didn't scale as more services were added❌
Designed for multi-subscriber and is not cost-effective for single-subscriber ❌
Lots of accidental complexity❌
(4/n)

@auth0 @TBrightB1 Single-tenant (aka private cloud) ➕'s:
Automation and ability to support many environments ✅
Environment Creation: on-demand in a couple hours✅
Data Sovereignty✅
Isolation and reduced blast radius✅
(5/n)

@auth0 @TBrightB1 Single-tenant ➖'s:
Technology Constraints ❌
Lack of access (data, infra, etc) ❌
Mutable and In-Place Deployments❌
Lack of Autoscaling❌
Too many targets/configurations❌
Runtime config drift❌
Slow TTR due to patch process❌
Customer Hosted❌
(6/n)

Outside of the ➕s and ➖s, the platform divergence was slowing down our product engineering teams as they had to get the features to work on two different stacks. This also added to engineering frustration and low morale (7/n)

Now, let's explore how we approached the solution. 1st challenge - how do you convince the CFO of the investment? If it's just addressing tech debt, chances of approval were low to none. So, we flipped the model. (8/n)

We started by targeting business value - we wanted to bring in new biz in 2021 (the year we kicked off was 2020). If we deployed to a new cloud target - we'd bring in incremental net new revenue and customers. So, that was the birth of our journey to @Azure (9/n)

@Azure 2nd challenge - what should the new stack be? We had a few failed tries with @kubernetesio in the past so there was a nervousness to approach the same tech again. We took an iterative approach and built lots of PoCs. We addressed many of our big technical q's this way. (10/n)

@Azure @kubernetesio The rapid iteration and PoCs proved our tech and gave birth to Layer0 (our internal project name). The new platform was a modern, resilient, cloud-native tech stack. A big thanks to so many engineers but special mention to @lxfontes, @dschenkelman, @cyx + more (11/n)

As of today, we have:
Modern, resilient, cloud-native tech stack ✅
Multi-cloud: Choice of @awscloud or @Azure, with the ability to support other clouds in the future ✅
Increased speed to ship features with frequent, smaller releases across hundreds of environments ✅
(12/n)

@awscloud @Azure Single codebase, build once ship anywhere with full release control ✅
Highly Available and Geo-failover ready ✅
Supports upgrade scheduling and rollbacks✅
Customers being deployed on the new platform across both cloud targets @awscloud + @Azure ✅
(13/n)

@awscloud @Azure The 3rd challenge was migration to the new platform. In general, platform migrations are a PITA! We ensured that migrations were first-class citizens in the new platform. We started building some migration tooling in parallel with the platform. Our target: <10 min downtime (14/n)

@awscloud @Azure Today most customer configurations have a brief downtime of under 10 mins. There are snowflakes that will take longer but again 80/20 rule here. Ok, now onto the next chapter....what's next? (15/n)

@awscloud @Azure 1. Scale - the new platform gives us 4-10x scale in terms of RPS/RPM. Our customers will benefit directly from this. We can handle any large scale consumer application
(16/n)

@awscloud @Azure 2. Ease of migrations - between tenancy models allows customers to upgrade/downgrade based on their needs.
(17/n)

@awscloud @Azure 3. Availability - broad one here but this new platform allows us to deliver a highly available service with better DR and failover scenarios. We are reducing blast radius significantly as we can deploy many, smaller environments faster (ie minutes versus months)
(18/n)

@awscloud @Azure 4. Features - with a single codebase + platform new features are feature flagged to any customer, regardless of their tenancy
(19/n)

@awscloud @Azure 5. New cloud targets - we will follow customer demand. New cloud targets are now easy for us to deploy to given our new multi-cloud enabled stack.
(20/20) </end>