How Heroku Works

I started looking into Heroku as an option for creating personal applications in my free time. In fact, I converted an existing application from the AWS ecosystem to Heroku which was captured in a series on DZone.com:

Moving Away From AWS and Onto Heroku

Starting with a brand new idea with Heroku, I was able to quickly create a fitness-based SaaS solution as well, which was documented in another series on DZone.com:

Using Heroku to Quickly Build a Multi-Tenant SaaS Product

Well over a year into using Heroku for several of my applications, I thought I would take a step back and describe how Heroku works and offer thoughts on why the Salesforce-owned solution should be a consideration for your next project.

What is Heroku?

Founded in 2007, Heroku is a platform as a service (PaaS) ecosystem which currently supports the Ruby, Java, Node.js, Scala, Clojure, Python, PHP, and Go programming languages (plus community support for many other languages). Because of its ability to support multiple languages to accomplish the same result, Heroku is considered a polyglot platform.

At the highest level, Heroku intends to serve the needs of applications looking for a place to live. Developers get started by creating a Heroku "app" and introduce their original code via a standardized git repository. Heroku simply takes things from there—building and deploying the application, then serving it up for consumption as needed. This includes static resources (like an Angular or React.js application), which can be served from a Node.js implementation.

Heroku provides over 175 add-on services to complement each app, featuring:

• database services
• uptime alerts
• messaging services
• automatic backups
• search
• metrics
• mail delivery

Below is an illustration of one my personal applications leveraging database, security, and messaging all within Heroku:

Heroku strives to do everything possible in order to allow users to focus on building features and functionality in their applications. In taking this approach, you can avoid the time typically required to learn, implement, manage, and support the DevOps-driven path toward application deployment.

Heroku has been a Salesforce company since 2010 as part of a $212 million acquisition. In fact, Salesforce CEO Marc Benioff stated:

“With Heroku, our platform can become the cornerstone of the next-generation of cloud computing.”
Marc Benioff - Salesforce chairman and CEO

Features of Heroku

Heroku is far more than a place to deploy and house applications – it provides all the necessary aspects to complement application hosting and management. For this article, I will focus on four interesting aspects of Heroku.

1. Buildpacks and Slugs

Buildpacks are the mechanism inside the Heroku ecosystem which compile application code and create a "slug." The slug is a pre-packaged copy of the application (including any necessary runtime layer) that is optimized for distribution into a dyno. To gain a better understanding of this concept, consider the illustration below:

As part of creating a new application in Heroku, a git remote is created from the repository containing the source code to deploy. With this in place, a standardized git push command is issued, along with specifying the target host and branch. In the example above, git push heroku master is issued to push the current branch to the "master" branch in the "heroku" remote.

This triggers Heroku to start processing the request. The first step is to scan the project to understand if a buildpack has been specified in the Heroku configuration. If using one of the supported languages noted above, this step is not necessary as Heroku will automatically select the correct buildpack. If you are not using one of the officially supported languages, you can create a custom buildpack, or you can select from over 6,000 third-party buildpacks in the Elements Marketplace.

The buildpack then tells Heroku how to retrieve all the needed dependencies and runtime required to run the application. The result of this action is creating an application slug. Heroku then deploys that slug to one (or many) dynos and runs the buildpack or user-specified command to starts the application.

2. Dynos, Config Vars, and Releases

In the prior section, a buildpack and slug were utilized to launch a new application in Heroku. The application itself runs in a Heroku dyno, which is the heart of the Heroku platform. Dynos are Linux-based containers that are isolated and designed to execute code based upon a user-specified command. (Heroku came up with the term dyno because, at the time, Docker hadn't yet come up with or popularized the term container.) Because of this design, Heroku allows dynos to be scaled up (or down) to meet capacity needs.

In order to avoid including sensitive and configuration information in the source code of the application, Heroku provides a mechanism to house configuration variables. For command-line users, the heroku config command provides the following information:

╭─me@mbp ~/new-dyno ‹master›
╰─$ heroku config
=== new-dyno Config Vars
DATABASE_URL:      mysql://someUser:somePassword@someHost.net/someService?reconnect=true
CLIENT_ID:         myAuthClientId
CLIENT_SECRET:     myAuthSecreteId

There is a complementary web-based version in the Settings tab of the Heroku Dashboard:

Whenever code is deployed, a configuration variable is changed, or an add-on resource is modified, Heroku creates a new release and restarts the dyno application. This is a feature of Heroku that often goes overlooked, as Heroku always provides the ability to roll back to a prior state with ease.

The release history is available in the Heroku Dashboard and also available via the heroku releases command line:

╭─me@mbp ~/new-dyno ‹master›
╰─$ heroku releases
=== new-dyno Releases - Current: v3
v3  Deploy 2b93a215                            me@example.com  2021/03/23 07:49:35 -0400
v2  Set CLIENT_ID, CLIENT_SECRET config vars   me@example.com  2021/03/19 07:26:34 -0400
v1  Deploy 40e37807                            me@example.com  2021/03/19 06:48:00 -0400

3. Heroku Add-Ons

The adaptability of a product or a platform is largely tied to libraries or services which are available with the mere click of a mouse button or issuing a simple command-line statement. Currently, Heroku includes over 175 add-on products which cover over 24 different categories of add-ons. Below, is a current screenshot of the Heroku Marketplace where add-ons can be viewed and instantly added to an existing app.

The majority of Heroku add-ons provide a free level for use or a trial period. Both options allow the developer to gain a better understanding of the product before making a long-term investment.

Personally, I have taken advantage of the free trial tiers to compare solutions which compete in the same space. In fact, add-ons can be removed just as quickly as they were installed.

4. Logging and Routing

Heroku simplifies logging by automatically collating and routing logs from every part of your application into a single channel. This provides a truly comprehensive and extensible app-centric logging. 

Heroku uses Logplex for distributed log routing and collation. Using the command-line interface, the following command can be issued to view the current logs:

╭─me@mbp ~/new-dyno ‹master›
╰─$ heroku logs --tail 

2021-03-28T20:45:30 app[web.1]: 2021-03-28 20:45:30.020  INFO 4 --- [scheduling-1] c.g.j.f.services.SmsService : sendSmsSummaryMessages() completed
2021-03-28T20:50:00 app[web.1]: 2021-03-28 20:50:00.019  INFO 4 --- [scheduling-1] c.g.j.f.services.SmsService : start date=03/28/2021, time=08:50 PM
2021-03-28T20:50:00 app[web.1]: 2021-03-28 20:50:00.019  INFO 4 --- [scheduling-1] c.g.j.f.services.SmsService : end date=03/30/2021, time=02:50 AM

Leveraging the power of add-ons can introduce tools like Coralogix Logging, Logentries, LogDNA, Papertrail, and Sumo Logic to the app in order to provide fully-functional logic analysis and debugging.

Who Should (and Should Not) Use Heroku?

With several options competing for customer acquisition, the following table illustrates cases where Heroku is (and is not) an option:

From my personal analysis of the IT industry over a 30-year time period, I feel comfortable asserting the fact that Heroku provides the necessary solution set to serve the needs of over 80% of the applications currently running today. The only limiting factor is to perform the necessary analysis and planning to take advantage of the services offered by Heroku.

Once Heroku becomes the destination, every application will begin to benefit from the time which can be applied to future features and functionality.

Conclusion

If I were to draft a concise mission statement for any IT professional it would be quite simple:

"Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else."

Basically, if you are in the business of building an application that helps do something with widgets, commit your time and efforts toward maximizing ways to give widgets a competitive advantage. Avoid spending time doing things that a framework, product, or service offering already provides—knowing they will likely always provide a better solution than you can—because that is why they exist.

Prior to using Heroku for my applications, I found myself spending unnecessary time trying to figure out aspects that Heroku already does (and does very well) for me. This effort came with a serious consequence of not being able to allocate my limited time in the right manner. Now, a year later, I am amazed at the results which have been achieved by sticking to the simple mission statement above. 

From the latest information I could find, my applications are part of over 9 million applications currently running on Heroku—clearly playing a part of the next-generation of cloud computing.

Have a really great day!