If youâre old enough and lucky enough to have had access to a computer in the early 1990s, you may have experienced the joy and wonder that was an MS-DOS game. These games were marvels of their time, but a number of them required you to do something odd, which was reboot your computer and boot into the game itself, thus taking the operating system (OS) out of the equation while the game was running.
The reason was that the OS put constraints on the game program; it used up resources needed by the game and forced certain rules into place that werenât necessarily helpful for the game to run efficiently.
As time moved on, this approach was no longer needed. Operating systems were becoming more advanced and games were able to run quite happily within their boundaries. The games were able to benefit from the additional help that the OS gave for interfacing with hardware and so on.
These days, we would never imagine running our games outside of the platform provided by the OS; itâs just too much work and involvement for the developer. Why would a developer rewrite a whole hardware interface or library of sound drivers when it can rely on those provided by the OS?
Now think about this in the context of the Web. In the early days of deployment, everything was very much a homegrown affair: developers and system administrators had to figure out a lot of how things bolted together themselves, and worry about the things they had missed. As time rolled on, more and more tools and software became available, which made their lives significantly easier.
These days, though, we have platforms such as Heroku, which you could almost consider to be one of the Webâs operating systems. As a developer, you can write your application in the way a game designer wouldâyou donât need to worry about the details of how your database server is set up and you donât need to worry about how your servers are kept up to date. Heroku is a platform that takes care of all of these things and allows you to integrate with it how you will.
Now, we are in a position where the idea of a developer building a server to host an application is becoming almost a bizarre route to take. Each day, hundreds of developers deploy applications, and fewer and fewer are getting involved in the nitty-gritty of infrastructure, instead choosing to use platforms such as Heroku.
This book is aimed at anyone who is already using Heroku in one form or another, and wants to learn more about the best ways to make use of the technology available. This book makes the assumption that you are already proficient in using your own language of choice and are happy using Git for your source control needs.
The book assumes no previous knowledge of Heroku itself, but you will get more from it if you have deployed an application or two to the platform already.
Lastly, you should not be afraid of documentation. There is a vast array of content available, both on the subject of Heroku itself and the various languages that can be deployed to it. Therefore, instead of repeating that content, we encourage you, the reader, to go out and review whatever you can find on a given topic.
Heroku is still a relatively young company, having only started in 2007 (making Heroku younger than the Apple iPhone!). Back then, the three foundersâJames Lindenbaum, Adam Wiggins, and Orion Henryâwere all working together at a small web development agency, and found that the amount of time spent deploying an application once having built it was not proportional. For instance, they were commonly finding that an application might take a month to develop, but then they would need to spend a week deploying the application to the Web.
After a while, they started developing applications using Ruby on Rails. With this came a newfound productivity, yet the time for deployment hadnât changed. Therefore, the three of them had the idea of bringing the same sort of efficiencies to application hosting.
In six weeks, an idea was developed and a prototype was built: a simple platform that was easy to deploy to and straightforward for a developer to figure out.
Interestingly, the initial prototype was nothing like the Heroku you see today. For instance, one major component was an application called Heroku Garden (although it wasnât known by this name at the time), a web-based code editor that users could log into and use to edit their code via a browser (see Figure 1). Once you hit Save, the code was deployed and running on the Web, ready for users to see. Interestingly, there are more web-based code editors popping up in 2013, which shows how far ahead of the curve it was.
Over time, however, Heroku found that more and more of its target users were interested in the application hosting aspect of the product instead of the web-based editor. Therefore, Heroku developed an API that developers could use alongside Git, the source control system. Developers could also use the API to push their code to the Heroku platform.
Use of this API grew, and Heroku took the decision to turn off Heroku Garden completely. In January 2009, Heroku relaunched and rebranded itself as a Ruby/Rack deployment platform, and interest in and adoption of the product grew significantly.
Heroku is constantly developing the stack that is available for use, starting with the Aspen and Bamboo stacks, and moving to the current Cedar stack, which this book talks about.
Cedar is a big move forward in that it allows Heroku to become a fully polyglot platform (i.e., it can run many different types of applications within the same stack). Ruby is no longer the only option for use on Heroku, with the platform now supporting Python, Java, Node.js, Clojure, and Scala, and providing the potential for a vast amount more via the use of Heroku buildpacks, which we will talk about more later in the book.
Itâs probably worth mentioning the Heroku culture and how this affects its approach to software and how things are put together.
Picture the movie industry just 70 years ago. If you wanted to watch a film, it had to be what was playing at the local cinema. Hundreds of people would congregate and watch that film together, and it would be fun.
By the 1980s, the magical idea of the videocassette was taking off. Now people could choose what film to watch and when, assuming that they had access to the media. The technology was much smaller, and the media much more readily available.
Come the 1990s, the DVD made its entrance. Again, smaller devices, smaller media, but with another iteration in quality and capability. Over the matter of a couple of iterations, we had gone from a massive cinema to a box no bigger than a large book.
And these days, weâve advanced yet another step. We can now stream any film we like, whenever we want, regardless of whether we own it or not. Whatâs more, we donât need any specific hardware or media in the house. We just need a device connected to the Web.
But why are we talking about this? Well, this history matches the ethos at work within Heroku. Heroku strives to turn the age-old and complex process of hosting an application on the Web into one that requires no hardware and no softwareâyou push your code up and the job is done. Heroku is striving to create the Netflix equivalent of application provisioning. In the world of Heroku, if thereâs a choice between software or service, service wins every time.
By knowing more about the inner workings of the Heroku stack, youâll be able to make better educated guesses about how to architect your applications so they can work as efficiently as possible. Youâll be able to identify where you need to focus your own efforts when developing your code, and which parts of your code can be left to add-ons and so on that might be available to you. Youâll be able to recover an application should it go down because you will know where and what to look for. Whatâs more, youâll understand the benefits that the platform can give you and how to encourage those around you to use the platform.
The following typographical conventions are used in this book:
- Italic
- Indicates new terms, URLs, email addresses, filenames, and file extensions.
-
Constant width - Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.
-
Constant width bold - Shows commands or other text that should be typed literally by the user.
-
Constant width italic - Shows text that should be replaced with user-supplied values or by values determined by context.
Tip
This icon signifies a tip, suggestion, or general note.
Warning
This icon indicates a warning or caution.
Note
Safari Books Online is an on-demand digital library that delivers expert content in both book and video form from the worldâs leading authors in technology and business.
Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.
Safari Books Online offers a range of product mixes and pricing programs for organizations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like OâReilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and dozens more. For more information about Safari Books Online, please visit us online.
Please address comments and questions concerning this book to the publisher:
| OâReilly Media, Inc. |
| 1005 Gravenstein Highway North |
| Sebastopol, CA 95472 |
| 800-998-9938 (in the United States or Canada) |
| 707-829-0515 (international or local) |
| 707-829-0104 (fax) |
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://oreil.ly/heroku-ur.
To comment or ask technical questions about this book, send email to bookquestions@oreilly.com.
For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.
Find us on Facebook: http://facebook.com/oreilly
Follow us on Twitter: http://twitter.com/oreillymedia
Watch us on YouTube: http://www.youtube.com/oreillymedia
I started to get involved with Heroku back in 2009 when the development shop I was working at was looking for a simple, effective, and relatively cheap platform for hosting our Ruby on Rails applications. After trying a few different options, we were looking at using a virtual private server (VPS) or Heroku. A few days later, we knew Heroku was the way to go. We could get applications running with the least amount of hassle in the least amount of time, and whatâs more, only pay for what we needed when we needed it.
As time went on, my relationship with Heroku grew closer as I got more and more involved in the platform and I started to base my website articles on best practices and know-how surrounding the product.
Eventually, a couple of things happened. First, I was approached by Heroku and OâReilly to put this book together with Richard, and second, I ended up working at Heroku full time as part of the support team. The last year, therefore, has been a pretty dramatic one, and one that I feel will open up some new horizonsâsome that will improve customer knowledge of the platform, but also to help Heroku confirm that step into the big league of application hosting.
I remember vividly the first time I heard about Heroku: I had just struggled over the course of seven painful days to deploy my first Rails app to a shared hosting provider. I was running Rails 1.2 then. I looked at Heroku, saw it was free to try, and gave it a shot. I was blown away. It took a few minutes to do what took days on another providerâI was addicted. It wasnât entirely love at first deploy though; I tried several other platforms, all of which are now out of business, to see how they fared. I actually ended up using one called mor.ph for a few months because it allowed me to do things that Heroku wouldnât. Eventually, I moved on to my own VPS with a respected cloud provider. I was running a half-dozen sites on one VPS and used another dedicated VPS running a mail server to receive incoming mail for an email anonymizing service I used to run called whyspam.me.
Life was good. Or at least it was until the first of many times my sites went down. I was at work, and couldnât SSH into my box to diagnose until I got home. The fix was simple, but the message was clear: if I was going to run anything serious, I needed to get some more firepower. I switched back to using Heroku and found that those things I couldnât do once, I had no desire to do anymore. They were the same things that caused my VPS to be unstable, so I ended up rewriting those features anyway. What once seemed like arbitrary limitations were now revealed as well-seasoned advice from an opinionated platform.
This was about the same time I began to teach Rails at the University of Texas, and I needed the easiest way for my students to deploy: I chose Heroku. After the lecture on deployment, one of my students actually asked me why programming Rails couldnât be as easy as deploying it. I believe my reply started off âback in my dayâ¦ââif only they knew.
In the meantime, I began working full time for a social network called Gowalla. I loved working on it like only a crazed programmer bent to change the world can love something. When Gowalla was purchased by Facebook in 2011, I sent a note out to my favorite Ruby-backed companies. Luckily for me, Herokuâmy number one choiceâdecided to write back, and Iâve been working there ever since.
I love working on Heroku, and I love introducing people to the beauty on the surface and under the covers of the platform. When the opportunity to write a few words about Heroku came up, I jumped on the chance, and here I am now.
These days, things are moving fast, and especially so in technology. In fact, almost every day we are seeing changes being made to the Heroku platform. Most of these changes are invisible to the user, but changes nonetheless.
In the print world, however, things are set in stone (or ink). Therefore, there are likely to be some inaccuracies or apparent mistakes due to these potential changes. If in doubt, check out the Heroku DevCenter for the authoritative source of up-to-date documentation.
Get Heroku: Up and Running now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
