Heroku doesn't offer auto-scaling for anything under the "performance tier" dynos ($250/mo).
Hirefire used to be a gem that you could configure to autoscale dynos, but they realized that their solution could make money so now it's a paid service.
What options are there (including rolling my own) for smaller apps to have intelligent scaling of dynos at no extra cost?
The cheapest solution in term of money, but at the cost of time would be to use Heroku's Platform API. The formation endpoint will let you scale up and down the number of dynos.
Then, you "just" need to gather information on how many dynos you need. For example, with the log-runtime-metrics feature and a log drain, you could listen for the cpu and memory usage on your dynos and scale up/down based on that.
Related
All the dyno sizes listed in the dropdown cost money. Is there some way to guarantee that only my free dyno hours will be used? Thanks!
The Heroku Scheduler Add-On is free when you add it to a Dyno which is using the Free plan.
If you use Hobby the type of the One-Off Dyno will be hobby (which is not free).
The same applies to Standard or Performance, see Heroku One-Off Dyno Type
Apps using standard or performance dyno types will use a standard-1x dyno type in the one-off dyno.
I am using Heroku for one of my hobby projects. I bumped into the following problem if webhook sends a request to Heroku and Java app restarts at this time, the request will be lost. Is there any native Heroku way or plugin that ensures that Heroku will get a request, at least once?
I didn't find anything so far, and the default solution is to take AWS Lambda or Google Cloud Function to ensure scalability and availability. I feel that it adds unnecessary complexity and possibly a maintenance headache.
To Summarize:
Is there any Heroku native mechanism or Heroku plugin that ensures that requests will be delivered?
Assuming your Java application restarts are related to dyno restarts or deploys:
you might want to look into the preboot feature on Heroku.
From their documentation:
Preboot changes the standard dyno start behavior for web dynos. Instead of stopping the existing set of web dynos before starting the new ones, preboot ensures that the new web dynos are started (and receive traffic) before the existing ones are terminated. This can contribute to zero downtime deployments.
#Denis Cornehl's answer helped a lot. My answer is an extension to it.
You don't have a free solution if you have free or hobby tires. You will have to follow Enterprise Integration Patterns.
My solution was to put the queue in front of the application and consume messages when the application is up. Even though there is no free queue, some cloud providers give you free quotes for big loads. I recommend considering them before deploying and maintaining your own queues.
I don't understand what the difference between an app and Dyno is.
I want to use the hobby plan so that I can use an own SSL domain and that the servers stops sleeping.
I have a backend (nodeJS) and a frontend (reactJS).
Heroku says $7/Dyno. Does that mean I have to pay $7 for one app? Or do I pay $7 and can use several apps with it, so that they don't sleep?
An App is a set of one or more different dynos. This latter can be either of the same or different type (e.g. web, workers, ...) and having a different tier (e.g. standard, hobby, performance ...). You can see here the details for your better understanding.
It is possible to execute more instances of the same dyno type (e.g. for high-availability, processing concurrency ...). You can see here and here for details.
You basically pay for the number of dynos you run.
I'm just starting with Heroku, and I'm considering using it to host my app.
The problem is, I'm planning to build my app with a micro services architecture.
As I understand Heroku's pricing, they charge per dyno. When using micro services, there are a bunch of "apps" or "services" working together to provide the functionality of one app.
It seems inevitable to do this without using multiple dynos, and by adding dynos, the price goes up very quickly.
I have three questions:
Is my interpretation of Heroku's pricing correct?
Is there a better way to do a micro services architecture using Heroku?
Or, is there a way to deploy multiple docker containers on a single dyno?
Your Heroku costs will definitely go up as you use more dynos and more apps, but if you are just starting out, the money you spend will be in no way more than the time you would spend setting up something like AWS to perform the same functionality.
You can always save money later, once your app is running and users are loving it. If you goal is to prototype and get it out fast, Heroku is still the best choice.
Did you know about Heroku price calculator?
Saw you run 10*1x dynos, plus some other services, like text messages and such. That will cost you $250-350 this month. That's a lot, sure. But you can get your app running tomorrow, and presumably that is worth a lot more than 250.
Looking for best practice/implementation thoughts:
I often create small to medium web apps for client projects, usually webservices for mobile apps, sometimes websites.
Since the free Heroku model scales down/shuts down dynos if no activity is detected, the start up time of websites and web service calls are sometimes delayed.
I would like to pay monthly for 1-2 dynos so that the apps are available immediately, but I would like all my apps to use the same dynos. Does anyone one if this is possible and where should I start.
I'm looking for solutions other than pinging the apps to try to keep the dynos alive, i'm not even sure if this really works in the long term.
Thanks.