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

We are far from a better Heroku for production apps in a hyper cloud

about.gitlab.com

Post reply on HN
Print view View original

261–270 of 275 posts

Re: We are far from a better Heroku for production apps in a hyper cloud

#261

Post by jrochkind1 »

sergiotapia wrote: post #252
jrochkind1 wrote: post #22

So I think heroku has stagnated a bit, and I am definitely very open to "better herokus". But the idea that something you did in five minutes is going to be better than heroku (in all ways?) is.... I don't know what the adjective is. Heroku is very mature and polished software, that almost always does what you expect -- it's a very non-leaky abstraction, I guess. You can almost always get away with ignoring the detai…

render.com is a better Heroku. Absurdly easy, inexpensive and killer UX. They also have in beta a way to spin up whole environments for every PR your dev team has. Imagine every PR has it's own database, backend and frontend, spun up/killed on the fly. It's a very compelling feature.

I believe heroku has this feature too, no?

https://devcenter.heroku.com/articles/github-integration-rev...

But I am interested in checking out render, that I just heard about here.

(Not particularly interested in spending time checking out whatever Gitlab OP is trying to tell me about tbh)

Re: We are far from a better Heroku for production apps in a hyper cloud

#262

Post by jrochkind1 »

sytse wrote: post #146
detaro wrote: post #120

Earlier quoted context omitted.

What difference is the "production app" distinction supposed to make? Its not clear from neither the article nor the linked comment. If it's an attempt to suggest that Heroku isn't suitable for production use, that's going to need a lot of argument backing it up.

A production app has stateful services that retain data between deployments. The ambition of the 5 minute production app is to make this faster than doing it on Heroku. The article doesn't make this case at all. Heroku is suitable for production and we didn't intent to suggest otherwise.

Typical heroku apps have services like postgres and redis that maintain state between deployments. This is very typical, and trivial to provision. Still not sure what you mean. Are you sure you are at all familiar with heroku?

Re: We are far from a better Heroku for production apps in a hyper cloud

#263

Post by jrochkind1 »

ljm wrote: post #214
mvanga wrote: post #43

Honestly, this article presents a fairly ridiculous comparison. You could bump deploy times on Heroku to 20 minutes and I would still use it without a second thought. At best, I'll complain a little louder. Here's step 1 from the article: The documentation says to create a new AWS IAM role with credentials for automation. At this point, you've already failed. You are forcing more complexity on me than I have to care…

Heroku's pricing is also justified IMO, since if you're using Heroku you're most likely saving money on hiring an on-call infrastructure or ops team, and saving money on having your engineers switch focus from feature development to maintaining the system, or doing dev-ops work. You're paying Heroku to do the operational stuff for you so you can spend more time building your product. That's a price well worth paying…

> even then I don't think the default next step is going full-blown cloud and K8S

What would you suggest as a 'next step' after heroku?

Re: We are far from a better Heroku for production apps in a hyper cloud

#264

Post by ksec »

darkr wrote: post #198
darkwater wrote: post #164

Earlier quoted context omitted.

> Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup. I fail to understand this. If Heroku is on AWS, Heroku is selling its services at price X. AWS is getting from Heroku Y money, where X > Y (or it should at least, if Heroku is not operating at loss). If Amazon owns Heroku it could sell its services…

> I fail to understand this Parent was proposing that AWS sell Heroku services at cost. As you say, my point was it doesn’t make sense

Heroku Buy AWS services at standard AWS Price (X) * (Substantial) Discount.

HeroKu Sell their services at (Y) where currently Y is >(X).

If they had acquired Heroku by Selling it at AWS Price (X), Amazon is still earning where they previously were not earning from those heavy Discount. At the expense of the Operational Cost of Heroku Team. And the benefits of further lock in and additional market segment which is currently not very well served by AWS.

Re: We are far from a better Heroku for production apps in a hyper cloud

#265

Post by funnygitlab »

sytse wrote: post #158
alecbz wrote: post #149

Earlier quoted context omitted.

It's a blog post on the company's official blog, no? I doubt it's like a free-for-all where any employee can post whatever they want without any review. Judging GitLab based on the content posted on their blog seems like fair game.

It is fair game to judge us based on our blog. At the same time it is a free-for-all for employees for blog posts marked Unfiltered as this one is. The author apologized in https://news.ycombinator.com/item?id=26555617 and we've made 8+ updates to the article to reduce the bias https://gitlab.com/gitlab-com/www-gitlab-com/-/commits/maste...

> At the same time it is a free-for-all for employees for blog posts marked Unfiltered as this one is.

So you allow your employees to have a "free-for-all" approach when posting blogs to your official company website? So tomorrow, one of your employees can post a "We are now Heroku" or "We have acquired Heroku" or some such post and your response will be to blame the author (even though, as per the records, in this current case you are one among the approvers of this blog[1]) and tell the rest of us that since this blog is in "Unfiltered" section, the readers are to be blamed for taking the blog seriously?

[1] https://news.ycombinator.com/item?id=26557589

Re: We are far from a better Heroku for production apps in a hyper cloud

#266

Post by ulisesrmzroche »

jack_riminton wrote: post #169
alecbz wrote: post #154

Earlier quoted context omitted.

I'm often confused at how poor so many engineers' product-sense is. Especially infra engineers (speaking as one). It's one thing to not have good product-sense when you're not the user, but for products like Heroku you literally are. My best guess is that a lot infra engineers actually value seeing the complexity and being able to understand all the pieces being used in the system more than they value getting somethi…

It must be something to do with forgetting how hard things are for novices Reminds me of the famous old HN comment about Dropbox

That one never gets old.

Re: We are far from a better Heroku for production apps in a hyper cloud

#267

Post by colesantiago »

jack_riminton wrote: post #169
alecbz wrote: post #154

Earlier quoted context omitted.

I'm often confused at how poor so many engineers' product-sense is. Especially infra engineers (speaking as one). It's one thing to not have good product-sense when you're not the user, but for products like Heroku you literally are. My best guess is that a lot infra engineers actually value seeing the complexity and being able to understand all the pieces being used in the system more than they value getting somethi…

It must be something to do with forgetting how hard things are for novices Reminds me of the famous old HN comment about Dropbox

https://en.wikipedia.org/wiki/Curse_of_knowledge

Re: We are far from a better Heroku for production apps in a hyper cloud

#268

Post by garethmcc »

jopsen wrote: post #231
leerob wrote: post #165

Earlier quoted context omitted.

Hey! Lee from Vercel here. Vercel isn't just for static sites – it also handles server-rendered applications, serverless functions, and hybrid frameworks (like Next.js). The current focus has been on an incredible front-end experience, but we're working to become a first-party integrator with your favorite backend solutions. For example, you can deploy a full-stack Next.js application with a PostgreSQL database in le…

Isn't serverless still just lambda..? Slow to boot, and subject to denial-of-wallet attacks. I do love vercel for static sites, and also think my blog with a minimal backend for comments is a good fit. But less sure how it'll hold up to even a single heroku dyno, which can do a lot of concurrent request at very low cost.

This is not entirely true. Firstly because Lambda keeps getting cheaper with the move from per 100ms billing to pwe 1ms being a big contributor. but also that I see organizations handling millions of requests per hour at peak but because of the dynamic nature of Lambda, any cost increase during the peaks are entirely offset by the reduced cost during low traffic periods since Lambda and associated services cost $0 when its doing nothing. Add in other services that act the same way such as S3, DynamoDB, API Gateway, etc and you have a very powerful, redundant and scalable applications without even really trying. No to mention that because spinning things out is so quick you can get a feature in front of users earning revenue way faster than any traditional service that requires some effort to start up, configure and maintain. And the costs associated with having VM's of the right size up to handle peak loads that are much slower to ramp up and down, creating significant periods of over provisioned capacity you pay for.

Lambdas are not slow to boot because of the methods used to tune how hot they stay; in a production application doing millions of invocations a day we saw 0.03 % of all invocations suffering a cold start that added an additional 100ms latency only. And if you absolutly have to have warm Lambdas always for even that 0.03% you can use provisioned concurrency that always keeps a certain number of Lambda functions warm.

Re: We are far from a better Heroku for production apps in a hyper cloud

#269

Post by garethmcc »

jopsen wrote: post #231
leerob wrote: post #165

Earlier quoted context omitted.

Hey! Lee from Vercel here. Vercel isn't just for static sites – it also handles server-rendered applications, serverless functions, and hybrid frameworks (like Next.js). The current focus has been on an incredible front-end experience, but we're working to become a first-party integrator with your favorite backend solutions. For example, you can deploy a full-stack Next.js application with a PostgreSQL database in le…

Isn't serverless still just lambda..? Slow to boot, and subject to denial-of-wallet attacks. I do love vercel for static sites, and also think my blog with a minimal backend for comments is a good fit. But less sure how it'll hold up to even a single heroku dyno, which can do a lot of concurrent request at very low cost.

Oh yes, and serverless is not just Lambda, its a about the whole suite of cloud services you combine together to build your solution.

Re: We are far from a better Heroku for production apps in a hyper cloud

#270

Post by detaro »

boleary-gl wrote: post #245
detaro wrote: post #122

Earlier quoted context omitted.

What do you think where Heroku apps run? Why would anyone truly caring about hyperscale trust Gitlab to handle that?

Heroku apps run in a hyper scale cloud, sure, but they abstract away all of that. When you "graduate" from Heroku you have to move your entire app and re-architect the entire thing. The idea behind this effort is to put you in a cloud native hyper cloud environment of your choice to start with and make that just as easy as Heroku. The big difference will be when you "graduate" - you'll already be in AWS or what have…

I think the mention "hyperscale" is unnecessarily confusing here. At least in my perception, nearly nobody uses that term when they just talk about "using cloud services from AWS & Co", presumably you don't insist on limiting your product to just those (i.e. Terraform will happily talk to smaller Cloud providers like Hetzner too, presumably you don't intend to exclude them by design, but just understandably focused on the large names first?). People more usually (again, from what I see, you might have different experience with your target groups) explicitly say hyperscale when what they are doing is at that scale, and that's a level of complexity that's never going to be 5 minutes.
Post reply on HN