Maybe it's me but it feels like in a world where developers know the basics of how to build a container image, container-driven workflows stand to offer the ease that people originally expected from the cloud. Since I'm an ops-curious/leaning developer, it's hard for me to see how we don't standardize on this the way to deploy going forward. I'd never touch a buildpack if deploy-by-container was available but maybe this says more about me and most developers are the other way.
First the "almost" container (or container-but-not-called-that + lots of other stuff) approaches popped up:
- Google App Engine
- AWS Elastic Beanstalk
- AWS ECS
Now the "actually just give us a container" solutions seem to be growing/moving:
- Heroku (with containers, not buildpacks)
- Google Cloud Run
- Render
- Fly.io
- AWS Appp Runner
I'd also dare to propose that a vast portion of the developers opting for Kubernetes are doing it just to have this -- being able to throw up a container and have the rest be managed for you. Kubernetes is much more interesting than that on the ops side, but you honestly don't need it if you don't want to do anything fancy ops wise -- if all you're doing is running a rails/django/(nuxt|next|nest)js app with a database like Postgres RDS, you can be up and running without the rest of it, and scale up to your first 1000+ customers before trying to do anything fancy. If you pick a decent enough database (a nice extensible one like postgres) you may not even need a real queue or full text search for a while.
Feels like 90% of CRUD-y or SaaS-y apps out there never need more than app container + DB + Redis + S3 + Queues, and if it's simple enough there's no need to turn to other solutions. Expose everything to the internet (and use the appropriate security) and you don't even need to muck with networks anymore.
Do we have to pay separately for an ALB? I don't see anything about that in the App Runner pricing page, but there must be a load balancer there. If the load balancer is included in the App Runner pricing, then it would be nice if we could have a new version of ALB, or a new separate load-balancing service, that has purely usage-based pricing without the base hourly rate. That way we could save money on load balancing even if we can't work within the restrictions of App Runner (e.g. no VPC).
The load balancer is included with App Runner pricing. If you want usage based load balancer you should check out API gateway. If you want to reduce the amount of ALBs you use you can set up multiple target groups to share a single ALB. The AWS load balancer controller for Kubernetes supports ALB groups out of the box.
Ah, it hadn't occurred to me to use API Gateway in conjunction with containers; it's most well known for being used with Lambda, while ALB is used with containers (e.g. through the ALB ingress controller for Kubernetes). Are there limitations I should be aware of when using API Gateway with containers?
This is great, but without support for sqs it’s not quite as competitive with google cloud run as I’d like. That said I like that you don’t have to scale it to zero, that’s definitely a benefit over cloud run for workloads that can’t tolerate cold starts.
I’d use this today if it supported sqs or Amazon MQ (rabbitmq)
Can this scale down to 0 like Cloud Run? I can't tell from the docs if you can have NO provisioned instances and have the connection hold and warm up an instance on-demand.
We optimized the service to work with any container instead of eliminating cost. If you're not getting requests you have a reduced cost for consumed memory and instances but by keeping one warm it makes it so you don't have to engineer around cold starts.
First the "almost" container (or container-but-not-called-that + lots of other stuff) approaches popped up:
- Google App Engine
- AWS Elastic Beanstalk
- AWS ECS
Now the "actually just give us a container" solutions seem to be growing/moving:
- Heroku (with containers, not buildpacks)
- Google Cloud Run
- Render
- Fly.io
- AWS Appp Runner
I'd also dare to propose that a vast portion of the developers opting for Kubernetes are doing it just to have this -- being able to throw up a container and have the rest be managed for you. Kubernetes is much more interesting than that on the ops side, but you honestly don't need it if you don't want to do anything fancy ops wise -- if all you're doing is running a rails/django/(nuxt|next|nest)js app with a database like Postgres RDS, you can be up and running without the rest of it, and scale up to your first 1000+ customers before trying to do anything fancy. If you pick a decent enough database (a nice extensible one like postgres) you may not even need a real queue or full text search for a while.
Feels like 90% of CRUD-y or SaaS-y apps out there never need more than app container + DB + Redis + S3 + Queues, and if it's simple enough there's no need to turn to other solutions. Expose everything to the internet (and use the appropriate security) and you don't even need to muck with networks anymore.