Difference between app and Dyno on Heroku? - heroku

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.

Related

Is there any Heroku request queue for storing requests while dyno is down?

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.

Is it possible to run two applications on one hobby dyno?

I have $161 platform credits on heroku from GitHub student pack to spend for one hobby dyno:
The Heroku offer is for one (1) free Hobby Dyno for two years, which will be applied on your invoice as a discount of $7 for a Hobby Dyno.
I already deployed one spring app and changed its dyno to hobby. My question is if there is a way I could deploy second Java app and set it to use the same dyno which is assigned for the first app?
Right now I have one app which has hobby dyno and one app which uses free dyno. I read on the internet and people say that there is only one app allowed for one dyno and Heroku will charge me for the second one but there is also this thread How many apps are allowed on a 'Hobby' Heroku plan? which says that I can have more than one app per hobby dyno.
So what's the truth?
No, you can't run multiple apps on a single dyno.
Heroku's model is to run one app per dyno (and often many dynos for a single app). The question you reference discussed the Hobby plan¹, asking how many dynos can be run per account. Keep in mind that Heroku's model is different from the shared or VPS hosting you might be used to. Dynos don't provide an OS that you can put apps onto; they run apps directly.
¹Technically I don't think this makes a ton of sense since accounts don't have these kinds of tiers. One account can run free dynos, hobby dynos, and professional dynos. But there is a difference between unverified accounts, which can run up to five free dynos, and verified accounts which can run many more.
According to this article on the heroku page it is possible but not recommended.
Heroku post

Heroku pricing dramatically increases when using microservices architecture

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.

Multiple apps, paid Dynos

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.

What exactly is Heroku?

I just started learning Ruby on rails and I was wondering what Heroku really is? I know that its a cloud that helps us to avoid using servers? When do we actually use it?
Heroku is a cloud platform as a service. That means you do not have to worry about infrastructure; you just focus on your application.
In addition to what Jonny said, there are a few features of Heroku:
Instant Deployment with Git push - build of your application is performed by Heroku using your build scripts
Plenty of Add-on resources (applications, databases etc.)
Processes scaling - independent scaling for each component of your app without affecting functionality and performance
Isolation - each process (aka dyno) is completely isolated from each other
Full Logging and Visibility - easy access to all logging output from every component of your app and each process (dyno)
Heroku provides very well written tutorial which allows you to start in minutes. Also they provide first 750 computation hours free of charge which means you can have one processes (aka Dyno) at no cost. Also performance is very good e.g. simple web application written in node.js can handle around 60 - 70 requests per second.
Heroku competitors are:
OpenShift by Red Hat
Windows Azure
Amazon Web Services
Google App Engine
VMware
HP Cloud Services
Force.com
It's a cloud-based, scalable server solution that allows you to easily manage the deployment of your Rails (or other) applications provided you subscribe to a number of conventions (e.g. Postgres as the database, no writing to the filesystem).
Thus you can easily scale as your application grows by bettering your database and increasing the number of dynos (Rails instances) and workers.
It doesn't help you avoid using servers, you will need some understanding of server management to effectively debug problems with your platform/app combination. However, while it is comparatively expensive (i.e. per instance when compared to renting a slice on Slicehost or something), there is a free account and it's a rough trade off between whether it's more cost effective to pay someone to build your own solution or take the extra expense.
Heroku Basically provides with webspace to upload your app
If you are uploading a Rails app then you can follow this tutorial
https://github.com/mrkushjain/herokuapp
As I see it, it is a scalable administrated web hosting service, ready to grow in any sense so you don't have to worry about it.
It's not useful for a normal PHP web application, because there are plenty of web hosting services with ftp over there for a simple web without scalability needs, but if you need something bigger Heroku or something similar is what you need.
It is exposed as a service via a command line tool so you can write scripts to automate your deployments. Anyway it is pretty similar to other web hosting services with Git enabled, but Heroku makes it simpler.
That's its thing, to make the administration stuff simpler to you, so it saves you time. But I'm not sure, as I'm just starting with it!
A nice introduction of how it works in the official documentation is:
https://devcenter.heroku.com/articles/how-heroku-works
Per DZone: https://dzone.com/articles/heroku-or-amazon-web-services-which-is-best-for-your-startup
Heroku is a Platform as a Service (PaaS) product based on AWS, and is vastly different from Elastic Compute Cloud. It’s very important to differentiate ‘Infrastructure as a Service’ and ‘Platform as a Service’ solutions as we consider deploying and supporting our application using these two solutions.
Heroku is way simpler to use than AWS Elastic Compute Cloud. Perhaps it’s even too simple. But there’s a good reason for this simplicity. The Heroku platform equips us with a ready runtime environment and application servers. Plus, we benefit from seamless integration with various development instruments, a pre-installed operating system, and redundant servers.
Therefore, with Heroku, we don’t need to think about infrastructure management, unlike with AWS EC2. We only need to choose a subscription plan and change our plan when necessary.
That article does a good job explaining the differences between Heroku and AWS but it looks like you can choose other iaas (infrastructure) providers other than AWS. So ultimately Heroku seems to just simplify the process of using a cloud provider but at a cost.

Resources