[RFC] afterclass.io v2 migration strategy

[davidlhw]

Need

Afterclass is currently deployed on AWS, utilizing key resources like EKS to run it's services. While this was a good feat to keep things scaling with the prevalence of spiked demand to Afterclass during bidding season, this has largely incurred unnecessary costs that are now becoming more unaffordable with AWS credits running out in Sep 2023.

Approach

Migrate from using AWS resources to Vercel + Supabase as the core infrastructure for Afterclass.

This migration will take place over the course of 2 months using the Blue-Green Deployment approach of having 2 servers running, with one being the primary and the other being secondary.

Blue-Green Deployments

For context, refer to this brief wiki article on Blue-Green Deployment.

In blue–green deployments, two servers are maintained: a "blue" server and a "green" server. At any given time, only one server is handling requests (e.g., being pointed to by the DNS). For example, public requests may be routed to the blue server, making it the production server and the green server the staging server, which can only be accessed on a private network. Changes are installed on the non-live server, which is then tested through the private network to verify the changes work as expected. Once verified, the non-live server is swapped with the live server, effectively making the deployed changes live.

Change strategy

1. deploy new app to vercel, with a temp banner that links to old.afterclass.io
2. DNS: add an A record new.afterclass.io pointing to the ip/domain of the new deployment
3. DNS: add an A record old.afterclass.io pointing to the same ip of the old deployment
4. when ready, DNS: update afterclass.io record to point to new.afterclass.io

Benefits

Main benefit of this approach is that users will still have access to the old version of afterclass (for some X period, until decommissioned) while also being able to experience the new version of afterclass. If there are any major bugs or issues on new, we can easily fallback and switch the DNS setup to use the old version as primary.

Another important benefit is that this allows us to gather usage insights by asking questions like:

• What is the rate that users are switching back to old?
• At which point (specific page) do they switch back to old?
• How long do they use until they switch to old?

Competition (or Alternatives)

Big Bang

One approach we can take as an alternative is to just decommission afterclass.io as it is and point the domain directly to our new deployment without considering for the old version.

The main reason to avoid this approach is the lack of flexibility in the event of unforseen failures. While not perfect, the current afterclass.io deployment is working well and does its job. Keeping it alive while we test our new deployment will be a safe option in case we need to fall back on an alternate version.

Weighted Routes (AWS Route53)

Another approach to take is the weighted routing appraoch using AWS Route53 as the DNS provider.

What this does is essentially allow for part of our users to reach the old version and another fraction of our users to reach the new version. This approach has some benefits of being able to compare usability metrics across the 2 versions to see which feature / user journey experienced real improvements and which is still lacking in the new version.

However, the main reason to avoid this approach is the complexity in getting it set up.

A few things needs to be done for this to be effective, just to list a few:

• Effective usage metric collection on both old and new deployments
• Time spent on data analysis of these metrics, which may not be a 1-1 match from old to new
• Knowledge gained from comparing these metrics will need to be actioned on