Heroku is a cloud Platform as a service(PaaS) supporting several programming languages that is used as a web application deployment model. Heroku, one of the first cloud platforms, has been in development since June 2007, when it supported only the ruby programming language, but now it supports Java, Python, Node.js, Scala, PHP and GO. For this reason, Heroku is said to be a polyglot platform as it lets the developer build, run and scale applications in a similar manner across all the languages. The polyglot platform nature of Heroku is  better understood by the knowledge of Heroku architecture. Things that constitute Heroku architecture are as follows:

Dynos 

They are the heart of Heroku platform. Your web application code runs on the Heroku Enterprise platform inside of structures that we call dynos. Heroku dynos are just managed run time containers with a Linux operating system underneath. These containers run the processes that allow your custom application code to run. Containerization is a virtualization technology that allows multiple isolated operating system containers to be run on a shared host(heroku) ,and process in one container cannot see anything about another process in another container.
One of the great things about Heroku dynos is how easy they are to scale up and down. Through Heroku org or via the command line, you can easily add more(number) dynos or larger(size) dynos. Adding additional dynos can help speed up your application’s response time by handling more concurrent requests,whereas adding larger dynos can provide additional RAM for your application.
Dynos are of  three different types differentiated based on their tasks.

Web Dynos: Web dynos are dynos of the “web” process type. Only web dynos receive HTTP request from the routers. When you initially deploy to Heroku, your app runs on a single web dyno. The web dyno is what serves your application to the world.
Consider a customer requests your webapp through the web browser. The request is sent to router and router directs it to respective web dyno. The web dyno ,then processes the request and gives back the result. If there are multiple requests from a wide range of customers, all the requests will be directed to a web dyno. If the web dyno is able to handle traffic(all incomimg requests) then there is no need to increase web dyno number or else web dyno number should be increased. The more concurrent connections your app needs to support, the more dynos you will need to keep your app accessible to users. If your traffic is supported well by a single dyno, having more will not provide any advantage.

For example a customer of a web app accessed the app through browser and needs to upload the image into the app and if dyno should immediately respond to the user’s request with some indicator of work progress. Requests of this type will be sent to web dyno. After uploading the image ,storing it in required directory or further processing of image will not be done by worker dyno. Web dynos are for efficient user interaction with web app

Worker Dynos: Background jobs are key to building scalable web apps as they transfer both time and computationally intensive tasks from the web layer to a background process. This ensures that web requests can always return immediately and reduce performance issues that occur when requests become backlogged.

In Heroku this is achieved by worker dynos. Worker dynos are typically used for background jobs,queuing systems, and timed jobs(jobs that take much time). Worker dynos run asynchronously to web dynos. Moving more processing to the worker will free up your web dyno to handle more requests. Handling long-running work with background workers has many benefits. It avoids tying up your web dynos, preventing them from serving other requests, and keeps your site snappy. In the above example if the uploaded image needs further processing web dynos pass it to worker dynos.
More examples of background jobs include fetching data from remote APIs, reading RSS (Rich Site Summary) feeds, resizing images, and uploading data to S3 (simple storage service) .You can have multiple kinds of worker dynos in your application. For example, one for urgent jobs and another for long-running jobs.

One-off Dynos: Web and Worker dynos do the app’s regular business such as handling web requests and processing background jobs as it runs. When you wish to do one-off the administrative or maintenance tasks for the app, or execute some task periodically using Heroku Scheduler, you can spin up a one-off dyno.

One-off dynos are temporary dynos that can run detached, or with their input/output attached to your local terminal. They are loaded with your latest release. They can be used to handle administrative tasks, such as database migrations and console sessions. They can also be used to run occasional background work.

One-off dynos run alongside other dynos, exactly like the app’s web, worker, and other formation dynos. They get all the benefits of dyno isolation. One-off dynos never automatically restart, whether the process ends on its own or whether you manually disconnect. Connections to one-off dynos will be closed after one hour of inactivity (in both input and output).

 Slug

A slug is a bundle of your source, fetched dependencies, the language runtime, and compiled/generated output of the build system – ready for execution.

 

How a slug is formed?
When you push code to Heroku from your local machine using git push,your code is received by the slug compiler on cloud. Slug compiler then downloads, builds, and installs local dependencies as specified in your build file. After that, depending on the language of code, a specific buildpack is activated and code is compiled. The compiled code is compressed to create the package known as slug archive or slug.

 Buildpacks

At the heart of the slug compiler is a collection of scripts called a buildpack that handles different languages. Heroku’s officially supported buildpacks accept applications written in Ruby, Python, Java, Clojure, Node.js, Scala, Go and PHP.

These buildpacks are open-source and available on GitHub. Also Heroku supports custom buildpacks. For example you have a code written in language other than Heroku supported languages, then for compilation of that code, Heroku allows you to design your own build pack.

Heroku Router

Whenever a new web dyno starts up, it registers itself with the router, letting it know which application the dyno is running. After a dyno is registered, the Heroku router begins distributing incoming requests across all the available dynos for an application.

HTTP requests are received by a load balancer that offers SSL(secure sockets layer) termination. From here they are passed directly to a set of routers. The routers are responsible for determining the location of your application’s web dynos and forwarding the HTTP request to one of these dynos.

Routers use a random selection algorithm for balancing HTTP requests across web dynos. If there are larger number of dynos in a particular region then algorithm automatically passes the request to that region. Also router maintains a counter which counts the number of requests made to a particular app. The counter has a limit and if the limit exceeds subsequent requests to that router will immediately return an H11(backlog too deep) response.

When Heroku receives an HTTP request, a router establishes a new connection to a selected web dyno. If the connection is refused or has not been successfully established after 5 seconds, the dyno will be quarantined and no other connections will be forwarded from that router to the dyno for up to 5 seconds. The quarantine only applies to a single router. Because each router keeps its own list of quarantined dynos, other routers may continue to forward connections to the dyno.

 Heroku Add-ons

Add-ons are another essential piece of the Heroku platform. Dynos do not provide storage, and so add-ons that provide some kind of storage are typically used as a means of communication between dynos in an application. Add-ons give you the ability to add complex functionality to your application without having to manage the underlying software or infrastructure.

Heroku customers use the marketplace or the Heroku CLI to provision your add-on.This is something similar to android mobile playstore, where we can get both free and paid apps. When an add-on is requested Heroku sends a request to your service, which creates a new private resource for the app.You can find your application add -ons in the resources tab in your org.

A great example of a useful add-on is the Heroku Postgres database. Postgres is an enterprise-class database that is fast, reliable, and has a ton of capabilities. Heroku Postgres provides features like continuous protection, rollback,storage and high availability. Best of all, when you provision a Postgres database as an add-on, the underlying infrastructure is completely managed by Heroku. Another example of Heroku Add-on is Heroku connect which is used to connect application data running on Heroku with salesforce org.

In addition to several Heroku-managed add-ons, third parties offer dozens of add-ons like data stores, email servers, monitoring tools, and anything else you can imagine.
To provision a add-on to a particular app, open the app and click on the resources tab and enter the search word for add-on or click on find more add-ons.

Lets consider you designed a code for a web application using java and you are ready to run and compile it. Using Heroku toolbelt you push the code to Heroku platform. It will be received by slug compiler of Heroku. Slug compiler then downloads, builds, and installs local dependencies as specified in your build file. After that, java buildpack is activated and that Java code is compiled. The compiled code is compressed to create the package known as slug archive or slug. This slug which is ready to run will be sent to dyno and simultaneously dyno id will be registered in router,so that the router knows which application the dyno is running. The final application will be run on dyno. Your web application will be given a unique URL, through which your users will access the application. Whenever the user access your application through website,he is actually speaking to dyno to display the application on website. To store the data of your web application because dynos does not support storage,they are like RAM, you need to provision a storage Add-on to your application.You can get that on Heroku market place. The very known add-on for database is Heroku Postgres.

Now a user wants to access the application designed by you. Through web browser he requests the application and HTTP request will be initially sent to Router via a load balancer which offers encrypted communication. Depending on the the requested URL the router directs to respective dyno (web dyno). If the user likes the content in website and he want to register himself in the application for further updates in the application then whatever data user enters will be received by web dyno and storing the data in a database will be done by worker dyno.