Live data from Hacker News

Ask HN: Where do you deploy to in 2018 and how?

news.ycombinator.com

1–10 of 85 posts

Ask HN: Where do you deploy to in 2018 and how?

#1
I've been using Heroku for several years now, and as it happens to everyone eventually it becomes just too expensive.

I'm curious to know what people here use to deploy, and where are you hosting your apps.

Personally I'm looking for an experience as similar as possible to Heroku, any recommendations?

Re: Ask HN: Where do you deploy to in 2018 and how?

#3
What parts of Heroku in particular are you interested in seeing in an alternative? If a friendly user interface is a big part of the ask, your options are unfortunately limited (at least among the big cloud providers, I'm unfamiliar with smaller providers).

AWS's Elastic Beanstalk doesn't have any UX to speak of (just a few options to fiddle and some weak logging support). It's a very raw service, much like the rest of AWS (rock-solid infrastructure to bring-your-own stuff). They take care of infrastructure but developer pleasantries are entirely up to you.

App Engine is significantly better on the UX front - you get error reporting, metrics, logging, etc all in a single cohesive web app. In my experience I hit some hard to debug / resolve quirks, but that is very much a ymmv situation. It can be tricky to figure out how to configure the right pieces / permissions in their new app engine variant (docker-based). I wouldn't use the classic variant at this point, it's pretty heavy on the vendor lock-in front. It's great if you need the specific capability of classic app engine but that's most likely not what you need.

If you're using Heroku's hosted postgres, know that GCloud's postgres support is still "beta". AWS RDS on the other hand has very good postgres support.

In both cases, deploys aren't just a git push, but use a custom CLI (`eb deploy` and `gcloud something something`). They're also both pretty typically tough to get to the first successful deploy with - for example Elastic Beanstalk will spend quite a while attempting to recover from deployment errors, and if you've never deployed a successful version it's very bad at that, and it also blocks deployments while it attempts to recover. So you end up stuck while it attempts to recover from a problem it will never recover from for a bit (this has been a problem for literally every beanstalk service I've ever deployed, heh).

You can also go something like the hosted Kubernetes route. Currently GCloud is king here, but naturally that's a command-line only UX unless you deploy your own kubernetes UI service (unfamiliar with options there)

Unfamiliar with Azure's offerings.

Re: Ask HN: Where do you deploy to in 2018 and how?

#5
Azure app service, deploy to it with MSBuild (which we fire off from teamcity, which git clones, runs build scripts, then deploys with msbuild). App services have a 'staging' deployment slot, so you can deploy to the staging slot, test it, then swap the slots and you are live.

App Services are cheap and easy to manage, if you write efficient code they have plenty of horsepower for medium sized websites.

Re: Ask HN: Where do you deploy to in 2018 and how?

#8
In making a selection like this you need to separate the deploy UX (git push heroku master) from the underlying service.

Things like dokku, etc are great at providing the UX and generally really solid.

However, much of the benefit of Heroku is that they handle some/much of the underlying sysadmin tasks you'd otherwise need to worry about. It's easy to discount that as it's mostly invisible until there's a serious problem.

A middle ground between putting dokku onto a VPS is perhaps Amazon's Elastic Beanstalk service combined with Amazon RDS which provides you a big chunk of the functionality (albeit in a less slick wrapper).

Re: Ask HN: Where do you deploy to in 2018 and how?

#10
AWS, mostly. On my servers I have simple shell scripts that have functions for pulling and running Docker images. Locally I use rake to build and push Docker images. Finally, Rake executes the deploy script on the server via ssh which pulls and runs the new images.

It's not fancy like dokku (or even Docker Compose), but it's composed of very minor pieces that are easy to debug and extend.

Not knowing if Docker Compose has executed successfully, and if I'm on the newest image or not, grew to be an extra todo in my checklist when debugging my applications.

Post reply on HN