I went to scale an app, but when I follow heroku docs for doing so:
heroku ps:scale web=2
Scaling dynos... !
▸ Cannot update to more than 1 Basic size dynos per process type.
I see the message, but I want more web dynos (not a worker dyno).
Based on the docs, this should be straight forward. Why won't it scale?
From Heroku docs:
Heroku apps can be scaled to run on multiple dynos simultaneously (except on Eco or Basic dynos).
So you need to change from 'Basic' ($7/dyno/month) to at least 'Standard' ($25-$500/dyno/month) in order to be able to scale the application.
This is also indicated in the description of 'Basic' in the 'Dyno Types' image:
Basic - Perfect for small-scale personal projects and apps that don't need scaling.
Related
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'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.
Is there a way to break a composite Heroku app with multiple process types and deploy as separate apps. Can I clone the app, and comment out the ProcFile for one or either process types and deploy it separately on two different containers?
You could most definitely do that, although -- that's probably only a good idea if you plan on maintaining each of those codebases separately.
Instead, why not just scale up a specific number of each process type? For instance, let's say you have defined two process types: web and worker.
You could say:
$ heroku ps:scale web=2 worker=2
This would run 2 web dynos, and 2 worker dynos. Each of them will run in separate containers and have their own resources.
As far as I know heroku gives you one dyno for free for your app. I uploaded an app but I have no dynos to assign to it.
What should I do?
You need to provide a Procfile so Heroku will know what kind of Dynos you need and how to start your app. Then you'll be able to scale your Dynos.
we want to migrate my application to Heroku acctually we have 3 applications related and we want to move to Heroku. But we don't know how many dynos we need for deploy those applications. wether 3 applications in the same dynos and make a copy in other dynos or for each application one dynos? thanks for your help.
If they are 3 separate applications you will need a minimum of 3 dynos since each Heroku application will need to run a dyno.
As to how many dynos each of your application needs to run that all depends on how busy each site is and how long requests take to process.
I can only speak for Java and an embedded server/container. In this case you actually could deploy more than one app into your container (which will be startet from your dyno), only using one dyno.