Fly.io: The reclaimer of Heroku's magic

The main thing I want is pipelines - review apps, staging apps, and promotion to production, all integrated closely with GitHub, along with a slack integration that lets me do all of it in a public chatroom.

Until another service has all of this, we’re sticking with Heroku.

I get the intention with Slack. I’ve never understood, except for the geek cred, pushing work into chat services. Github is open to the team too.

I hear complaints about chat distractions and see engineers create those distractions. I’m at a loss why we want to do that to ourselves?

Nevermind it’s one more pipeline for messages to lost in. It’s needless complexity and configuration too.

Render has review apps (https://render.com/docs/preview-environments). We're actively working on pipelines (early access ETA late summer).

First, Heroku's pipelines and GitHub integration are (or, I guess, were) excellent.

We (Fly.io) intentionally didn't build a pipeline replacement. We exist for one reason: to run apps close to users. We're just now to the size where we can do that well. It'll be a while before we can get good at a second thing. Heroku shipped them something like 8 years after they launched.

At the same time, GitHub actions and Buildkite are _very_ good. They're less opinionated than Heroku Pipelines, but I don't regret figuring out how to use them for my own projects.

I think there's a chance that emulating Heroku that closely is a path to failure in the 2020s.

The main reason is to use a chat solution is as a unified ledger / single pane of glass. Silly as it is, there isn't really a better solution out there for "integrate all of my third-party deploy, CI, build, etc. status updates in real time, in one place." Sure, someone can click into GitHub, but if you use another service to deploy into, does GitHub pipe the status of that service into your dashboard? How about error logs and alerting, do they go there? If there's a customer incident, does the trust site status show up as well?

On Slack and other chat solutions, it's possible to set up a #operations style single-pane-of-glass channel with deploy notifications, error alerting, and customer communication platforms all pushing to the same place. If an incident occurs, engineers, product, support, etc. can all collaborate around what's going on in real-time without needing to ask "hey has someone updated the trust site yet?" or click into 10 different tabs.

It's honestly pretty good when it works well and really bad and noisy when it doesn't, but it has a place.

Non-engineering are usually in Slack too, which really helps when support, product, or the field need quick answers to easy questions like "has this commit been deployed yet today?"

Perhaps for looking back to see the history of things, a unified ledger is convenient. But as a notifications/alerts solution it’s terrible because it essentially guarantees that the signal to noise ratio will be incredibly low.

Any plans for a chatops extension for Slack? The best think about Heroku is being able to say "/deploy [app]/[branch] to [environment]", and have it Just Work, all with inline threads that convey status updates about the deployment. Does Render plan to build something like that?

Yeah, totally get that.

> I think there's a chance that emulating Heroku that closely is a path to failure in the 2020s.

I'm not sure I agree, considering that a different platform emulating this exact setup with ~zero configuration is basically everything we want! GitHub actions is (I agree) really great and very versatile, but I'll take Heroku's UI over digging through actions plugin documentation for hours any day.

No immediate plans, but I'd love to see this on Render at some point, and not just for Slack.

Chat is a multi-player CLI. Anything you would do in a terminal that your team members should also know about can profitably be integrated with chat.

This just depends on how disciplined you are. We use a system where backend errors are logged to slack, and then we treat addressing the source of the errors as an immediate priority. Keeping the SNR high is a priority. Plus generally being very selective about what goes into the channel.

I'd never, ever go back to working without chat.

We've switched to Discord (because reasons. Slack is much better for work though) and I rewrote a bunch of Slack hooks to get Dicord notifications.

> I hear complaints about chat distractions and see engineers create those distractions.

People will complain no matter what.

We’re super early but if all of that running on top of your own cloud using tools like cloud run or fargate sounds interesting, check out www.withcoherence.com (I’m a cofounder).

A coworker and I basically built review apps on top of hubot interactions with the Heroku API before review apps existed. It was probably the work of about two weeks to get right.

Yes, it’s automation you have to own, but it changed very little once it was done and provided phenomenal value. I wouldn’t let those features hold you back from exploring other options.