In the early days of web application deployment, everything was very much a homegrown affair: developers and system administrators had to figure out a lot of how things were working together themselves, worry about the things they had missed and also considering the expenses and time consumption. As time rolled on, more and more tools and software became available, which made their lives significantly easier.

Nowadays applications can be developed and packed as a .war or .ear archive and run in a container, provided from Web- or Application Servers.  Common servers in this area are Tomcat, Jboss or WebSphere and many more. Most of them accomplish a lot more than only a run-time environment to service requests from the client side. Many other features like security, transaction management, scaling and load balancing are provided and can be configured. In such a scenario tasks often divided in between a development team, creating the application and an administration team, that hosts the server, takes control of the right configuration, installs patches and so on. In the last years evolution raised another trend which outsourced the administrative part more and more … here cloud application development comes into play!

One representative of these cloud application platforms is Heroku. In this article I take a closer and more technical look how Heroku serves the application provider’s needs.

Key promises of cloud application development

What are the promises of cloud application development? To name just two of them:

  • As a developer, you can just focus on the logic of your application instead of worrying about the server configuration and other prerequisites.
  • Cloud application development also means reduce the cost of building and maintaining your web apps. You pay as you go and get billed for only what you use.

These are just a few but important advantages that using cloud application development ease the pain throughout the process of application development. How Heroku tries to keep this promises and what you should be aware of, if you decide to develop or migrate an application, are some of the aspects we dedicated this and following articles.

Just one question: How does Heroku really work?

Heroku is a polyglot platform as a service (PaaS). It’s a cloud software platform that provides a combination of the underlying operating system resources, language run-time, and supporting software such as a library of add-ons to help you build your own web apps.

Heroku lets you deploy, run and manage applications written in Ruby, Node.js, Java, Python, Clojure, Scala, Go and PHP.

An application is a collection of source code, resource files and some build scripts used by a build systems such as maven to build the application.

Dependency mechanisms vary across languages: in Ruby you use a Gemfile, in Python a requirements.txt, in Node.js a package.json, in Java a pom.xml and so on.

For a clearer understanding, lets list all you need in order to deploy our code on Heroku:

  • The source code for your application
  • dependency file depending on the language you are using (as mentioned above)
  • file informing the platform as to which parts of your application are runnable (Procfile)

That’s all you need to provide enough information for the Heroku platform to build your application, to produce something that can be executed. Yes, that’s all!

What’s a Procfile?

To dive a little bit deeper into the Heroku context it’s necessary to know what exactly a Procfile is. Heroku uses a Procfile as a mechanism to declare what commands are run by your application’s dynos on the Heroku platform.

Here is an example of a Procfile:

web: java $JAVA_OPTS -Dspring.profiles.active=prod -jar target/dependency/webapp-runner.jar --port $PORT target/*.war

This Procfile is part of our „Splash“ Heroku button, check our GitHub repo for more.

Let’s just focus on the most interesting part of this example: An executable jar (webapp-runner) is used to start a tomcat server and deploy the Web Application that’s placed in the target directory and ends with*.war.

Important also that it has to be named exactly “Procfile” and placed in the root directory of your application:

On deploying applications on Heroku

Deploying applications involves sending the application to Heroku using either Git, GitHub, Dropbox, or via an API. The Heroku platform uses Git as the primary means for deploying applications.

On building applications …

When the Heroku platform receives the application source, it initiates a build of the source application. Under the hood, a git hub webhook is triggered after pushing new Source Code to the master branch.  For build and deployment Heroku uses so called buildpacks.  Heroku maintains a collection of default build packs for common languages and will automatically use the right one for your type of application. With help of the buildpack your app is compiled and packaged to a “slug”.

Now you might ask: What is this “slug” thing?

Before answering this question, we need to know some basics about what is going on inside of Heroku:

The Heroku cloud development platform provides you with the foundation for developing, deploying, and troubleshooting your cloud-based applications. It is comprised of the following components:

  • The platform stack: This provides core components such as the operating system (Linux Ubuntu 14.x), language runtime (i.e. Node.js, Ruby, Java, Php), and supporting libraries.
  • Request routing mechanism: This provides support to accept client requests and route them reliably to the running process.
  • The execution environment: This provides the necessary runtime support to run your apps.
  • The Logplex logging framework: This is an event logging system to collate application events that emanate from different processes for further processing.
  • The add-on ecosystem: This provides the ability to easily plug in third-party libraries to provide value added services, such as performance monitoring, caching, or data storage for your application.
  • The Heroku Platform APIs: This is a web service interface to programmatically perform Heroku operations from your code.

… and about Dynos and the „slug“ thing

Later on when you want to start with deploying your code on Heroku, you will see a concept called “dyno”. A dyno is a lightweight virtual UNIX container that can run any type of process the execution environment provides. This process execution environment – or so-called dyno manifold- facilitates the execution of various dynos. Most common are the so-called web dynos. They receive HTTP traffic coming in over the Heroku routers and might cater to different client requests.

Now that we know what a dyno is it’s time to go back and answer our question regarding the slug. The slug compiler is responsible for creating an executable application from raw code by building the application, linking required binaries, and compressing the executable for faster deployment. The final product of the slug compilation process is what is termed as the slug.

In short: Slugs are pre-packaged copies of the application optimized for quick distribution across the dyno manifold.

As we all know, building an application is not just all about coding and running the code, but also scaling and maintaining our service.

Heroku offers state of the art scaling. Scale horizontal by changing the amount of Dynos (i.e.  if you want handle more requests). Scale vertical by using more performant Dynos (i.e. if you need more CPU Power).

P.S.: I used example code of our SPLASH Heroku Button. Find out more about it on our GitHub page https://github.com/logiclinegmbh/splash. It’s an architectural pattern for a web app using Java, Spring, Hibernate and AngularJS on a single Dyno on Heroku.

 

More information you will find on Heroku’s website: https://www.heroku.com