Updated on July 5, 2017 by UpGuard
Cloud computing is no longer the next big thing. As evidenced by all the cloud infrastructure and data centers now being set up by established players like Google with its AppEngine and Amazon with AWS, it is the current big thing. Into this mix are some smaller pioneers like Heroku, started all the way back in 2007 – in cloud computing that’s the late Jurassic period. Let’s compare two PaaS offerings, Heroku and Google’s AppEngine, and see what makes each of them tick.
Heroku and AppEngine are philosophically similar in that they are both PaaS solutions. They both provide you with a ready-made environment in which you can deploy your code and apps, though that environment only hosts a limited range of OS, languages, databases and other base platforms on available. This means you can get up and running fairly quickly, but it also implies that if your app doesn’t run or isn’t hosted or developed by the stuff on the pre-approved list then you’re left high and dry. This is in stark contrast to IaaS platforms such as Amazon’s AWS that provide you with a virtual machine in which you can install and customize your software environment as you wish.
What They Are
Google’s AppEngine presents you with an abstracted view of a machine instance that runs your code and supports Python, Google’s new Go language, and Java and other JVM languages such as Clojure, JRuby and PHP. One caveat is that only pure Python is supported, so you can’t run modules containing, say, C code. With such language restrictions it’s clear to see that Google is presenting developers with a cosseted, language-aware, sand-boxed environment in which to run code. In fact easy, no-frills sandboxing is a major AppEngine’s forte, together with the ability to quickly and easily scale horizontally for load-balancing. Still, many have complained that AppEngine’s proprietary, read-only nature results in tedious and unnecessary code refactoring; apps have to be written specifically with AppEngine in mind, API’s have to be written specifically for AppEngine, even standard Java code has to be extensively altered to fit into the AppEngine environment. Another sore point is that Google insists on AppEngine customers only using its BigTable non-relational database, although they have also recently added some support for CloudSQL. So allocate a significant amount of time for ‘database refactoring’ for your apps’ backend DB when moving already-developed apps to AppEngine. This porting of apps away from AppEngine to other platforms is such a major pain it has led many to darkly hint of a sinister plot by Google to lock in customers to their framework.
Heroku, now owned by Salesforce, originally supported Ruby only, but now also includes support for Java, Node.js, Scala, Clojure, Python and PHP. It is still recognized as an excellent host for Ruby platforms and frameworks like Ruby on Rails. In terms of databases, you have both relational and non-relational choices in PostgreSQL, MongoDB, Cloudant, and Redis. This highlights Heroku’s massive advantage over AppEngine – Heroku’s database-platform choices reflect a collection that is in widespread use already in the wider world. It’s relatively easy to port your DB from Oracle to PostgreSQL because they are both relational, for example, but good luck trying to move your relational DB to the non-relational BigTable. It can be done, but it’s an expensive (in terms of time) and painful exercise. Heroku’s infrastructure is hosted on Amazon’s EC2 could servers.
Support & Pricing
Support and help for both is excellent. Heroku is smaller than Google but has been around longer (2007 vs. 2011). The Heroku user community is particularly active and helpful. And Google’s Goliath-ness means there is no shortage of in-house support for AppEngine.
Comparing pricing for PaaS products is an exercise in frustration. You would think that similar products in the same market would offer the same features would lend themselves easily to comparison. The BMW 5-series for example, competes with the Mercedes E-Class and Audi A6 in the luxury midsize sedan market, so you can calculate the cost of optioning them up to the same spec, then easily compare the costs. For PaaS products this is difficult to do. For instance you get a free tier with both, but they have different capabilities. Heroku’s PaaS unit is called a dyno, and it offers 512MB, unknown CPU power and 100MB swap space for free. From there if you need more dynos for scaling, it costs $0.05 per hour. The dyno equivalent on AppEngine is called a FrontEnd instance, and it costs $0.08 per hour. After that you need to pay for the database, which on AppEngine is $0.24 per GB per month, and on Heroku is a tiered plan from $9 to $100 for a 1TB. Then AppEngine charges you $0.07 for every 100k reads and $0.10 for every 100k writes to the datastore, which is an outrage – there is no good reason for cloud compute platforms to charge users to read and write their own data. Heroku doesn’t charge for read/ write operations. Oh, then after this you need to factor in charges for file storage …
Anyway, at the end of the day, Heroku seems to be significantly cheaper than AppEngine. For an excellent, in-depth analysis and comparison of Heroku vs. AppEngine pricing, go to this page: http://kmilo0.blogspot.com/2013/02/gae-vs-heroku.html.
Heroku and AppEngine are very close competitors. They both have their good and bad points. Overall though, the sentiment in the developer community (that’s the crowd that mainly uses PaaS’s) is that AppEngine is a missed opportunity by Google because of its closed-in, proprietary nature and lack of platform choices. Heroku offers few restrictions on what can and can’t be done in your hosted app, and you also have powerful access to the user space your application runs in. But Heroku’s AWS base means that Amazon’s high-profile and damaging service outages also affect Heroku customers.
In the end, Until Google improves and stop viewing AppEngine as a way to tie in customers to the Google universe, we have to give the edge to Heroku as the better platform. Also see the pros-cons table below for further comparison:
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.