4 ms·

Along those lines, a few years ago I joined a company where they had just switched from Heroku to direct-AWS hosting for their infrastructure (to save $$). The

Along those lines, a few years ago I joined a company where they had just switched from Heroku to direct-AWS hosting for their infrastructure (to save $$). The devs had gotten used to the ease of Heroku deployments and Kubernetes wasn't yet a thing. So one of the DevOps team reimplemented the Heroku CLI as a massive, self-invoking Go monolith. It had everything from Jenkins scripts to a near-complete Mesos/Marathon client to to local Docker support built in. Many places (especially the CI code) it self-invoked to access other subsystems. Furthermore, it was the dev's self-admitted first Go project (previously he worked in Java). Somehow this spaghetti-behemoth actually worked, and I spent the next year fixing bugs and adding features. We even modularized it enough to support deploys to either Mesos/Marathon or early Kubernetes. It still sticks in my head as an example of where somebody did everything "wrong," yet they still did it, and it ended up being extremely valuable to the company. I think nowadays with k8s being what it is, and with all the tooling around it and increasing industry expertise—not to mention managed offerings—Heroku is going to have a hard time.

rektide 6y ago
huge fan of k8s. drop what you're doing & use a cross-system object-storage/"apiserver" & control-loops to automate everything; embrace desired state management & thank me latter. but, Heroku &al have a lot of value left. there's just not that many folk trying to tame deploys on k8s via gitops. flux2 is the rage, it's all over the alpha geek's efforts[1], but it's usually used by someone carefully authoring a fairly complex Helm file, then building out a significant Flux2 HelmRelease object (ex: [2]). there's a bunch of other tools[3], & i'm frankly not familiar enough. but this idea of having a bunch of source that can deploy itself, simply, is still extremely rare even among the alpha-geek #gitops types. i'm sure some of these tools better match the simplicity of the Heroku model, corresponding branches to environments, which makes so so much sense, but so far i feel like such attempts are still basically unknown. heroku's really simmered it down to something that made extremely natural sense. huge props to that. too too much of this effort had to go into creating buildpacks & supporting language environments very very carefully very actively, that ability to stealth-containerize an app & not even notice is so much of the special sauce that makes this a hard, hard & eternal problem (because langauges/envs keep changing). there's still a lot of ease of use to Heroku that's potentially will be underrated and/or lost by the oncoming generations. i have high respect for how operateable Heroku is. [1] https://github.com/k8s-at-home/awesome-home-kubernetes https://github.com/k8s-at-home/awesome-home-kubernetes [2] https://github.com/onedr0p/home-cluster/blob/main/cluster/apps/media/bazarr/helm-release.yaml https://github.com/onedr0p/home-cluster/blob/main/cluster/ap... [3] https://github.com/weaveworks/awesome-gitops#tools https://github.com/weaveworks/awesome-gitops#tools
bdcravens 6y ago
We've since moved to ECS, but we used Cloud66 for a few years, which provided a Heroku-like deployment experience on our own EC2 instances.
EdwinLarkin 6y ago
I dont get this sentiment at all.If you are paying people to glue Ops and Dev you are already not the main target for Heroku. Heroku is for companies that are willing to pay for convenience.
- ebiester 6y ago
  Companies aren't static. I'd consider Heroku (or similar) to start, but once I had funding/revenue to support having ops, I would transition away. However, once you have developed a workflow, going back in developer experience is hard, and hacks like these become common. (I saw a team do a similar tool to avoid paying for Cloud Foundry.)

rektide 6y ago

huge fan of k8s. drop what you're doing & use a cross-system object-storage/"apiserver" & control-loops to automate everything; embrace desired state management & thank me latter. but, Heroku &al have a lot of value left. there's just not that many folk trying to tame deploys on k8s via gitops. flux2 is the rage, it's all over the alpha geek's efforts[1], but it's usually used by someone carefully authoring a fairly complex Helm file, then building out a significant Flux2 HelmRelease object (ex: [2]). there's a bunch of other tools[3], & i'm frankly not familiar enough. but this idea of having a bunch of source that can deploy itself, simply, is still extremely rare even among the alpha-geek #gitops types. i'm sure some of these tools better match the simplicity of the Heroku model, corresponding branches to environments, which makes so so much sense, but so far i feel like such attempts are still basically unknown. heroku's really simmered it down to something that made extremely natural sense. huge props to that. too too much of this effort had to go into creating buildpacks & supporting language environments very very carefully very actively, that ability to stealth-containerize an app & not even notice is so much of the special sauce that makes this a hard, hard & eternal problem (because langauges/envs keep changing). there's still a lot of ease of use to Heroku that's potentially will be underrated and/or lost by the oncoming generations. i have high respect for how operateable Heroku is. [1] https://github.com/k8s-at-home/awesome-home-kubernetes https://github.com/k8s-at-home/awesome-home-kubernetes [2] https://github.com/onedr0p/home-cluster/blob/main/cluster/apps/media/bazarr/helm-release.yaml https://github.com/onedr0p/home-cluster/blob/main/cluster/ap... [3] https://github.com/weaveworks/awesome-gitops#tools https://github.com/weaveworks/awesome-gitops#tools

bdcravens 6y ago

We've since moved to ECS, but we used Cloud66 for a few years, which provided a Heroku-like deployment experience on our own EC2 instances.

EdwinLarkin 6y ago

I dont get this sentiment at all.If you are paying people to glue Ops and Dev you are already not the main target for Heroku. Heroku is for companies that are willing to pay for convenience.

ebiester 6y ago
Companies aren't static. I'd consider Heroku (or similar) to start, but once I had funding/revenue to support having ops, I would transition away. However, once you have developed a workflow, going back in developer experience is hard, and hacks like these become common. (I saw a team do a similar tool to avoid paying for Cloud Foundry.)