People should learn that using an intermediary other than AWS or Google Cloud for convenience is risky. All depends on your level of risk vs. screwing around, but if you want to go cheap then you should run your own instrumentation on top of bare Linux instances from commodity vendors that can be cycled out easily, and use multiple vendors to ensure outages at one are easily remedied.
Heroku is another example. Can’t trust your business to shaky foundations. The moment they started to have frequent outages your company should have been migrating ASAP.
As a side note, I would never use nor invest in brand new databases. Database tech needs to soak for 10+ years before I trust the software is stable and the organization behind it will exist longterm. A startup using a shiny new database is evidence of weak engineering leadership. Similarly, Terraform / Cloudformation is easy enough that needing something other than AWS tooling itself is making less sense from a cost vs. convenience perspective.
I'm not interested in becoming a cloud practitioner or getting an AWS/GCP/Azure certificate just to host my web app on AWS.
All I want to do is just git push my code and my app is distributed worldwide in the closest regions, all fast with no deploy scripts or convoluted formation tools.
Heroku and maybe Fly.io are the closest to this goal than other all the other solutions i've tried.
But anything that gets in my way of this goal is friction.
The other way to protect yourself is to design the app to be easily portable between cloud solutions.
A static site can easily move from fly to heroku to vercel to digital ocean. Something written in NodeJS can be moved around those just as easily.
Most apps will be naturally portable unless you do something very specfic to your provider.
The idea here is not to be "multi cloud" but to say "if this provider goes to shit, give me 2-4 hours, and I can deploy it somewhere else, change the DNS, and then go sip a pina colada".
For small potatoes stuff, yes. For critical business apps that make money and have real customers and jobs on the line, IMO too risky. It isn’t that hard to get to “push code and it deploys” directly with AWS nowadays.
You don't need any AWS certs to deploy a few lambdas and a couple of DynamoDB tables. Come on.
Your codebase, a few shell scripts, a yaml file for your CI/CD config, and another for your serverless framework definition and you're done -- couldn't be easier.
100% agreed. But I'd suggest you just go for a serverless offering from one of the big cloud players.
If your app runs on Heroku or Fly.io, you really don't need servers or VPCs or k8s clusters.
Where I work, we've gone all-in on AWS Serverless and couldn't be happier. We have 1 dev-ops/infra person supporting 3 feature teams, all of which are releasing into their apps based on this stack multiple times a day. The infrastructure overhead is so low that our dev-ops guy has time to additionally spend time on optimising CI/CD for speed, tightening up on security, etc, etc.
When we started, we had 2 devs who just did everything from a single repo, a gitlab account, and the serverless framework.
I really don't understand how adding yet another layer on top of AWS's / GCP's / Azure is materially going to change the developer or user experience. It just adds cost.
> I really don't understand how adding yet another layer on top of AWS's / GCP's / Azure is materially going to change the developer or user experience. It just adds cost.
Actually, AWS products (PaaS like Lambda) themselves are a layer atop AWS (IaaS like EC2) that you just said you immensely favour, and that it reduced costs (1 devops for 3 teams). Besides, Snowflake and Databricks are two examples among many of non-AWS but AWS-dependent billion dollar software shops that work just fine for the largest of enterprise businesses.
That said, don't think Fly is a layer on top of AWS (they rely on servers from NetActuate, Equinix, and others from the looks of it: https://news.ycombinator.com/item?id=29162706). They couldn't have the pricing they do if they were.
AWS regularly lies about their status on their status page.
Instead, if you have an issue you think is an AWS specific issue and if you spend enough money with AWS, you have a TAM. You reach out to your TAM who can give you the real status under AWS NDA.
I would love to use AWS but the usage based pricing has scared me away. There have been too many stories of running up bills in the tens of thousands from coding errors. If AWS had a way to make sure that didn’t happen I would be all over it.
Heroku is another example. Can’t trust your business to shaky foundations. The moment they started to have frequent outages your company should have been migrating ASAP.
As a side note, I would never use nor invest in brand new databases. Database tech needs to soak for 10+ years before I trust the software is stable and the organization behind it will exist longterm. A startup using a shiny new database is evidence of weak engineering leadership. Similarly, Terraform / Cloudformation is easy enough that needing something other than AWS tooling itself is making less sense from a cost vs. convenience perspective.