To deploy your code you can make use of popular developer tools like git, GitHub, and Docker using a single command.

If you aren’t aware of how a Heroku works, then this blog is definitely for you!

Here we have listed out how the Heroku actually works!

Heroku- The Cloud Application

An application is a collection of source code which is written any of the above-stated languages.

In each language, the dependency platform varies, such as Ruby you use a Gemfile, in Python a requirements.txt, in Node.js a package.json, in Java a pom.xml and so on.

The source code of your application along with the dependency file will help you to build the Heroku platform.

Knowing what should be executed

When you want to run the applications on Heroku, you don’t need to make any changes to them.

If you are using some established framework, Heroku can figure it out. For example, in Ruby on Rails, it’s typically the rails server, in Django, it’s python <app>/manage.py runserver and in Node.js it’s the main field in package.json.

But for other applications, you need to declare what needs to be executed. You do this in a text file that accompanies your source code – a Procfile. Each line declares a process type that is: a named command that can be executed against your built application.

Deploying the Applications:

You can make use of Git which is a powerful, distributed version control system that many developers use to manage and version source code. Even the Heroku uses Git platform to deploy the applications.

Whenever you create an application in Heroku, it gets associated with a new Git Remote which is named as Heroku, with the local Git repository for your application.

One of the ways to deploy your application is by:

$ git push heroku master

There are many other ways which can also be used to deploy your applications.

Building Applications

Whenever the Heroku platform receives the application source, it initiates a build of the source application. The application which is built is language specific but it follows the same pattern, by retrieving the specific dependencies and creating assets.

Slug is nothing but the composition of your application, together with the fetched dependencies and output of the build phase such as generated assets or compiled code, as well as the language and framework.

Running Applications on Dynos

Heroku executes applications which are running the command which you have specified in Procfile.

Basically, if you deploy an application for the first time, Heroku will run 1 web dyno automatically.

HTTP Routing

Depending on the type of your dyno formation, some of your dynos will be running the command associated with the web process type, and some will be running other commands associated with other process types.

The dynos which run process types named web are different in one way from all other dynos – they will receive HTTP traffic. Heroku’s HTTP routers distributes the incoming requests for your application across your running web dynos.

So to scale an app’s capacity to handle web traffic involves scaling the number of web dynos:

heroku ps: scale web+5

A random selection algorithm is basically used for HTTP request load balancing across web dynos – and this routing handles both HTTP and HTTPS traffic. Added, it also supports multiple simultaneous connections, as well as timeout handling.

Conclusion

The above concepts can be summed together into two buckets: Those which involve the deployment and deployment of the application and on the other end which involves the run time operation of the Heroku platform and the application after it is deployed.

If you have any interesting information to make this more clear, you can jot down your comments in the comments section below.

Thanks for reading!!