[ecuaflo]

I’ve been spending a week trying to learn how to deploy a collection of containers (my web app, a Postgres DB, and some microservices) to AWS and I am still so lost.

The first solution I happened upon was serverless. Specifically SST, which is written with AWS CDK, but you must develop on live services and I just can’t justify paying to develop.

Then I found Serverless Framework, which is an abstraction on CloudFormation, but the offline solutions like localstack get a lot of flack for being buggy and localstack charges for some services. I also looked into Architect but the documentation is abysmal.

Then I figured serverful might be the easier way to go. I found that docker compose has a built in integration with AWS ECS where it transforms your yaml into Cloudformation to provision the right services. However, it seems to just be missing key parts like custom domain and SSL certificate provisioning which seems to defeat the IaC ethos.

Then I figured I might go with Terraform and I found some seemingly good starters like https://github.com/aws-ia/terraform-aws-ecs-blueprints https://github.com/cloudposse/terraform-aws-ecs-web-app https://github.com/turnerlabs/terraform-ecs-fargate but the examples are just lacking. They don’t have any examples for multiple containers that can access each others’ resources that I can find. Reading these templates has at least given me a better idea of the resources I need to provision in AWS but the networking and configuration still frighten me. Like do I need to configure nginx with a reverse proxy myself? How do I orchestrate that container with the others? And apparently services can crash and just not restart? And I need to make sure to configure volumes for data that needs to persist. And setting up the CI/CD seems daunting.

I’ve also heard about docker swarm, kubernetes, pulumi, AWS SAM, etc but it’s a lot to learn. When I go on Discords for web frameworks, mostly everyone including the devs of these frameworks use 2nd tier managed providers like Vercel, Fly, Netlify, Supabase, Cloudflare, etc. But many of those are just not as reliable as core cloud providers, the cost is way higher, and now you’re setting up a local stack that probably wildly differs from how it will work in production between those services. Glad to see I’m not alone in a very reasonable expectation of a simple way to orchestrate multiple containers on AWS, what must be the most common use case web developers have

[latchkey]

I feel like you've gone down the rabbit hole to the point that you've over complicated everything and now you can't do anything.

Take a step back and simplify everything.

Personally, I just use GCP cloud functions talking to a GCP managed postgres database. I don't worry about all the deploy stuff since their tooling takes care of it for me... heck, integrate it with github actions and it is just a git push to go live.

GCP is also next to free for low tier usage. Last I looked, a tiny postgres instance was one of the cheapest out there.

Then, just put cloudflare in front of GCP and now you've got the ability to use their functions in front of GCP too.

Fully scalable, relatively simple and low cost.

[brundolf]

To add another simple setup, I've been trying out:

- Static front-end hosted on render.com

- Back-end web service on render.com

- Postgres on (you guessed it) render.com

Each is an easy-to-manage item on the dashboard. They can each be scaled up quite a bit through the web UI if needed

Front-end and back-end are subdirectories of a single repo. Deploys are automatic on push

For local development the front-end can be served statically by a filesystem-based HTTP server

Back-end is Deno, so there's basically no configuration or build step or anything; running locally is `deno run`. It doesn't have to be Deno; Go, Rust, and others only need a single compiler/runtime on the system. Just pick one like that with a single system dependency and install it manually, I promise it'll be fine

No local Docker is needed at all

Another thing I love about this setup is that - just like it's trivial to run it locally - it's trivial to move to a VM or another provider because it has bare minimum infrastructure concerns/entanglements

[latchkey]

Awesome thanks for the write up. Yea, what I'm seeing now is that this style of development is becoming more and more commoditized. There is very little vendor lock-in. Moving between these platforms or even hosting on multiple of them even at the same time, is going to become more and more common over time.

[brundolf]

> But many of those are just not as reliable as core cloud providers

Aren't they? I've never heard this, do you have a source?

> the cost is way higher

Depends. For small-medium stuff the cost may be "way higher" in that it's dollars instead of pennies per month, but you have to weigh that cost against the cost of your time (how many months of PaaS hosting did the past week cost you in dev hours?). I'm sure the economics become significant at some scale, but I'd ask yourself whether they are at your scale

> and now you’re setting up a local stack that probably wildly differs from how it will work in production between those services

That doesn't have to be true at all; many of these services let you ship Docker containers if you want to (and manage everything else from there), but it's possible to go without even that: https://news.ycombinator.com/item?id=34243045

I'd recommend taking a step back and seeing how much complexity is really necessary for what you're trying to do

[ecuaflo]

There was actually just a thread about Fly and someone pointed out lots of outages https://news.ycombinator.com/item?id=34240679

I also meant this in the sense that you are locking yourself into very immature companies that can shut down anytime the VC money stops. They are not proven like the core cloud services that the Fortune whatever companies all rely on. Also with those core cloud services being more low level, you are free to move between them much easier than the hyperpreconfigured 2nd tier serverless services.

I’m certainly not familiar with all the providers. Maybe there is one I haven’t found yet that would be a better fit

[brundolf]

> with those core cloud services being more low level, you are free to move between them much easier than the hyperpreconfigured 2nd tier serverless services

I actually think it's the exact opposite

With the big providers you can create elaborate architectures that pull together a bunch of hyper-specific services, or if you do everything bare-metal, you have to write (again, elaborate) configurations in terraform or whatever else

With a PaaS, your contract with the platform is usually very simple by design: "download the code and run this command", or "expose a postgres DB", or "serve these files". Because the contract is so simple, it's very easy to run the same stuff locally on your dev machine, or move it to another provider. Because it doesn't care about what architecture it's running on, it doesn't care about what platform it's running on

It's the same as with programming languages: if you write something in assembly, its contract with the host system is very broad, which means it's tightly coupled to the OS and the chip architecture. If you write something in Java - a higher abstraction level - it can be run on anything under the sun, because it cares very little about the details of the environment it's running in

[klooney]

If you want something that's free locally, but has a pretty good port-to-cloud story, you want kubernetes.

Getting live with EKS in AWS is a little scary and painful and not cheap, but if you just work through https://www.eksworkshop.com/ it's pretty plug and chug.

Doing it with Cloudformation or Terraform or something built on top like Pulumi or the CDK is something I wouldn't recommend unless you do this for a living. Just stand up the infra manually- doing a bad job is like 10% of the work required to do a "good" infra as code job, and you don't sound interested in the project.

All your actual app stuff can be nice declarative k8s yaml, and you'll be good to go indefinitely.