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?

What do I think about the scalability of the solution?

How are customer service and support?

How was the initial setup?

What about the implementation team?

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

What other advice do I have?

Which deployment model are you using for this solution?

We love Heroku. It makes deployment so easy and quick. However, it can start to get pricey when you add additional dynos at $35 each a month.

With a small amount of work, you can get a lot more out of your Heroku hosting whilst drastically improving the performance of your site. You might need to spend a little bit of cash on other services, but a lot less than if you simply moved the dyno slider up a few notches, and the result will be much better scalability.

So how do we max out the performance of our Heroku apps? First we stop using Heroku for things it’s bad at, then we let it do more of what it is good at, running your application code.

1. Offload Assets to S3 and CloudFront using asset_sync

By default a Heroku dyno is responsible for serving all the assets for your site, so every page load will involve multiple requests to the dyno.

The asset_sync gem modifies asset pre-compilation to sync all of your assets to an Amazon S3 bucket from where they are served directly and freeing up your dyno to handle more requests.

If you want to speed things up even more, you can slap Amazon’s Cloudfront CDN in front of your S3 bucket with multiple subdomains. Michel Sikkes has an excellent guide to serving you assets with S3 and cloudfront. Your assets will be served through Cloudfront from multiple subdomains (e.g. assets[0-3].myapp.com), all of which point to the same bucket. Not only will your assets be served through CloudFront’s speedy global CDN, but most will be downloaded in parallel. Browsers make a limited number of concurrent requests per host name (2 for IE, more for other browsers) so using multiple CNAMEs increases the number of concurrent connections, significantly reducing the page load time for users with good connections.

The cost of serving assets from S3, even with CloudFront, is very cheap and scales directly with the amount of data. Compared to adding another Heroku dyno this is great value, and has the added benefit of speeding up overall page loads.

2. Don’t Upload and Process Files with your Web Dynos

If you use something like CarrierWave or Paperclip, by default the uploading and processing of images is done by your dyno. While this is happening your dyno is completely tied up, unable to handle requests from any other user. If one person uploads a 2Mb image on a slow connection everyone else will be locked out for the duration.

To prevent this from happening you need to decouple the upload process from your dyno. The CarrierWave Direct gem does just this. With a bit of client-side magic it uploads files to S3 directly, rather than through the dyno. The images then get resized by background processes using DelayedJob or Resque. This obviously has the downside that you’ll need a worker running, but there are ways to manage these cost-effectively which I’ll talk about next.

Another option, which we’ve used recently, is the awesome Cloudinary service. They provide direct image uploading, on-demand image processing (including face detection, which even seems to work on cats) and a worldwide CDN all in one package. There is a free tier to get you started, and for $39 (slightly more than one Heroku dyno) their Basic plan will be more than enough for many sites. Obviously you could just spend money on another dyno, but that just scales your performance linearly, without really solving the fundamental performance bottleneck.

3. Background Processing the Smart Way with Delayed::Job and HireFire

Background processing with Delayed::Job is a great way of speeding up your web requests. Potentially slow tasks like image processing or sending signup emails can happen outside of the request-response cycle, making it much snappier and freeing up your dyno to handle more requests. The downside is that you need to run a worker dyno at $35/month.

Michael van Rooljen’s HireFire modifies Delayed::Job and Resque to automatically scale the number of worker dynos based on the jobs in the queue. Because Heroku charge by the dyno/second, spinning up 10 workers for one minute costs the same as one worker for ten minutes, so with HireFire you can potentially get things done quicker while paying less than you would if you ran a dedicated worker dyno.

HireFire does have one limitation, it only works for jobs scheduled for immediate execution. If that is an issue Michael has a HireFire service that will monitor your application for you, so jobs scheduled in the future will be run.

4. Offload Complex Search to a Dedicated Provider

If you have an application that needs to perform complex searches over large datasets don’t do it in your application directly. If searches regularly take a long time (a couple of seconds or more) consider using something like Solr (available as a Heroku plugin), Amazon CloudSearch, or one of the many Search as a Service providers. You’ll not only get faster search performance in many cases, but you’ll save vast amounts of development time trying to optimise your in-app search. Of course, if you have a simple application with straight-forward search then this probably won’t be worth it the cost, but it’s something worth considering.

5. Turbo-Charge your Application with Memcache backed View Caching

If you’ve not encountered caching in Rails, stop reading this article right now, go read the Rails Guide to Caching and then DHH’s short guide to key based cache expiry. Caching in Rails 4 will be even better, with improved support for “Russian Doll” caching.

View caching in Rails can have a profound effect on your application’s response time. In the past we have found that rendering pages, especially complex ones with lots of partials, can easily account for two-thirds of the total processing time, much more than you might expect.

Simply using caching will help speed up your application, but the default cache store is not shared between dynos so the benefits are limited. In contrast, a Memcache store is shared between your dynos so they all benefit from any cached item. Heroku has two add-ons that let you very easily add memcache to your project. The Memcachier addon gives you 25mb for free, and is pretty reasonably priced from there on up. Just adding a small cache store of 25mb can make a significant difference to the load time of your pages.

6. Finally: Slice and Dice your Dynos with Unicorn

So after spending a little bit of time, and a relatively small amount of cash, we’ve offloaded much of the work that was being done by our web dyno and onto services that are better suited to it; drastically speeding up our request-response cycle. Our single dyno can now handle significantly more users per minute, who are happier because they get a much faster response from the site.

However the default Heroku dyno configuration only handles one request at a time. If you wanted to increase your level of concurrency in the past you would have to increase the number of dynos. That’s all changed with the release of the Rack server Unicorn which can handle multiple concurrent connections. For most applications a single dyno should be able to handle between two and four connections at a time. The main constraint will be memory (limited to 512mb per dyno), so keep an eye on the gems you are loading in your production environment. Florian at Rails On Fire has done a great introduction on setting up Unicorn on Heroku. If you’ve followed the previous steps you should be using less memory on your web dynos, allowing you to use more threads.

Putting it all Together

At the end of all this we’ve freed up our Heroku dyno from doing things it’s not very good at like serving static files and uploads, and juiced up its performance when doing what it’s great at, serving Rails application requests with no sys-admin in sight.

Each technique can be easily applied to your existing applications, but if you develop with them in mind from the start you get all the benefits with almost no additional work. On their own each one will help the performance of your application, but combining them together will significantly extend the amount of time before you have to start forking out for lots more dynos, and when you do you’ll get much more bang for each of your thirty-five Heroku bucks.

If you’ve got any other tips for getting the most out of a Rails application, whether or not it’s on Heroku, we’d love to hear about it them!

Platform as a Service is a one of the GROWING sector of cloud computing. PaaS basically help developer to speed the development of app, saving money and most important innovating their applications and business instead of setting up configurations and managing things like servers and databases.

Other features buying to use PaaS is the application deployment process such as agility, High Availability, Monitoring, Scale / Descale, limited need for expertise, easy deployment, and reduced cost and development time.

Major forces driving the PaaS

- Pay as you Go
- Low start up cost
- Leave the plumbing to expert
- PaaS handles auto scaling/descaling, Load blancing, disaster recovery
- PaaS manages all security requirements
- PaaS manages reliability, High Availability
- Paas manages manay third party addon’s for you

Barrier to PaaS adoption?

- Less Control over Server and databases
- Have to be expert to mange security controls and audits
- Costs will be very high if not governed properly
- Premature and dobious in current day and age

Major PaaS providers are Heroku, Jelastic, and Engine Yard. When we talk about revenue, The global PaaS market is estimated to grow from $1.28 billion in 2013 to $6.94 billion in 2018 at a compound annual growth rate (CAGR) of 32.54% in this period. In terms of geographies, North America continues to be the biggest market for PaaS solutions. In 2012, PaaS revenues ($1.2 billion) was the tenth of the size of SaaS ($14.4 billion), a fifth of IaaS ($6.2 billion), and just a tiny fraction of BPaaS ($84.1 billion).

PaaS has always taken a very small space in the cloud computing arena as compared to the other two segments: IaaS and SaaS. But the trend has recently shown a drift with PaaS market showing a very high growth rate in terms of revenue. Though it is still not as huge as the other two segments but now holds a significant proportion of the pie. PaaS has now been adopted by most of the big cloud computing and IT solution providers like Amazon, IBM, Google etc. as one of their main services.. Many small players have also emerged and made the market very dynamic and competitive. Application developers are benefiting from this fact resulting in more adoption and thus increasing the demand for PaaS all the more in various sectors.

We expect to see more and more application development companies choosing PaaS over IaaS or traditional Hosting, as they can then focus on driving innovation and building apps that change their interactions with customers, partners and community. It will make them free of the details of infrastructure, so they can push the possibilities of the latest technology to build great web and mobile applications.

Big spender.

There’s my heroku bill after hosting the voting for a local television contest. $2.37. Over 40,000 people used the app over a period of 2 weeks.

I spent the same amount on coffee this morning.

What?! How?!

I’ve always been really interested in scaling and getting the best possible performance out of limited resources.

I had the opportunity recently to build out the voting back-end for a local television contest. Projects like this are fun because I had the flexibility to try out something new and a lot of people would be using it.

The Stack

I wanted to build an API to handle the voting and get the best performance out of it. Usually I’d use Sinatra for this, but this time I chose to try out Goliath, which is a non-blocking Ruby web server for building APIs. I also used Grape since it would make writing the API even easier.

I hosted it on Heroku. My initial goal was to see if I could keep it to only 1 dyno (more fun with a challenge).

If you’re not familiar with Heroku, a dyno is the equivalent of a small virtual server with 512mb of memory. They also give you your first dyno for free. So all I ended up paying for was the postgres basic database add-on.

Stress Test

Before releasing it, I did some stress testing with Siege. I couldn’t have this app failing when it went live.

212.45 transactions per second.

On only 1 heroku dyno.

WOW GOLIATH IS FAST.

Each transaction was a single GET request, that hit the database (postgres) and returned the count of contest votes. Postgres was probably the slowest part of each request. I could optimize even further by caching with memcached. Maybe next time.

The 200+ transactions per second was way more speed than I needed for this app. And much more than I expected to get out of a single dyno.

I knew that the traffic for this app would be pretty sporadic. Highly dependent on when it was mentioned on TV. Without Goliath, I would have needed to use more dynos to account for the spikes in traffic. But with the performance I was seeing out of Goliath, I knew it could handle the peaks with just 1 dyno.

See the details of the Seige test here.

If you’d like to try it out yourself, the app I used to run this contest was a modified version of Mathy Poll. Which is open source and you can grab it on github.

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.