I love the idea of a Heroku style site for a single-founder startup but don't like the idea of third party buildpacks that lack EF migration support once deployed etc.
Speed. I’m working on a new personal project. The last project I was on, I took time to write Terraform to deploy to AWS Elastic Beanstalk where I ran Docker containers. It took me two days to get all of that setup, and I consider that time to have been poorly utilized.
Yes, I can use Docker and deploy to my own server, but I really want to focus on the product/service being built, not infrastructure. I’m using Heroku now because it is free (for the moment), and setup is relatively quick. I just added Redis and Celery last night. That was mostly a matter of clicking to add the add-on, and updating some Django settings.
If the project takes off, and makes some money, maybe I’ll move to a different provider. At this stage, however, the costs outweigh the benefits.
> The last project I was on, I took time to write Terraform to deploy to AWS Elastic Beanstalk where I ran Docker containers. It took me two days to get all of that setup, and I consider that time to have been poorly utilized.
To be fair, you don't need that whole stack to run containers, and most of the work you had to do was to operate a particular choice of infrastructure services and tooling that are not necessary to run containers.
All you need to run containers in a single-node setup is Docker, and that's it.
That's true. I wanted to maintain good continuous delivery practices while minimizing the need to worry about individual resources (e.g. web server, database server, DNS), which is why I opted for Elastic Beanstalk. Then I fell down the Terraform rabbit hole.
Docker definitely gets the job done, but I would still have to worry about dealing with data backups, DNS, and deploying to the server. Heroku worries about all of that for me now.
Visual Studio can also help automate running EF Migrations scripts, you just provide a Connection String under EF Migrations settings in the Publish settings.
What it does under the hood is also relatively easy to script or automate in other places. It builds a script artifact using:
dotnet ef migrations script --idempotent
That gives you a "run anywhere" SQL Server T-SQL Script (I don't think it supports other databases) that will run any migrations that don't exist in the target database (and is safe if the target database is already up to date).
Then it's just a matter of running that script on the right database.
Also you might be interested in looking at FluentMigrator for database migrations. It's a tad more work but they have a really well thought out fluent interface for writing migrations. I find it much nicer to work with than ef migrations
Appharbor does look like a zombie startup. The last blog post 5 years ago, the last tweet 3 years ago. Alexa ranks them at #466,765. I was their customer many many years ago but eventually switched to AWS.
19 comments
[ 3.0 ms ] story [ 59.4 ms ] threadYes, I can use Docker and deploy to my own server, but I really want to focus on the product/service being built, not infrastructure. I’m using Heroku now because it is free (for the moment), and setup is relatively quick. I just added Redis and Celery last night. That was mostly a matter of clicking to add the add-on, and updating some Django settings.
If the project takes off, and makes some money, maybe I’ll move to a different provider. At this stage, however, the costs outweigh the benefits.
To be fair, you don't need that whole stack to run containers, and most of the work you had to do was to operate a particular choice of infrastructure services and tooling that are not necessary to run containers.
All you need to run containers in a single-node setup is Docker, and that's it.
Docker definitely gets the job done, but I would still have to worry about dealing with data backups, DNS, and deploying to the server. Heroku worries about all of that for me now.
Setting up a database of your choice (Postgres, MySQL, SQL Server) is nice and easy too.
What it does under the hood is also relatively easy to script or automate in other places. It builds a script artifact using:
That gives you a "run anywhere" SQL Server T-SQL Script (I don't think it supports other databases) that will run any migrations that don't exist in the target database (and is safe if the target database is already up to date).Then it's just a matter of running that script on the right database.
https://cloud.google.com/appengine/docs/flexible/dotnet/an-o...