Heroku is still probably the platform that offers the most well built-out "here's all your operational needs for the first N years of your business" system, without causing you to have to deal with a billion concepts.
I have found Heroku to be going downhill a lot, but after moving away from it I often feel a bit of regret from this decision. You get _so much_ operational niceness out of the box with Heroku.
It is encouraging to see that heroku is actually working on rolling new things out -- for a bit it hasn't clear if it was just in frozen "squeezing all the juice out with as little investment as possible" mode forever.
I'm having trouble interpreting that blog post to understand what it might actually mean for me or if I'd want to use it or what advantages it would have, looking forward to learning more.
> Today, OCI images are the new cloud executables. By moving to OCI artifacts, all Fir apps will be using images with compatibility across different environments. This means you can build your application once, run it locally, and deploy it anywhere, without worrying about vendor lock-in or compatibility issues.
Is this something I can try out locally without signing up for heroku first?
I am pleased to see support for OpenTelemetry on the way. As a heavy user of AWS Lambda, the observability provided by X-Ray is invaluable for troubleshooting and improving performance.
Marketing speak aside, I'm curious what is actually changing for the end developer in the "next generation". Heroku already supports building and deploying containers, and that will presumably continue.
One big part that I'm personally excited about is support for Cloud Native Buildpacks. It's an open spec, part of the CNCF, and produces container images. You can use it to debug locally and can try it out now https://github.com/heroku/buildpacks/blob/main/docs/ruby/REA....
To go along with that we've built and maintain a Rust framework for writing CNBs https://github.com/heroku/libcnb.rs. I maintain the Ruby CNB and so I'm pretty excited to see some of my stuff in action.
> Heroku already supports building and deploying containers
Kinda. Heroku created a container ecosystem before OCI images were a thing. Apps deployed to the current Cedar infrastructure are deployed as "slugs" basically a tgz of the application directory that's loaded onto an LXC container, and unzipped to run on a base image (also called a stack) https://devcenter.heroku.com/articles/slug-compiler.
One big benefit of moving towards a standards compliant future instead of homebrew, is that customers also have access to that ecosystem. That's what enables things like being able to run and debug application images locally. It's the standards and community. We went fast and blazed some trails, now we're aiming to "go far," together with the community.
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.
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?
I guess I was assuming it was computed, not manually entered, therefore it's the most trivial of bugs, and was just trying to have some fun with a bug report
Even if it was computed, the only reasonable interpretation of a date given without a timezone (either explicitly or implicitly from the location) is that it's in UTC.
15 years on Heroku, absolutely no regrets and would do it again and again and again. It's one of those "no one goes there because it's too busy" type of situations. Don't fall for the noise, just use Heroku and move on with your life.
Same thing happened to us. Moved to kubernetes 2 years and we had to rebuild all the features of Heroku in house against a kubernetes backend.
I’ve been working in my spare time to try to create an open source version of this, in case it would be useful to anyone else in the future https://github.com/czhu12/canine
I geniunely and strongly believe PaaS and BaaS do not have a sustainable business model for the long term. Most of the platforms are losing money for each user they onboard. No matter how "loved" a platform is they are not actually making money and some point they are going to "get you". All the new platforms are constantly raising money to compensate for the costs and nobody is actually engineering solutions to reduce cost but doing feature engineering that is actually increasing their cost per user.
If Heroku works for you, that is good. Ignore my comment.
PaaS is just a middleman service providing convenience over more bare bones infrastructure. Look at the entire world of profitable middleman companies and you’ll see there’s plenty of viability in the business model, but it’s not as easy as a golden goose.
I used these so called "build packs" a lot and owe Heroku a great deal in general.
However, when I was "forced to" use Docker containers instead of custom build packs (Heroku also supports them), I didn't look back: It's a non-vendor-locked, portable, industry standard, which works with every framework of my choice, not just Django and Spring Boot. It also doesn't need an extra effort to support.Net, or anything else for that matter.
Huh, this wasn't supported already? Wonder why they decided it was finally time to take the 30 minutes to create an official .NET buildpak now vs 10 years ago when it became cross-platform.
In a world of Google Cloud Run, which builds your app from a code base via build packs, streams logs, scales to zero and autoscales (regardless of container size/price), provides SLI/SLO monitoring and definition via point and click, integrates to pull requests on GitHub, directly connects to databases on GCP… the list goes on.
I would say, that in the world of cloud native, it boils down to whom gives less surprise bills, and actually provides humans to talk to when support issues arise.
I'm by no means an entrepreneur but I would literally never trust any of my services to Google. Not even email. This is the most evil, profit-centric company that has virtually no user support, nor a care in the world for you. They shittify every single product at some point too. Anything goes down, you're f*led without any means of getting help from a human. Someone someday in the past used the same ip as you and did something bad that got them banned? Say goodbye to your company's Play Store account. I've seen it happen for our client in the past. Zero communications. Google is the reason I moved away from Android App development.
You can, but not 100%. With class libraries, so it has to be a mix of C# and VB.
F# is on the same spot, hence why I nowadays say CLR has changed meaning to C# Language Runtime, the whole mantra of Common Language Runtime and Common Language Specification compliant libraries are now gone.
You may be able to get away with writing some of your business logic in VB.NET, but the actual endpoints, and likely many things around it, must be C#.
F# at least is officially supported for ASP.NET Core, and has official ASP.NET Core templates in Visual Studio.
I doubt that teams which employ F# are affected by default template selection in Visual Studio in any way, shape or form (if they use VS at all) :)
And companies which strictly choose only whatever comes out of box are unlikely to use F# anyway. The concept itself is incorrect and, I argue, must not be applied beyond ASP.NET Core and EF Core. There are no "first-party" frameworks in many other languages in either case so it is an unfair and flawed argument in the context of .NET.
Not unfair at all, and a clear shift of goalposts from how .NET was sold in 2001, and has been for almost 15 years, until management decided only C# gets invited for the new party.
Do you want a refresh from Visual Studio.NET and further releases until this stop being a thing?
I have so many great memories of my software just running in Heroku, unfortunately it was so easy to switch inbetween machines, that they could never lower their prices and thus it is just not competitive anymore. It costs way too much for a small website.
Not the poster you replied to, but try Google Cloud Run or Azure Container Apps.
Both scale to zero, are portable, and allow full use of your language/runtime/framework of choice. Take any app you are deploying to instance compute today and add a Dockerfile and ship it.
AWS App runner comes close, but doesn't have the option to scale to zero.
Heroku was revolutionary, but was bought out (salesforce) and stagnated while retaining their 4x cost. More than a few of the addons i've used on heroku have shut down, and you still have to upgrade your app to the new heroku stack regularly, so hosting an app is not maintenance free.
I wish they had maintained momentum and attempted to price competitively, but at this point its probably too late.
Heroku is still probably the platform that offers the most well built-out "here's all your operational needs for the first N years of your business" system, without causing you to have to deal with a billion concepts.
I have found Heroku to be going downhill a lot, but after moving away from it I often feel a bit of regret from this decision. You get _so much_ operational niceness out of the box with Heroku.
We’ve been working the next generation of Heroku - and actually also launching that this week! Check out our post on it here https://blog.heroku.com/planting-new-platform-roots-cloud-na...
It is encouraging to see that heroku is actually working on rolling new things out -- for a bit it hasn't clear if it was just in frozen "squeezing all the juice out with as little investment as possible" mode forever.
I'm having trouble interpreting that blog post to understand what it might actually mean for me or if I'd want to use it or what advantages it would have, looking forward to learning more.
Really glad to read there is a local story.
> Today, OCI images are the new cloud executables. By moving to OCI artifacts, all Fir apps will be using images with compatibility across different environments. This means you can build your application once, run it locally, and deploy it anywhere, without worrying about vendor lock-in or compatibility issues.
Is this something I can try out locally without signing up for heroku first?
Yep you can use our CNBs anywhere! More info and instructions here: https://github.com/heroku/buildpacks
I am pleased to see support for OpenTelemetry on the way. As a heavy user of AWS Lambda, the observability provided by X-Ray is invaluable for troubleshooting and improving performance.
Marketing speak aside, I'm curious what is actually changing for the end developer in the "next generation". Heroku already supports building and deploying containers, and that will presumably continue.
One big part that I'm personally excited about is support for Cloud Native Buildpacks. It's an open spec, part of the CNCF, and produces container images. You can use it to debug locally and can try it out now https://github.com/heroku/buildpacks/blob/main/docs/ruby/REA....
To go along with that we've built and maintain a Rust framework for writing CNBs https://github.com/heroku/libcnb.rs. I maintain the Ruby CNB and so I'm pretty excited to see some of my stuff in action.
> Heroku already supports building and deploying containers
Kinda. Heroku created a container ecosystem before OCI images were a thing. Apps deployed to the current Cedar infrastructure are deployed as "slugs" basically a tgz of the application directory that's loaded onto an LXC container, and unzipped to run on a base image (also called a stack) https://devcenter.heroku.com/articles/slug-compiler.
One big benefit of moving towards a standards compliant future instead of homebrew, is that customers also have access to that ecosystem. That's what enables things like being able to run and debug application images locally. It's the standards and community. We went fast and blazed some trails, now we're aiming to "go far," together with the community.
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.
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?
You all really are living in the future, says it was last updated tomorrow XD
/r/usdefaultism. It was already December 3rd in most of the world when you posted.
I had considered that, time is hard
I guess I was assuming it was computed, not manually entered, therefore it's the most trivial of bugs, and was just trying to have some fun with a bug report
Even if it was computed, the only reasonable interpretation of a date given without a timezone (either explicitly or implicitly from the location) is that it's in UTC.
15 years on Heroku, absolutely no regrets and would do it again and again and again. It's one of those "no one goes there because it's too busy" type of situations. Don't fall for the noise, just use Heroku and move on with your life.
Same thing happened to us. Moved to kubernetes 2 years and we had to rebuild all the features of Heroku in house against a kubernetes backend.
I’ve been working in my spare time to try to create an open source version of this, in case it would be useful to anyone else in the future https://github.com/czhu12/canine
I geniunely and strongly believe PaaS and BaaS do not have a sustainable business model for the long term. Most of the platforms are losing money for each user they onboard. No matter how "loved" a platform is they are not actually making money and some point they are going to "get you". All the new platforms are constantly raising money to compensate for the costs and nobody is actually engineering solutions to reduce cost but doing feature engineering that is actually increasing their cost per user.
If Heroku works for you, that is good. Ignore my comment.
PaaS is just a middleman service providing convenience over more bare bones infrastructure. Look at the entire world of profitable middleman companies and you’ll see there’s plenty of viability in the business model, but it’s not as easy as a golden goose.
> Most of the platforms are losing money for each user they onboard.
I really don't think they're losing money on onboarding, but I can totally see an argument for the fixed costs being so high that it doesn't work out.
I used these so called "build packs" a lot and owe Heroku a great deal in general.
However, when I was "forced to" use Docker containers instead of custom build packs (Heroku also supports them), I didn't look back: It's a non-vendor-locked, portable, industry standard, which works with every framework of my choice, not just Django and Spring Boot. It also doesn't need an extra effort to support.Net, or anything else for that matter.
Cloud Native Buildpacks now produce OCI images. Here’s a tutorial for using them locally https://github.com/heroku/buildpacks/blob/main/docs/ruby/REA...
Yes. I mentioned that Heroku also supports them.
I imagine what it could have been if it wasn't acquired by Salesforce and it makes me sad
Huh, this wasn't supported already? Wonder why they decided it was finally time to take the 30 minutes to create an official .NET buildpak now vs 10 years ago when it became cross-platform.
Who's using Heroku these days? The rug pull they managed back in the day akin to Travis ought to have lost them any goodwill.
Those that think aws is too cheap
CEO Bob Wise just left for Nvidia to run engineering and operations for DGX Cloud.
https://www.linkedin.com/feed/update/urn:li:activity:7267639...
In a world of Google Cloud Run, which builds your app from a code base via build packs, streams logs, scales to zero and autoscales (regardless of container size/price), provides SLI/SLO monitoring and definition via point and click, integrates to pull requests on GitHub, directly connects to databases on GCP… the list goes on.
Why would you bother with Heroku?
I would say, that in the world of cloud native, it boils down to whom gives less surprise bills, and actually provides humans to talk to when support issues arise.
GCP isn't well seen in that regard.
I'm by no means an entrepreneur but I would literally never trust any of my services to Google. Not even email. This is the most evil, profit-centric company that has virtually no user support, nor a care in the world for you. They shittify every single product at some point too. Anything goes down, you're f*led without any means of getting help from a human. Someone someday in the past used the same ip as you and did something bad that got them banned? Say goodbye to your company's Play Store account. I've seen it happen for our client in the past. Zero communications. Google is the reason I moved away from Android App development.
AFAIK .NET has no first-class support on Google Cloud Run.
Happy (for the most part) long term heroku customer, this is great to see.
> Developers can now build and deploy applications in C#, F#, and Visual Basic, using frameworks like ASP.NET Core and Blazor
Pretty sure you can't build an ASP.NET Core app in Visual Basic.NET (as it lacks support for some modern language features the framework needs).
You can, but not 100%. With class libraries, so it has to be a mix of C# and VB.
F# is on the same spot, hence why I nowadays say CLR has changed meaning to C# Language Runtime, the whole mantra of Common Language Runtime and Common Language Specification compliant libraries are now gone.
You may be able to get away with writing some of your business logic in VB.NET, but the actual endpoints, and likely many things around it, must be C#.
F# at least is officially supported for ASP.NET Core, and has official ASP.NET Core templates in Visual Studio.
Try to use the Blazor ones without community helper libraries, both languages aren't without issues.
That is why I point that the change of meaning in C from CLR.
Have you tried employing either in any recent time? Or is this just what you think is the state of affairs without contextual knowledge?
Good luck doing Blazor in straight F# or VB without C# glue code, does it answer?
There is, in fact, a package that does just that: https://github.com/slaveOftime/Fun.Blazor (and there are others IIRC)
> This is a project to make F# developer to write blazor easier
Now do the same in Visual Studio New Project, language F# or VB, without similar community projects.
I doubt that teams which employ F# are affected by default template selection in Visual Studio in any way, shape or form (if they use VS at all) :)
And companies which strictly choose only whatever comes out of box are unlikely to use F# anyway. The concept itself is incorrect and, I argue, must not be applied beyond ASP.NET Core and EF Core. There are no "first-party" frameworks in many other languages in either case so it is an unfair and flawed argument in the context of .NET.
Not unfair at all, and a clear shift of goalposts from how .NET was sold in 2001, and has been for almost 15 years, until management decided only C# gets invited for the new party.
Do you want a refresh from Visual Studio.NET and further releases until this stop being a thing?
I have so many great memories of my software just running in Heroku, unfortunately it was so easy to switch inbetween machines, that they could never lower their prices and thus it is just not competitive anymore. It costs way too much for a small website.
i remember deis. it's just like heroku but self-hosted. the experience is pretty amazing.
then k8s happened. deis workflows adopts k8s but it's never finished. deis team acquired by Microsoft not long after iirc.
Yawn- heroku used to be my go-to but hasn't been for years.
On the other hand, it's nice to see them support the dotnet (I'm assuming through a well supported engine like mono).
It’s actually using official .NET (which is now cross-platform and works very well on Heroku’s platform).
Also see https://devcenter.heroku.com/articles/dotnet-heroku-support-...
.NET has been cross-platform since 2014
Mono has been transferred to the WineHQ Organization [1] and is no longer recommended or supported by Microsoft.
.NET is the only (cross-platform) server runtime anyone should consider running Server Apps on.
[1] https://www.mono-project.com
Mono? What next, Heroku announces support for the newly released Python 2???
Thanks for your insightful comment.
What do you use now?
Not the poster you replied to, but try Google Cloud Run or Azure Container Apps.
Both scale to zero, are portable, and allow full use of your language/runtime/framework of choice. Take any app you are deploying to instance compute today and add a Dockerfile and ship it.
AWS App runner comes close, but doesn't have the option to scale to zero.
I think Render is pretty good. https://render.com/
Heroku was revolutionary, but was bought out (salesforce) and stagnated while retaining their 4x cost. More than a few of the addons i've used on heroku have shut down, and you still have to upgrade your app to the new heroku stack regularly, so hosting an app is not maintenance free.
I wish they had maintained momentum and attempted to price competitively, but at this point its probably too late.