Cloud

Why Ikayzo Trusts Heroku with our Web Apps

Introduction

Heroku is a managed Cloud hosting provider built on top of Amazon EC2’s (Elastic Compute Cloud) physical infrastructure. The purpose of this white paper is to illustrate the benefits of using Heroku and its value-added tools over managing your own computing resources purely with Amazon EC2.

Architecture

Heroku’s architecture abstracted away the concept of not only physical servers, but virtual servers as well. When provisioning resources on Heroku, one thinks primarily in terms of how many “dynos” are needed for a particular application and load. A dyno is a Heroku concept and can be likened to a single computer process. Each dyno is afforded up to a certain amount of memory (512MB) and runs strictly in isolation to other dynos. Dynos are actively monitored for responsiveness and automatically terminated and replaced with new dynos if they are failing or ailing. This architecture has profound impact on multiple points of interest when considering what it takes to manage your own server infrastructure.

Server Installation

For all but the most trivial web applications, a minimum of three servers is usually required: one database server plus two application servers for redundancy and failover. To accomplish this with EC2 alone, you need to choose an existing server template for your database server, or write your own script to build a new server template which also installs your database onto the template. You then need to do the same for your application server(s). In building the application server, you then additionally need to install and configure a load balancing mechanism for managing requests across the two application servers.

In contrast, all of this is done for you and inherently part of the Heroku offering as soon as you you sign-up.

Failover and Redundancy

In the same breath, you inherently get automatic failover and redundancy built-in when hosting with Heroku. Dynos assigned to the same web application are purposely distributed by Heroku to run in different physical locations. For example, one dyno for your application might be running in Data Center 1, while another might be running in Data Center 2. If Data Center 1 were to experience a power outtage, the dyno in Data Center 2 will still be alive and serving requests for your application. Furthermore, web traffic to dynos are intelligently routed by Heroku to dynos experiencing the least load at the moment. Such services inherently come with any Heroku-hosted application big or small. To achieve cross-location redundancy and intelligent load-balancing for zero outlay on even the smallest of applications is truly unprecedented.

Deployment

To deploy code updates to your application using only EC2, you usually need to install a source code control client on all of your application servers, run the command to pull the latest code from your repository on each server, then restart all your servers. Alternatively, you can implement a mechanism to automatically deploy to multiple servers. With Heroku, you can login (or in some cases do it from your local source code control client), hit update, and all your servers are updated. Even the dyno restarts are automatically done for you.

Scalability

With added load comes a need for more computing resources. Traditionally this need is fulfilled either by scaling up (acquiring bigger servers) or by scaling out (adding more servers). To accomplish this using only EC2 would involve selecting, configuring, and installing bigger and/or more server templates in the Cloud. If your architecture did not allow for “hot-swapping” servers, or real-time addition of more servers, you would also need to schedule down-time and inconvenience users.

In comparison, on Heroku one would simply login to the Heroku console and move a slider up to provision in real-time how many new dynos are needed. That’s it. If/when traffic slows down, simply move the slider back to a fewer number of dynos. The difference in man-hours is literally minutes versus hours, or sometimes even days. In this way, one enjoys both on-demand scaling up and on-demand scaling down, and only pay for the capacity you need when you need it.

Monitoring and Disaster Recovery

To achieve 24/7 application monitoring and disaster recovery with pure EC2 normally requires you to either a) implement your own monitoring machinery against your application cluster, or b) engage another service provider to monitor your application around the clock, and contact your people in case of unscheduled downtime. Without this monitoring, you are relying on your users to notify you of application problems. Heroku actively monitors all dynos around-the-clock and automatically removes unhealthy dynos from the pool and replaces them with new ones. While this does not guard against issues that require manual intervention, such as application bugs, it does help alleviate issues such as long-term memory leaks.

Database Backups

If you are managing your own servers in EC2, you will need to define your database backup schedule, then write the scripts or otherwise implement the machinery to perform the automatic backups. You will also likely need to procure services from another provider such as Amazon S3 (Simple Storage Service), or build your own storage solution to house your backups. Heroku hosting comes with an automatic, database backup solution (described here: http://addons.heroku.com/pgbackups). Manual backup and restoration are also built-in to Heroku tools affording quick and easy backup handling.

Security

While Amazon actively manages its EC2 physical infrastructure (ex. apply firmware patches to physical machines and firewalls), it does not manage what you install on your server templates. If there is a security hotfix for your particular OS and version, it is entirely up to you to be aware of the fix and install it. During initial installation, it is also up to you to choose a secure existing server template, or harden your own server template beyond the physical aspects by turning off all unused services, applying patches, etc. Heroku does all of this for you behind-the-scenes as they actively curate their technology stack and update it with patches, fixes, and secure it with best practices.

PCI Compliance

Although Amazon EC2 has applied for and achieved PCI Compliance Level 1 status, Heroku has not undertaken the same endeavor to hire a QSA (qualified security assessor) to audit their infrastructure and apply for PCI compliance designation. The thousands of e-commerce applications that are hosted on Heroku achieve PCI compliance by off-loading credit card data storage, transmission, and processing to a PCI-compliant third-party payment provider such as Paypal. By offloading credit card data-handling to another provider, these sites deal exclusively with, in PCI parlance, “card-not-present” transactions and fall under PCI SAQ Category A (PCI Self-Assessmention Questionnaire and Attestation of Compliance A). Under SAQ Category A, only the payment provider must be PCI-compliant (i.e. Paypal) for the merchant to be PCI-compliant, and not the hosting provider (i.e. Heroku).

Cost Comparison

A Heroku application with four dynos running 24/7 and one database server will cost $507 a month. The rough computing equivalent on Amazon EC2 will cost approximately $200 a month without factoring in additional costs needed for Heroku-inclusive service equivalents such as backup storage and 24/7 monitoring. This comparison is solely for a single production environment. On Heroku, small environments which suffice for most non-production environments are free. With pure Amazon EC2, you will likely need a matching staging environment for ongoing tests for your particular setup, and at least one other non-production development environment. Running these additional environments more than doubles the $200 monthly cost of a single Amazon EC2 environment, ironically bringing up recurring hosting costs roughly to parity with Heroku. While hosting costs are roughly the same, the real cost advantage of Heroku comes in the man-hours saved not only in initial setup but the ongoing maintenance for the lifetime of the application as illustrated in prior sections of this paper.

Business Viability

In January 2011, Salesforce.com Inc., a large enterprise cloud computing CRM service provider publicly valued at $13 billion, acquired Heroku for $212 million. Heroku currently hosts over 60,000 applications, including applications from BestBuy.com and Flightcaster. In response to natural disasters in December 2010, the Australian government has since securely raised over $30 million AU through an application hosted on Heroku.

Conclusion

Hosting with Heroku versus pure Amazon EC2, ultimately helps you achieve both lower upfront costs and lower ongoing maintenance costs, resulting in substantially lower total cost of ownership from the beginning to the end of life of your application. At the same time, it offers higher QoS (quality of service) out-of-the-box in the areas of application performance, scalability, reliability, security, and disaster recovery.