Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A simple DIY Heroku replacement to keep your hosting costs down

github.com

Post reply on HN
Print view View original

71–76 of 76 posts

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

#71

Post by yebyen »

jacques_chester wrote: post #69
yebyen wrote: post #67

Earlier quoted context omitted.

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,…

> developers can deploy rapidly, get databases and integrations on a self-serve basis, enjoy uniform platform features

That's what I'm looking for, personally. It's a real headache that in our environment, we usually have exactly one each: dev, test, prod. Sometimes you need a couple more dev environments for a few days, but it's totally not worth it to go through a RFC or REQ process to get it. Instead, you tend to get developers merging features before they're ready, just to be able to get them in front of customers at the same time.

> tl;dr we build installable superpowers.

I was assuming this, but it's good to hear it out loud ;)

Honestly don't know what my teams will go with, but we're starting a trial of ECS for the organization's first formal foray into containers. Convox looks to me like it might actually make using ECS palatable. I was frankly not at all optimistic about ECS until I found it.

The scope of the pilot is written to deliberately exclude K8S, which I'm not sure I agree with, but there are also a lot of people saying they believe we will fail on our first attempt to implement containers as an organization, and I'm not sure there is any choice we can make (K8S or otherwise) that would surely make those people wrong (to make the first attempt succeed.) Solely due to institutional inertia, and also difficulty integrating with people who are slow to adopt new things. It's tough working in a group where everyone must insist on moving together.

As a developer, I've been using containers seriously in various shapes and sizes since probably well before 2013; here it's still considered new (and scary.)

So I almost prefer that we fail hard, at least once, so that we're not stuck carrying legacy garbage along with us forever. Failed launches may leave orbital debris to burn up on reentry. But a successful launch could remain in orbit with its components, for better or worse, basically forever...

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

#72

Post by simplify »

alpha_squared wrote: post #65
simplify wrote: post #63

Earlier quoted context omitted.

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.

That's the fault of the original claimer. They shouldn't be making subjective claims and trying to pass it off as objective.

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

#73

Post by yebyen »

jacques_chester wrote: post #70
yebyen wrote: post #64

Earlier quoted context omitted.

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 bui…

That's really cool and good to know. I will keep that in mind! Thanks

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

#74

Post by jacques_chester »

yebyen wrote: post #71
jacques_chester wrote: post #69

Earlier quoted context omitted.

> 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,…

> developers can deploy rapidly, get databases and integrations on a self-serve basis, enjoy uniform platform features That's what I'm looking for, personally. It's a real headache that in our environment, we usually have exactly one each: dev, test, prod. Sometimes you need a couple more dev environments for a few days, but it's totally not worth it to go through a RFC or REQ process to get it. Instead, you tend to…

The biggest risk is going to be the temptation to roll your own PaaS on top of ECS. Later on it might be to roll your own on top of Kubernetes.

It just doesn't seem like a lot of work. Assemble this logging system, that proxy ... before long you have a working PaaS and a source of pride and joy.

And a future millstone around your neck.

A lot of people who work at Pivotal have worked at other places that tried to DIY. Usually this was a long-running bonfire of cash, during which any potential competitive advantage was lost. No matter how technically capable your team is, there is just a hell of a lot of engineering to be done to build systems of this depth and breadth, especially when they are distributed systems.

Software generally is a sharp illustration of comparative advantage. Even if you can do everything better than anyone else, it does not make sense to do everything. Focus on the area where you can add the most value. It is almost certainly not in rolling your own cloud application platform.

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

#75

Post by timewarrior »

michaelbuckbee wrote: post #30
timewarrior wrote: post #23

Earlier quoted context omitted.

While I agree that a script can't match what Heroku does, in the end Heroku shouldn't be used for anything serious. I love Heroku for it's simplicity. They give you very few levers, making it less likely for you to screw up. When we had a production add we faced following issues with Heroku: 1. Frequent downtimes. Heroku would have a 3-4 hour downtime every 2 months. In some cases, site would be down. In most cases y…

I think we're agreeing more than disagreeing here. But I think you're not properly valuing yourself in this scenario. People that can utilize AWS and navigate through all the services, use CloudFormation, etc. are in a high demand and at some level in the cost analysis you need to factor that in.

In terms of my time, it has been very valuable.

I had to spend quite some time working around Heroku's limitations. We have had 100% uptime (based on external monitoring) since we moved to Elastic Beanstalk.

Health check based rolling deploys are awesome. Caught production bugs 3-4 times.

I agree that it was easier for me to do, because I have extensive DevOps experience. However if someone is getting to anything more than a hobby project, consider investing in someone to build a basic CloudFormation script for ElasticBeanstalk. I will open source ours in a couple of months (things really hectic right now).

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

#76

Post by maxehmookau »

diggan wrote: post #68
maxehmookau wrote: post #57

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.

I am not (and have never been) inside the Silicon Valley bubble. I live in the UK and work outside of London. I'm as far from the SV bubble as you can get and still work in tech.
Post reply on HN