Live data from Hacker News

A simple DIY Heroku replacement to keep your hosting costs down

github.com

61–70 of 76 posts

Re: A simple DIY Heroku replacement to keep your hosting costs down

#61

Earlier quoted context omitted.

For the Kubernetes + Dokku replacement, GitLab's Auto DevOps https://docs.gitlab.com/ce/topics/autodevops/ can do a lot of stuff. It's included in CE, thus it's free.

That's a layer over Kubernetes and Prometheus, no? It looks good, but it assumes I've already installed the former.

In the next few months, GitLab supports GKE Cluster Integration. https://docs.gitlab.com/ce/user/project/clusters/index.html

You can set up your Kubernetes, Helm, Tiller, Runner, Prometheus by one click.

Re: A simple DIY Heroku replacement to keep your hosting costs down

#62
post #51
post #50

another option that is a pretty good Heroku clone is to deploy to a Deis stack. https://deis.com I set up a deploy on kubernetes a year ago and it was very close to Heroku -- impressive.

Yeah, Deis! I have been a big proponent of Deis even as Microsoft has acquired the team and they've gone more hands-off with the project. It's harder to make the case for Deis when there is nobody you can buy support from... (Is there anyone left that you can buy support from? I heard the easiest way to get an answer on the internet is to start by "being wrong"... secretly hoping there's still someone out there in th…

I think the two major platforms for PaaS into the foreseeable future are going to be OpenShift and Cloud Foundry.

Both have large engineering professional organisations involved, large community footprints and a lot of sales to pay for all of the above.

There is what I call the "kambrian explosion" of PaaSes being built on top of kubernetes. Most of these will, I think, shake out over the coming years and again, the heavy-duty PaaS market will largely be dominated by the two existing platforms.

Disclosure: I work for Pivotal, we're the leading contributor to Cloud Foundry. Red Hat is a competitor.

Re: A simple DIY Heroku replacement to keep your hosting costs down

#63

Earlier quoted context omitted.

> in the end Heroku shouldn't be used for anything serious. This is a provably false statement. There are thousands of companies running very serious things on Heroku handling load that would exceed the needs of the majority of audience here. All with near zero effort from a developer perspective. They've also always been transparent about downtime, retrospectively creating/amending cases if required. The only multi-…

> All with near zero effort from a developer perspective For a very small subset of developers. The last time I was tethered to a Heroku installation, I spend 60% of my time coding, and 40% of my time working around Heroku's shortcomings. It doesn't matter how many times you reply to people on HN stating that their position is "provably false," that doesn't make it true.

I've been using Heroku for many serious projects since its inception. It's been nearly a zero effort, especially compared to doing it all myself. This alone is enough to prove the statement false (counterexample).

Re: A simple DIY Heroku replacement to keep your hosting costs down

#64
post #56

Earlier quoted context omitted.

I use Deis on a single server. It works great. There are a few things you need to be aware of, but the tl;dr is that it works great for us. We'd be using it more, except that our org hasn't adopted containers in any meaningful way yet, and Deis is large and complicated, and a little too much for them to bite off and swallow all at once. They want to do a pilot on ECS so that we can say we're using more AWS services (…

That's very helpful, thank you! I was with you up until "Deis is EOL", I only want to use it for my sideprojects, but I still wouldn't want to be out of luck if something breaks on the next Ubuntu update and I can't get a fix anywhere :/ Maybe I should look into OpenShift instead, as that's more active?

I will tell you this: there is a group of people who are committed to keeping Deis alive, called Team Hephy and the Deis slack is still active. I've used OpenShift and it is certainly more active, but I also have the very strong feeling that Deis is "done" where many parts of OpenShift look like they are still evolving. (And I mean "done" in a good way.)

If you are not sure, feel free to drop in and ask any and all questions: https://slack.deis.io/

The announcement of EOL came in July, and the announcement that Team Hephy would take over was almost one month to the day later, in August. I have a lot of faith in the Deis codebase and I'm on Team Hephy now.

We have yet to put out a fully e2e acceptance test passing and providence-verified signed, versioned release of our own, but we have and know of a number of production users that still use Deis in Production.

It definitely does not feel like a ghost town on the Deis slack. Questions get answered. Neither does OpenShift (it is definitely not deserted, and it does not seem to suffer from "abandoned k8s fork" syndrome, they do keep up with the release cadence, because they have to.)

I would go with the one that solves your problem better. I'm personally still recommending Deis, as I like the built-in support for Heroku buildpacks that OpenShift lacks. (Convox also has support for this, on ECS.) I'm not aware of any K8S-native Deis competitor (other than Hephy) at least for now.

Edit:

The really nice thing about working in Kubernetes is that you have the conformance suite[1]. You shouldn't worry about breaking something with the next Ubuntu update, because if Ubuntu update has broken Kubernetes in a way that will cause Deis to fail, then it will not be a Kubernetes-conformant distro anymore (and there is a large list[2] of K8S-conformant distros and platform to choose from, so you should pick a conformant one[3] instead.)

So, your question should be whether Deis will continue to work on Kubernetes distributions that are conformant, and with some minimal research, I think you should be able to say that with a high degree of certainty it will, regardless of ongoing vendor support from either side.

Then, you can ask whether your K8S distro is likely to remain conformant. (This should be a no-brainer.) Finally, is there anything that can break within Deis internally (not related to how it interacts with Kubernetes) that would mean you'd have to stop using it?

For me, the big reveal / final test will be, can we upgrade from Cedar stack to Heroku 16, which is on Team Hephy's planned roadmap for the future.

If that goes smoothly, then I'm not sure what else there is to worry about.

[1]: https://www.cncf.io/certification/software-conformance/

[2]: https://www.cncf.io/certification/software-conformance/#logo...

[3]: https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4Eb...

Re: A simple DIY Heroku replacement to keep your hosting costs down

#65

Earlier quoted context omitted.

> All with near zero effort from a developer perspective For a very small subset of developers. The last time I was tethered to a Heroku installation, I spend 60% of my time coding, and 40% of my time working around Heroku's shortcomings. It doesn't matter how many times you reply to people on HN stating that their position is "provably false," that doesn't make it true.

I've been using Heroku for many serious projects since its inception. It's been nearly a zero effort, especially compared to doing it all myself. This alone is enough to prove the statement false (counterexample).

A little nitpicky here, but the original claim is "shouldn't be used for anything serious" which is an entirely subjective statement. I don't know if proving something subjective is false is really possible.

Re: A simple DIY Heroku replacement to keep your hosting costs down

#66
post #64

Earlier quoted context omitted.

That's very helpful, thank you! I was with you up until "Deis is EOL", I only want to use it for my sideprojects, but I still wouldn't want to be out of luck if something breaks on the next Ubuntu update and I can't get a fix anywhere :/ Maybe I should look into OpenShift instead, as that's more active?

I will tell you this: there is a group of people who are committed to keeping Deis alive, called Team Hephy and the Deis slack is still active. I've used OpenShift and it is certainly more active, but I also have the very strong feeling that Deis is "done" where many parts of OpenShift look like they are still evolving. (And I mean "done" in a good way.) If you are not sure, feel free to drop in and ask any and all q…

Thank you, the fact that there's a team that will take over puts my mind at ease somewhat. I'll give Deis a shot, thanks again!

Re: A simple DIY Heroku replacement to keep your hosting costs down

#67
post #51

Earlier quoted context omitted.

Yeah, Deis! I have been a big proponent of Deis even as Microsoft has acquired the team and they've gone more hands-off with the project. It's harder to make the case for Deis when there is nobody you can buy support from... (Is there anyone left that you can buy support from? I heard the easiest way to get an answer on the internet is to start by "being wrong"... secretly hoping there's still someone out there in th…

I think the two major platforms for PaaS into the foreseeable future are going to be OpenShift and Cloud Foundry. Both have large engineering professional organisations involved, large community footprints and a lot of sales to pay for all of the above. There is what I call the "kambrian explosion" of PaaSes being built on top of kubernetes. Most of these will, I think, shake out over the coming years and again, the…

Thanks for chiming in, Jacques from Pivotal!

I don't know which teams have the most meat behind them, but I know my team (or, the part of my team that deals with infrastructure and platforms, at least...) has taken a guarded approach while embracing as much as possible everything that AWS does.

So while I've recommended Deis and OpenShift I've only really been able to see them start to take a serious look at Kubernetes now that Amazon says it's a thing to look at. We don't have any K8S or containers at all, except for our Jenkins server. We knew this announcement (EKS) was probably coming, so we started to look at it again weeks and months ago, and we still haven't really made any progress. The working group is formed and we're committed... to looking at it. Starting now.

We haven't really even looked at either OpenShift or CloudFoundry. So I'm asking you, in the hopes that you'll give me something I can relay to my team, why do you think CloudFoundry will win? What are the major advantages of CF?

Large engineering effort, community footprint, and sales are all good indicators, but from a technical perspective, why do you think we should be looking at CF?

Disclosure: I work in University IT, where we have a majority of legacy projects and large databases to support, as well as incidental development efforts that we'd love to support with a platform (like the project I'm working on, a Rails app that provides a suite of workflow actions for Human Resources and Payroll to obviate their antique paper-esque forms processes)

Re: A simple DIY Heroku replacement to keep your hosting costs down

#68

It's been said already, but the idea that Heroku is expensive is provably incorrect. They're not providing hosting, they're providing a service. If I want self-hosted platforms, I'll manage my own docker containers on a GKE cluster or something similar. As it turns out, I want to write code and scale it to millions of people. Heroku lets me do that, and I don't need to hire an SRE team.

Well, maybe provably incorrect for you but I can see that if you're a company outside the Silicon Valley bubble, Heroku would be way too expensive compared to other solutions. Even for me personally (living in Barcelona) I think it would just be too expensive to use for anything without feeling like I'm bleeding money.

Re: A simple DIY Heroku replacement to keep your hosting costs down

#69
post #67

Earlier quoted context omitted.

I think the two major platforms for PaaS into the foreseeable future are going to be OpenShift and Cloud Foundry. Both have large engineering professional organisations involved, large community footprints and a lot of sales to pay for all of the above. There is what I call the "kambrian explosion" of PaaSes being built on top of kubernetes. Most of these will, I think, shake out over the coming years and again, the…

Thanks for chiming in, Jacques from Pivotal! I don't know which teams have the most meat behind them, but I know my team (or, the part of my team that deals with infrastructure and platforms, at least...) has taken a guarded approach while embracing as much as possible everything that AWS does. So while I've recommended Deis and OpenShift I've only really been able to see them start to take a serious look at Kubernet…

> Large engineering effort, community footprint, and sales are all good indicators, but from a technical perspective, why do you think we should be looking at CF?

Broadly it's that a good platform gets everyone out of everyone's way.

Cloud Foundry (these days, it's called the Application Runtime or CFAR) has made it possible for small teams of operators to support thousands of developers and applications. Similarly, it means developers can deploy rapidly, get databases and integrations on a self-serve basis, enjoy uniform platform features and so on.

There's now a lot more interest in the container as the unit of deployment, which is where kubernetes has become the winning orchestrator. So there's also a Cloud Foundry Container Runtime (CFCR), which is based on kubernetes, designed to use the same low-level operator tooling, BOSH, and to integrate smoothly with the Application Runtime.

Both the Application Runtime and Container Runtime are intended to run on any major IaaS; BOSH provides a uniform layer that abstracts away the raw interfaces. So you can deploy to AWS, GCP, Azure, OpenStack, vSphere, RackHD and there are others I forget.

Last week we had our flagship conference, Spring One Platform, which had a parade of customers talking about how much faster they move. Months per deployment turning into deployments per day. Thousands of developers running tens of thousands of apps. I am aware of customers handling billions of requests per day and handling hundreds of millions of business events using CF. Going through black friday effortlessly without having to massively overprovision.

tl;dr we build installable superpowers.

Re: A simple DIY Heroku replacement to keep your hosting costs down

#70
post #64

Earlier quoted context omitted.

That's very helpful, thank you! I was with you up until "Deis is EOL", I only want to use it for my sideprojects, but I still wouldn't want to be out of luck if something breaks on the next Ubuntu update and I can't get a fix anywhere :/ Maybe I should look into OpenShift instead, as that's more active?

I will tell you this: there is a group of people who are committed to keeping Deis alive, called Team Hephy and the Deis slack is still active. I've used OpenShift and it is certainly more active, but I also have the very strong feeling that Deis is "done" where many parts of OpenShift look like they are still evolving. (And I mean "done" in a good way.) If you are not sure, feel free to drop in and ask any and all q…

I used to work on buildpacks -- can I suggest getting in touch with the Cloud Foundry Buildpacks team? They also do a lot of work around the Ubuntu base image (cflinuxfs2) and there's been work towards cflinuxfs3.

They also used to use soft-forked Heroku buildpack code. Almost all of the Cloud Foundry buildpacks have now been rewritten on top of a single shared library. The strength of Heroku's code was that each buildpack has a maintainer familiar with the relevant ecosystem. The weakness was that they were all different. Often forked from a previous one and then tinkered into submission.

Post reply on HN