undefined | Better HN

0 pointsemilsedgh1y ago0 comments

We've been on Heroku Enterprise for 8 years now. I read your comment and clicked on the link with so much enthusiasm.

Duh. You guys have completely forgotten who your audience is. Your audience is _application developers_. I have no idea what all that mambo jambo means in that article _and thats why I pay Heroku_.

I'm on Heroku because I don't want to know about cloud native and fir and open telemtry are. You tell me I should get excited on Heroku? How about improving your autoscaling options so the narrow response-time-based scaling is not the only option?

All that article tells me is that you guys are maybe improving your underlying infrastructure. Meh. Good for you. From a customer (AKA Application Developer) perspective nothing has changed.

0 comments

schneems1y ago

The blog post is one of three published recently. It's from Terence Lee, an architect and former maintainer of Bundler (Ruby package manager). He co-founded the Cloud Native Buildpack project and was part of open sourcing the original Ruby buildpack. He gets pretty into the weeds with the tech.

The other article that's not been linked yet is this one https://blog.heroku.com/next-generation-heroku-platform. It's still not exactly what you're asking for "give me the application features" but it is a little less lingo heavy.

One thing kinda hidden in there:

> and AWS Graviton into the platform.

That means ARM support. Already the Heroku supported buildpacks work with both AMD (x86) and ARM (aarch64). Think mac Intel versus M(1/2/3/4) chips.

> From a customer (AKA Application Developer) perspective

I posted another comment earlier. Local debugging with CNBs is pretty neat. But I also agree, I see this still as an "investment" phase. This is the start of the work, that gets us more fun stuff later.

> How about improving your autoscaling options so the narrow response-time-based scaling is not the only option?

This is not my team, so I'm speaking not from first-hand experience. It's my understanding that Kubernetes has a pretty rich ecosystem for autoscaling. On our current platform, if someone wants to try out an autoscaler, it's a bespoke solution and difficult to try in the wild. Moving to a more standards based and community backed infrastructure means what's easy to do on Kubernetes, should also be easy for us to do on Heroku on the new platform.

I hear that you care about autoscaling options and I'll pass that along. Anything specific in that area?

j / k navigate · click thread line to collapse