How We Outgrew AWS Amplify in a Pre-Seed Startup
Learnings from using AWS Amplify for an MVP of a pre-seed startup.
Powers of Amplify
We built our current dashboard as a Create React Application and hosted it using AWS Amplify. As a startup, our primary goal was to ship a working MVP. This means a service like Amplify was suited for our needs as it is not only a host but a full suite of tools that combines CI/CD/Hosting/Environment management/etc.
The setup process took less than 10 minutes to deploy a React app to its subdomain at https://app.samelogic.com.
It took a few clicks to connect AWS Amplify to our github repository. On every merge to master we had a deployment to production.
Downfall of Amplify
As we received feedback, it became clear that we could no longer get by without a backend and a good dashboard.
We've built our backend services using the serverless framework, which has well-established CI/CD processes.
We automate everything we can so we can spend our efforts on the product. This includes automating infrastructure through Terraform or Serverless. Github Actions is already our primary CD and CI tool.
We've adopted Amplify as a second CI/CD service that will incur cognitive and technical debt over time. At the moment, Amplify only serves as a wrapper around S3 and Cloudfront, which our CD tooling can handle for us. As a startup, we need to keep our tooling consolidated to operate as lean as possible.
What Amplify couldn't do
We could not separate our build and deploy scripts. Meaning, we could not create a package once and deploy to many environments.
Documentation is lacking with integrating of other CI tools such as Github Actions.
Amplify could not easily handle cross-account deployment. Our AWS accounts are separated for each deployment stage.
Our alternative to Amplify was to leverage the Serverless Framework's Infrastructure as Code feature and our existing Github Action's deployment model. Serverless will configure our S3 bucket and CloudFront resources and deploy the files.
Conclusion
Amplify served its purpose; we got to ship an MVP fast and got feedback. As the organization grew, it became too much of an All-In-One tool.
Selecting the right tool for the job is critical to us, and a single tool cannot do everything and do them well. Product Management, Project Management, Development, CI, CD, infrastructure, and hosting are separate and complex layers. One could say we are applying the Separation of Concerns (SoC) principles to organization structure.
Each layer of the product should be built in a vendor-agnostic manner. This should allow us to lift and shift a layer such as hosting to Azure or GCP if necessary.
Our current layout and tooling are as follows:
Source Code Hosting - Github
CI - Github actions
CD - Github actions
IaC (Infra as Code) - Terraform + Serverless Framework
Static Site hosting - AWS S3 + Cloudfront
Compute - AWS Lambda via Serverless Framework
Product Management - ProdPad
Project Management - Asana
Product Experimentation - dogfooding Samelogic
As a company grows, the more complex and distributed systems become. It is imperative that we understand these domain layers and keep the layers separate but tightly integrated to provide a seamless experience for everyone in the company.
We may revisit Amplify in the future when we need to spin up small internal one-time apps. But not for complex production systems where the frameworks and toolset must be consistent across all of your services.