Heroku Reviews

When I wrote about Heroku and Amazon Web Services a few months ago it seemed both services were equally worthwhile in many respects. My rule of thumb was: small app–Heroku; large app–Amazon. Since then a few events have caused me to reevaluate my position.

Heroku’s customer non-service

Recently, Heroku revealed a new site interface. In the past if you needed something you could open up a free support ticket. Now the only options for free support are the docs or Stack Overflow. Yes, they actually link to Stack Overflow on their new help page. Ticket History is still visible, but there is no way to open up a new ticket.

Granted, AWS doesn’t provide much more than Heroku. But AWS does have a free forum where Amazon employees reply to users’ support questions.

I recently had an issue related to billing with Heroku. Heroku offered a beta period for their new database stack allowing developers to try out their new databases free of charge. I added a couple for testing believing they would remain free until their general release in August. Heroku’s blog post indicated they would notify users prior to billing them.

I assumed there would be an additional step needed to opt-in before being billed, but this was not the case. The only notice I found was a note in one of their email newsletters (which I never read). The notice was one sentence in the middle of the email (underlined in red).

Nearly two months later, I discovered we had accumulated several hundred dollars in charges for databases that we weren’t even using. I tried writing them back at their billing@heroku.com account, but it’s been three weeks and I have not received a response.

How AWS would have prevented this

Around the same time that I noticed the excessive Heroku charges, I logged into our AWS account. What a pleasant surprise to be greeted with a message telling me how to set up notifications for estimated cost triggers. (I already use Amazon’s Simple Notification Service for CPU usage alerts on our EC2 instances.) The alerts are easy to configure due to an intuitive web interface. After establishing a preferred trigger, you can review the past few days’ activity which shows when the trigger would have activated. I immediately set up cost alerts for my AWS account. AWS was nice enough to place the cost alert feature in a prominent place where everyone should see it. Heroku may have a similar feature, but I have not found it.

The billing issue is a small concern, but it illustrates how mature AWS has become while Heroku’s new interface is somewhat of a regression. In the future I will explore how to get up and running on AWS, and how to leverage Ruby gems to achieve similar functionality to that offered by Heroku.

Recently I have been playing PaaS for test thing out, and with recent General Available of AppFog, PaaS providers’ competition become more interesting. In this post, I will compare AppFog with a mature PaaS provider, Heroku.

So, there are many people think, what are their primary features that make you stick to particular PaaS provider? Lets do the comparison using case study.

Memory Management

Do you ever come across a senario where your app is consume 80MB most of the time, or well, 512MB is not enough for you when you deploy a huge Java Web Application (Yeah, Java)?

With AppFog, this is not an issue for you, since they allow developer to configure how much memory they want to allocate to their app. Wow, awesome right? No more wasting your money to invest on ten dynos on heroku, where a lot of memory is not used.

However, this can be a issue for you, if you choose to deploy your app to Heroku, you will need to buy a dyno with 512MB of RAM where either sometime is too larger, or too small. If your application consume 100MB RAM, and you deploy ten dynos, well, you wasted (512 - 100) * 10 = 4120MB of RAM!

Pricing Model

I have a web application on production, suddenly my application is getting huge traffic after a tweet by a famous person. I want quickly scale my application to handle such traffic.

According to AppFog pricing model, it is by subscription based model by select a plan. However, assume their able to upgrade plan within minutes, then it is fine (See Comment). But what if upgrade plan required more than 4 hours? Maybe your application will crash before upgrade to better plan. Futhermore, after 1 week your application traffic is back to normal, I believe you want to downgrade plan to save some money, which required you to submit a ticket to their support. However, AppFog offer free plan with 2GB of RAM, equivalent up to 4 dynos at heroku.

Heroku is pay as you go, scale on demand PaaS, so this kind of senerio will not affect heroku users. Futhermore, you can scale to 10 dynos for an hours then scale back to 2 dynos. Cool.

Data Centers

I have a application, with the target users are from Asia. I want able to serves my content from data center that with low latency to Asia visitors.

AppFog is the first PaaS provider provide cross regions deployment option to its customers. It allow me, a developer from Asia to deploy application that nearby here, such as Singapore. This enable my application serves visitors faster.

Heroku does not support cross regions deployment option to its customers. I have a test application writed in Ruby On Rails, with a feature to upload a image to AWS S3 bucket at Singapore. But its not stable because there is 30 seconds timeout on heroku platform, which is reasonable constraint. But I just cant accept the application always failed to upload a image file. The workflow petty simple:

Upload file to application at Heroku -> scale image into 3 deviations -> upload images to my AWS S3 bucket at Singaprore.

Maybe I need redesign my application to use dyno worker, Resque, Redis to do such thing? Wow, I give up.

Data Store

Most of the application required at least one datastore, let say I want a Relational Database for my application, I want able manual backup before deployment, daily automatic backup, and other features.

AppFog just GA not long ago, currently they have free shared DB, such as mongoDB, MySQL, Postgres. However, they still no plan for serious production database option, but only through add-on such as ClearDB. But their roadmap included dedicated database, hopefully will be feature rich database plan and release soon!

With heroku, it offer serious database production for RDBMS, Postgres. Futhermore, their offer also include other nice feature such as fork, follow, data clip and so on.

Deployment

Assume I use scripting language such as Ruby for my application, I want able to deploy to production with simplest way, such as git push.

Unforturenly AppFog does not have git integration into deployment, unless you need a custom application to deploy for you, such as node-pusher.

Heroku’s deployment is tightly integrated with git, it is great and most of the people use git anyway.

Conclusion

The table below show the sumarrized comparison.

My choose of PaaS is AppFog, even the comparison shows Heroku is better. There are some roadblock in heroku cause me to choose AppFog such as memory managemet and Data Centers.

A blog post went viral this week and uncovered an issue in PaaS provider, Heroku’s routing mesh, which has caused a significant degradation of Ruby on Rails app performance. Essentially, over the past three years Heroku moved from “smart” to “random” web request routing among an account’s “dynos”, Heroku’s processing units. Each dyno runs about $35/month.

The change in architecture, which is explained in detail here, is only a portion of why Heroku is catching heat. Here are the real reasons:

Same cost, less value

First and foremost, there have been no reductions in price for the net reduction in capacity provided by the service. This is especially frustrating to the community at a time when other PaaS providers like Amazon Web Services (AWS) continue to lower their prices. Heroku’s platform leverages AWS in its architecture. Over time, users were purchasing more dynos for their accounts with diminishing returns. Each additional $35 dyno does not provide $35 in value.

Appearance of deception

Second, Heroku boasts robust monitoring tools that allow you to see the performance of your applications across many layers of their architecture. However, the monitoring tools provided by Heroku and New Relic don’t reflect the area of latency caused by random request routing. For a highly sophisticated platform provider, this oversight comes across to the community as deceptive rather than as an oversight.

Lack of coherent communication

Finally, there was no communication to customers about the change, and no consistent and coherent documentation. In fact, documentation around Heroku’s site was confusing and contradictory. Again, the appearance of deception.

Response

Heroku is responding openly and humbly, which is the proper way to handle the situation, but there are many who don’t think the responses go far enough. They want monetary reparations as well. I’d guess Heroku is considering concessions quietly by necessity as they are part of a publicly traded company and any concessions could have an impact on current and prior period financials of the company.

The whole debacle reminds us that the lack of transparency over time can cause much larger PR problems for companies than the issues themselves. Individual customers have the platform to tell their story and initiate change.

What is our primary use case?

What is most valuable?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

How are customer service and technical support?

How was the initial setup?

What other advice do I have?

Which deployment model are you using for this solution?

I have been a great fan of Heroku as it simplified my work for many years.

But I recently got my account suspended because someone abused one of my apps. Since then, I decided to leave Heroku because I cannot afford to loose control on my work.

Here's the story: http://augustin-riedinger.fr/e...

What is most valuable?

What needs improvement?

For how long have I used the solution?

How are customer service and technical support?

Which solution did I use previously and why did I switch?

How was the initial setup?

What's my experience with pricing, setup cost, and licensing?

I first used Heroku to deploy and host Facebook apps, and I’m a big fan ever since.

Lately, I’ve been doing development with node.js and since Heroku supports it (wonder if they were first to offer it), it was a no-brainer:

• deployment via command line with git: nice way to enforce best dev practices
• package management with NPM – everything will be fetched and installed for you
• built-in SSL support on *.herokuapp.com subdomains
• easy monitoring: just type ‘heroku logs’
• easy scaling: just type ‘ps:scale web=x’ or ‘ps:scale worker=x’
• support of environment variables: one example – running multiple instances from the same git repo
• pretty good docs and tutorials
• tons of add-ons: you are free to do pretty much anything (I use Mongolab add-on for Mongo hosting)
• affordable!

Nodejitsu is another service focusing on node.js primarily, but I’ve been reluctant to switch because I just like Heroku so much.

It’s also super cool that they support multiple environments via buildpacks, I’d love to look under the hood and find out how they made it work (and here’s a great post describing their polyglot platform in high-level)

In contrast to the one-language-per-career programmer, today’s up-and-coming developers can often utilize many languages effectively. Borrowing a term from linguistics, we can call these versatile new developers “polyglot programmers.”

For the latest Show&Tell demo, I talked about benefits of using Heroku (as one of the PaaS options) for rapid deployment and easy hosting, so here’s the deck.

This week I’m working on a recommendation chart for cloud hosting, so I’ll share that as well soon.