If you do plan to be hosting 1TB of data in EBS for each developer then yes, this approach is probably not right for you and you should adapt it! It's not a one-size fits all approach.
Hey, author of the post here. Apologies if the wording wasn't clear, but these are our developer AWS accounts, i.e. not production workloads. I was just highlighting that everyone runs a copy of the production infrastructure and since serverless is "pay for usage" we mostly only pay for when developers are firing in the handful of requests they do during development.
None of our engineers have so far managed to generate gigabytes of data or millions of requests like our production account :)
A website doesn't need a server! You can host your website assets on a CDN and all of it's then loaded without hitting any of your servers.
Our architecture roughly looks like this:
- React application hosted on Vercel
- AWS API Gateway routes API requests to Lambdas
- The Lambdas then read/write data from RDS Postgres, DynamoDB and also maybe publish events to EventBridge.
- We have many smaller Lambdas that listen to events happening on EventBridge and do other things, such as sending notifications, etc.
I think if you're able to be build a non-trivial application with microservices then you're also able to build one just on lambdas.
Hey, author of the post here! Thanks for your comment.
Yes, you hit the nail on the head :) 99% of our code actually lives in domain packages that are infrastructure agnostic. Our lambda handlers are very lightweight adapters that take the input and transform it to a domain input and transform the output back.
That said, our serverless architecture does leak a bit into our domain thinking. E.g. certain things are built async since it's just so easy to hook up a lambda to listen to an EventBridge event.
- AWS SSO hooked up to our Google Workspace: so no AWS access keys exist, everyone has only short-lived credentials (e.g. 24 hours) to access their AWS account.
- AWS Organization with consolidated billing: all our bills roll up into one nice invoice!
- AWS Control Tower: allows us to deploy guardrails and policies to keep all our AWS accounts secure. We also have a centralized Audit AWS account where all Cloudtrail logs are routed.
- AWS Account Factory: to create new AWS accounts that are automatically enrolled and created as part of the right Org Unit.
- AWS Cloudformation StackSets: allows us to deploy custom resources to everyone's AWS accounts. Right now we use this to deploy custom roles that can be assumed by developers.
