.png)
1 month ago
2
Background
For the last 10 years, the team behind MoneyOnFIRE have been building different applications on AWS. We were early serverless adopters and AWS Lambda and, to give AWS full credit, Lambda was a vast improvement over what came before.
The first version of MoneyOnFIRE was built on AWS as a serverless architecture. However, as our demands grew and found we were spending too much time on AWS vs Product and our Developer Experience was poor. After one too many AWS frustrations, we decided to try migrating everything to Vercel.
This post documents our experience, the tradeoffs we found, and whether it was worth it.
Our Architecture
The Architecture of MoneyOnFIRE is pretty close to the serverless web app reference architecture: a very common architecture for many SaaS products.
The only unusual requirement that MoneyOnFIRE may have is that the main lambda function is very compute-intensive. Every time the user clicks we:
- 'Run' their main scenario which is ~70 years of month by month, account by account with tax calculations.
- There are a few optimization problems within a sceanrio run which may cause us to explore several paths (run the 70 years multiple times)
- We then run ~12 different scenarios to show things like different expenses or market returns. Each of these scenarios is a completely fresh run of the above.
For reference, a spreadhsheet implementation of a single plan took 5-10 seconds to run. Getting access to dependable (low spin up, high flops) lambda compute was a key issue.
The Bakeoff
In essence, it is a straight contest - where is it 'better' to build the SaaS serverless architecture; AWS or Vercel? Which one is quicker, cheaper, most secure and with the least ongoing maintenance effort?
Our Takeaways
We made the point before but our architecture is very much in the wheelhouse of Vercel - so YMMV depending on your architecture. However, we do wonder how many startups now start with this architecture and whether Vercel is now catching this market.
Dev experience really matters. To find issues in logs, to issue fixes, to test, to deploy, to have confidence in that deploy.
It's not that it is impossible to build any of these features on AWS. Of course it is possible. The question is time. The default AWS dev experience is really quite poor (and Amplify is so bad that its not up for discussion).
Our big concern was whether there was something we wanted to do that Vercel would not support and we would be unable to leave the ecosystem. However, we haven't found anything - perhaps because we conform to their target architecture so YMMV. If we do then we might run a special back end service back on AWS. So far, there hasn't really been any downside.
Conclusion
Ultimately, after doing a few tests to derisk we moved our entire application to Vercel over one weekend and deleted a lot of excess code. When we look at our repo now its 99% our application and 1% infrastructure. That makes us happy.
