With over 80,000 applications on Heroku, we are frequently asked what type of apps people are building. While there’s a wide range, one of the areas I’ve been most excited about is social apps. We have thousands of social applications around Twitter, Facebook, and other platforms. The Social App Workshop last month was proof of the interest with a sold out crowd of over 150 people filling a basement on a great summer Saturday.
Social platforms are sweeping enterprises as well. From internal communities for collaboration to external communities with millions of users, enterprises are finding social software essential to how they work. Today we’re announcing a partnership with the leader in this space – Jive Software. Over 3,000 leading companies, including over 25% of the Fortune 100, use the Jive platform to engage their employees, customers and partners.
If you are interested in building social applications for the enterprise and reaching millions of employees, we have a great opportunity for you. For the first time, Jive is opening up their platform to 3rd party application developers. Their new Jive Apps Market will make it easy for customers using the Jive platform to purchase cloud-based social app software. You’ll be able to deploy your applications to Heroku, and have companies from around the world view, purchase, and use your app within Jive. Jive is leading the way in bringing cloud social business applications into the enterprise, and we’re honored to be part of it.
To help you get started, Jive is holding their first ever Jive Apps Developer Event on September 16th at the San Francisco InterContinental Hotel. This is a great opportunity to both evaluate the size of the Jive Apps opportunity by mingling with enterprise customers as well as get the technical details from Jive engineers.
Jive and Heroku have teamed up to offer 10 free passes to the event. If you’d like to enter to win one of the passes, fill out this survey before Sept 2nd.
Last month’s Social App Workshop was a huge success. With a sold out crowd of over 150 people filling the basement of our new office, a great lineup of presenters and some fun coding in the afternoon it surpassed our expectations. Social App Workshop is a hacker event for new and experienced developers working on Twitter & Facebook apps. With a combination of presentations and coding the workshop brings developers together to work on social apps.
The morning was spent with a combination of 10 min talks and 30 min talks from Facebook, Twitter, Heroku, Apigee, Twilio, and Abraham Williams. After getting everyone amped up in the morning, we broke into groups in the afternoon to code up fun projects. Projects ranged from sample apps using oauth for twitter to a wake up call service for travelling moms.
If you weren’t able to make it, we’ve posted all the videos of the talks and embedded them below as well.
We’re working with Dave Nielsen to hold additional Social App Workshops, both here in San Francisco as well as around the world. If you have ideas or would like to see this type of event in your town, leave us a comment and let us know!
Bundler is quickly shaping up to meet all it’s promise as THE best way to manage your application dependencies. This afternoon we updated Heroku to the latest version – 1.0.0RC5. RC5 addresses all known outstanding issues including the git sourced gems. You can see a full changelog on github.
One key problem Bundler was designed to address was the shifting sands of various gems updating and changing dependencies. As many of you have probably found in the past before Bundler, deploying could unexpectedly install new versions of gems on you, breaking your application. Bundler has added a new flag: “—deployment” for this very issue.
When you run “bundle install” on your local development machine, Bundler will automatically create a Gemfile.lock file. The lock file includes a pinned version of all of your gem dependencies, for all groups. When the deploy process then uses the —deployment flag, the installation will only install the version of gems that are listed in the Gemfile.lock, which was generated on your development machine. This ensures that even your dependent gems change, the dependencies on the dependencies change, etc, you won’t be surprised by updating to a different version than you tested against.
To work, the —deployment flag requires that you have a Gemfile.lock. Currently, Heroku runs “bundle install” against your application if you don’t have a Gemfile.lock, and “bundle install —deployment” if you do. Starting next month, we will begin to use the —deployment flag 100% of the time. This means you must commit a Gemfile.lock to your git repo. Simply run bundle install locally, git add your Gemfile.lock, and you’ll be all set for the future.
Why NoSQL Matters
“NoSQL” is a label which encompasses a wave of innovation now happening in the database space. The NoSQL movement has sparked a whirlwind of discussion, debate, and excitement in the technical community. Why is NoSQL generating so much buzz? What does it mean for you, the application developer? And what place does NoSQL have for apps running on the Heroku platform?
SQL (the language) and SQL RDBMS implementations (MySQL, PostgreSQL, Oracle, etc) have been the one-size-fits-all solution for data persistence and retrieval for decades. The rise of the web and the LAMP stack cemented the role of the relational database. But in 2010 we see a variety of application needs which are not satisfied by MySQL and friends. New problems demand new tools. High availability, horizontal scaling, replication, schemaless design, and map/reduce capability are some of the areas being explored by a new crop of datastores, all of which are loosely categorized as NoSQL.
To understand why NoSQL is important to you as an app developer, let’s consider the use cases for some of these features:
- Frequently-written, rarely read statistical data (for example, a web hit counter) should use an in-memory key/value store like Redis, or an update-in-place document store like MongoDB.
- Big Data (like weather stats or business analytics) will work best in a freeform, distributed db system like Hadoop.
- Binary assets (such as MP3s and PDFs) find a good home in a datastore that can serve directly to the user’s browser, like Amazon S3.
- Transient data (like web sessions, locks, or short-term stats) should be kept in a transient datastore like Memcache. (Traditionally we haven’t grouped memcached into the database family, but NoSQL has broadened our thinking on this subject.)
- If you need to be able to replicate your data set to multiple locations (such as syncing a music database between a web app and a mobile device), you’ll want the replication features of CouchDB.
- High availability apps, where minimizing downtime is critical, will find great utility in the automatically clustered, redundant setup of datastores like Casandra and Riak.
Despite all the use cases described above, there will always be a place for the highly normalized, transactional, ad-hoc-query capabilities of SQL databases. We’re adding new tools to our toolbox, not removing old ones.
Polyglot Persistence – or, How Do You Pick a NoSQL Datastore?
Part of the NoSQL message is: pick the right tool for the job. The use cases outlined above should help guide your choice of datastore, as will many resources around the web like this diagram, these slides, or this video. And, like any technology, you should pick something that feels right for you and your team.
But most apps encompass multiple use cases. How do you pick one database to handle all the types of data your app needs to deal with? NoSQL answers: you don’t have to pick just one. This concept is called polyglot persistence (more details).
For example, we can imagine a web app which uses four different datastores:
- MySQL for low-volume, high-value data like user profiles and billing information
- MongoDB for high-volume, low-value data like hit counts and logs
- Amazon S3 for user-uploaded assets like photos and documents
- Memcached for temporary counters and rendered HTML
Polyglot persistence also makes it easy to dip your toes into NoSQL. Don’t migrate your existing production data – instead, use one of these new datastores as a supplementary tool. (Example: put non-critical session data or stats into Redis or Tokyo Tyrant.) And if you’re starting on a new app, you should give serious consideration to NoSQL options for your primary datastore, in addition to the venerable SQL choices.
NoSQL and the Cloud
The SQL databases we’re using today were designed over a decade ago. They were written with the constraints of 1990s hardware in mind: storage is cheap, memory and cpu are expensive. Today’s machines have different parameters. Memory and CPU are cheap, and can easily be scaled up on demand without capital expenditure using a service like Amazon EC2. But EC2, like all cloud technology, is based on virtualization. Virtualization’s weakness is I/O performance. So, the constraints of disk and memory have swapped: disk is the weak link in the chain, memory and cpu (spread out horizontally) are the strong links. It’s not surprising, then, that the datastores built a decade ago aren’t a good fit for the new parameters of cloud computing.
NoSQL databases tend to use memory over disk as the first-class write location: Redis and Memcached are in-memory only, and even systems like Casandra use memtables for writes with asynchronous flushing to disk, preventing inconsistent I/O performance from creating write speed bottlenecks. And since NoSQL datastores typically emphasize horizontal scalability via partitioning, this puts them in an excellent position to take advantage of the elastic provisioning capability of cloud. NoSQL and cloud are a natural fit.
Database-as-a-Service is the Future
Infrastructure-as-a-service like Amazon EC2 and Rackspace Cloud are what most of us think of as “cloud.” One of the effects of these large public clouds is that apps now have extremely low latency between themselves and other apps or service providers – 1ms or less compared to 50ms+ on the open internet. This latency difference opens up vast new possibilities for what a 3rd party service provider can offer.
Database-as-as-service is one of the coming decade’s most promising business models. Already services like MongoHQ (MongoDB), Cloudant (CouchDB), and Amazon RDS (MySQL) are offering fully hosted and managed databases to apps running in EC2. Like IaaS, DaaS promises remove up-front capex costs, and bring efficiency of scale and specialization in the admin and operation of databases. Although these services are still very young, the potential benefit of being able to outsource all the headaches of running and scaling your app’s database are enormous.
DaaS also goes hand-in-glove with polyglot persistence. Thanks to database services, you won’t need to learn how to sysadmin/DBA for every datastore you use – you can instead outsource that job to a service provider specializing in each database. One of the reasons databases have historically had a tribal affiliation (someone is a “MySQL guy” or a “Postgres gal” or an “Oracle guy,” but rarely two or all three) is because of the time investment in learning how to admin whatever database you use. DaaS removes that barrier and opens up even greater possibility for polyglot persistence in production use.
Heroku’s Commitment to Database Innovation
Heroku already supports two of the most popular NoSQL databases, MongoDB and CouchDB, as add-ons: MongoHQ and Cloudant. We also support the transient key-value datastore, Memcache, via Northscale’s service.
Looking forward to the future: we have more NoSQL add-ons coming down the pipeline, such as Redis To Go. And we’ll be continuing to work with technology leaders in the NoSQL community to help them bring their database services to market. Our goal is to provide access to the cornucopia of breakthrough new database technologies from the NoSQL world, available from the Heroku add-ons catalog at the click of a button. We hope to make Heroku a great place to play with these new technologies, while still curating a list of options that are fully baked and ready for use in real production applications.
Of course, we can’t forget that Heroku currently runs the largest and most mature SQL-database-as-a-service in the world: our PostgreSQL service, packaged with every Heroku app. We’re continuing to expand and improve this service (including support for great new features in Postgres 9), because we know SQL and the apps that depend on it are here to stay. Reinforcing our commitment to polyglot persistence, we’ll be turning our Postgres service into a separately packaged add-on – still installed by default into each app, but possible to opt out, or combine with other datastore add-ons. We also hope to see other providers in the SQL-as-a-service space besides Heroku’s Postgres service and Amazon RDS.
It’s an exciting time for data, and our team here at Heroku is thrilled to take part in the continuing growth of the NoSQL movement.
More and more developers are using Heroku as a SaaS deployment platform. By creating their applications on top of Heroku, they can leverage our architecture and security model to provide SaaS to their customers easily. Today we want to highlight a new favorite, Teambox.
Teambox is an opensource twitter-like collaboration tool for companies organization and teams. Teams around the world use it to http://teambox.com/tour and keep in touch, track tasks and much more.
The teambox team has made it easy to install on Heroku as well. This screencast walks you through the instructions from start to finish in just 5 minutes. Give it a try yourself, and try out their collaboration tool.
Deployment stacks have been a huge success. For many developers, heroku create —stack bamboo has become the default whenever creating new apps. With the latest version of Rails 2 and Rails 3 both requiring the Bamboo stack, we’re excited to make Bamboo the new default.
Effective immediately, all newly created apps will default to the bamboo stack with REE 1.8.7. You can still use the old aspen stack if you’d like by simply specifying `heroku create —stack aspen`. Existing apps stay on the stack they are on unless you explicitly migrate them.
A key feature of bamboo is to eliminate pre-installed gems. This provides app developers with considerably more flexibility in managing their apps. You can easily use any version of any gem by simply including it in your .gems file or Bundler Gemfile. You’ll need to remember to include all gems you are using. If you’re using Gemfile, this is automatically done for you. If you’re using .gems, please make sure to include all the gems you use, INCLUDING rails!
Heroku now supports Rails 3 beta 4 with Ruby 1.8.7. Make sure to push up to bamboo, and you should be all set!
As Rails 3 matures and gets closer to production a number of pieces continue to change. The beta 4 update introduced two significant changes to be aware of:
- Require Ruby 1.8.7 > p249 or Ruby 1.9.2.
- Require Bundler 0.9.26.
Heroku has updated to Ruby REE 1.8.7-2010.02 which incorporates the necessary patches for Rails 3. We will add support for 1.9.2 when the community releases the official release. In the meantime, developers interested in using Rails 3 on Heroku must use Ruby 1.8.7.
We have also updated to the latest stable release of Bundler: 0.9.26. We will continue to track the evolution of bundler through their 1.0 release. Due to thousands of applications that have already adopted bundler on Heroku, each update must be carefully tested to ensure that we don’t disrupt ongoing application operation.
If you develop apps for Twitter, this is the add-on for you. The Apigee for Twitter Add-on allows developers to easily access Twitter REST api’s. Through a direct relationship with Twitter, Apigee can offer users of the Add-on vastly increased rate limits automatically. The goal is to ensure that no valid application hits rate limits at all.
If you’re developing applications using the Twitter REST api, check out the add-on today. Using it is often as simple as changing your app to use the apigee provided config var endpoint instead of “api.twitter.com”. Full docs are available here, and as always please let us know how it works for you.
This past Sunday, Rails 2.3.6 was released, and quickly followed by 2.3.7 and 2.3.8. One of the major changes in these new versions is to require a newer version of Rack, specifically 1.1.0, that is incompatible with Rails 2.3.5 and older. Due to the fairly complex ways in which Rubygems resolves dependencies, this can prevent your app from starting – in your local environment as well as when deployed on Heroku. If you’ve been affected by this issue, you would see this error message:
Missing the Rails gem. Please `gem install -v= x.x.x`,
update your RAILS_GEM_VERSION setting in config/environment.rb
for the Rails version you dohave installed, or
comment out RAILS_GEM_VERSION to use the latest
version installed.
We have written up a new docs page page with information detailing the issue, how to reproduce on your local machine, and how to resolve it.
We can’t be happier to announce that we recently closed a $10 million Series B round of investment led by Ignition Partners. We’re planning to use the money to further expand our platform, turbo-charge partner programs for add-on providers and consultancies, and accelerate our go-to-market programs.
The growth and excitement that we’ve seen at Heroku, particularly in 2010, has been incredibly energizing for all of us. We talk a lot about numbers – the 60,000-plus apps running on our platform gets quoted a lot recently – but even more motivating are the creative forces that the platform is unleashing.
Developers and companies are building and running some amazing apps with our platform (check out the United Nations app ProtectedPlanet.net for one of my recent favorites). Ruby on Rails consultants are growing their businesses and creating happier customers. Technology vendors are building some very cool extensions to our platform as part of the Add-on system.
In other words, creating an open, efficient, and reliable platform that upends the status quo is not just about technology: it’s about resources and support for developers, making it easy for partners to use the platform for their own customers, and enabling technology partners to build businesses by extending the platform itself.
It’s also about having a great team. We can’t be prouder of the team we’re building at Heroku (if you might be interested in joining, please check out jobs.heroku.com), and the team just got stronger: John Connors of Ignition has joind our board. John is a super-smart, super-seasoned executive with a wealth of experience (including stints as CIO and CFO at Microsoft) that we’ve already begun to draw on as we plan what’s next for Heroku.
We’d like to take this moment to thank all of you for your support. We’ll take full advantage of the additional resources and expertise joining us today to serve you in the future.
Official news release here.
Let’s cut straight to the chase: MongoHQ is launching their add-on to all Heroku users as a public beta.
The details
Over the last six months we have seen persistent demand for MongoDB support on Heroku, so we are incredibly excited that MongoHQ is releasing their highly anticipated add-on into public beta today. The add-on interfaces seamlessly with their successful hosted service, and allows developers to use MongoDB as a first-class-citizen data store in any of their Heroku apps. Using it is just as easy as you’ve come to expect from Heroku: simply add the add-on, and you’re good to go!
The first available plan is free and includes one database up to 16MB. Soon, you will have your pick of the full range of MongoHQ plans.
Getting Started
Add the add-on to your app:
$ heroku addons:add mongohq:free
This will create a fresh new MongoHQ database for you and set the proper environment variable in your app. Follow the detailed instructions in our MongoHQ docs page for specifics on using MongoDB in your app.
Transferring data in/out
Since MongoDB isn’t a SQL database, taps won’t work. Luckily Pedro has created a Heroku client plugin that offers you push/pull functionality to a MongoDB. If you have MongoDB running locally on your development machine, with this plugin you can easily push and pull data just like with taps.
If you have any questions using the MongoHQ add-on, or any Heroku add-on, our support staff is available.
The response to yesterday’s Node.js announcement continues to be absolutely amazing.
First and foremost, we’re thrilled to see the community share our excitement about Node.js and its potential on the Heroku platform.
We do, however, also want to be mindful that we’re still in the experimental phase with this technology here. For this reason, we’re going to proceed carefully and invite testers in small batches.
So, if you don’t hear from us right away, despair not. It’ll likely take us a few weeks to get through the current list, and if you’re reading this for the first time, please don’t hesitate to register your interest at nodejs@heroku.com.
Today we’re offering experimental support for node.js to a limited set of users. We know there is a lot of demand, and will work with as many users as we can. See below for details.
A natural complement to Ruby
Yesterday we posted about how we think about the platform and make roadmap decisions. We are always looking for the next set of use cases to support, and lately we’ve been thinking about realtime apps and event-driven architectures.
Today, most Ruby apps are synchronous. By default, all I/O blocks. If you’re uploading a file, polling a service, or waiting on data, your app will be blocked. While it’s possible to fix this by meticulously eliminating all blocking I/O from your code and dependencies, and using a library such as EventMachine, it’s tedious and as Adam points out: “Libraries like eventmachine will never be truly intuitive to use, because event-driven I/O is enough of a fundamental shift that it requires deep language integration. JavaScript, it turns out, is a fundamentally event-driven language because of its origins in the browser”
Node.js is evented I/O for JavaScript, built on top of the blazingly fast V8 engine. It makes handling event-driven I/O incredibly simple, and aligns perfectly with our maniacal focus on simplicity and developer productivity. The Ruby community has quickly adopted node, and with great reason. Complimenting existing apps with node.js for components that require real-time event handling or massive concurrency is both easy and elegant – in part thanks to the availability of frameworks such as express.
Simple to use
Node fits well into our existing architecture. It’s just another runtime selectable as part of our stacks:
Open Questions
Supporting node opens many questions on the platform: how are we going to charge, what version will we support, how can I integrate it with my current apps? We’re releasing this in experimental state now to collaborate with the Node.js and Ruby communities on this. Over the next months we will work together to provide answers to all these questions and more.
How to Participate
If you want to participate and use node on an experimental basis, drop an email to nodejs@heroku.com with your email address, what you want to use Node for, and we’ll work to include you in the program.
It’s been a great first quarter for us, and it’s time for a brief update on where we are and where we’re headed.
Growth
Heroku’s growth has continued to be huge. 1,500 new apps were deployed to Heroku last week alone, and that number increases every week. Next week we will cross the 60,000 application mark.
As you can imagine, traffic is growing even more quickly, serving billions of requests per month. In fact, traffic has grown by 4x over the last four months:
Many are finding great value in the platform and paying for features and scale. Our customer count and revenue have similar growth curves.
Roadmap
Where is Heroku’s platform going next? How can you plan for our next releases or influence our direction? When we launch new features, what’s the best way to think about how they fit into our overall strategy?
Here’s how we think about our roadmap and decide on big new areas to work on: it’s all about use cases.
We started with the simplest use case: making it drop-dead easy for developers to deploy applications, and have grown into more complex ones (like multi-tier complex composite apps). We continue to try and expand the number of use cases that we provide a complete solution for.
Here’s a brief look at our historical roadmap from the perspective of expanding use cases:
Provisionless Deployment. Instant deployment with the now famous “git push heroku master” is at the heart of Heroku, enabling the basic use case: a frictionless application platform that just works.
Caching and Instant Scaling. We introduced high-speed HTTP caching built into every app, and added dynos which can be scaled up and down instantly, enabling large scale and variable scale apps.
Asynchronous Patterns. We added background processing with Delayed::Job, followed shortly by workers which can be scaled up and down just like dynos, enabling many use cases around modern asynchronous architecture.
Platform Extensibility. We launched the Add-ons system, a way to extend Heroku apps with core functionality like full-text search or memcache, and to consume external services like New Relic, Zerigo, or Sendgrid. Use cases here are literally endless. Add-ons allow the growing ecosystem of startups and established companies building cloud services to add new features to our platform – many more than we could do on our own.
Flexible Runtime. We recently introduced deployment stacks, which enable choice between multiple runtime environments.
What’s Next?
Over the next days, weeks, and months, we will release new features that continue to expand the number of use cases supported by Heroku, whether for startups or large enterprises.
You can be sure that each time we build a feature we will be maniacally focused on simplicity and developer productivity, and will always try to maintain the cohesiveness and quality of the platform.
From our core focus on developer productivity and frictionless deployment, we’ll be expanding the footprint to include areas like realtime and event-driven apps, more complex multi-tier applications, and a broader platform for deploying advanced applications. Stay tuned, and let us know where you’d like to see us go.
As apps have matured on Heroku, data sets have gotten much larger. Taps is designed to help development by providing a fast and easy way to transfer databases between local environments and Heroku. Today we launched taps 0.3 with a reworked architecture and a new set of features focused on large data sets:
- Push/Pull Specific Tables
You can now choose which tables to push and pull. Specify a regex and taps will only push or pull the tables that match. To only pull specific tables, specify a comma delimited list. For example, to pull the logs and tags tables, run this command:
heroku db:pull --tables logs,tags
- Resume Transfers
Interruptions can happen when moving large datasets. Now when you interrupt (Ctrl-C) or an error occurs, taps will dump a session file that can be used to resume the transfer:
heroku db:pull --resume-filename session_file.dat
- More Robust Schema Translation
DB operations are now 100% powered by Sequel, making taps capable of handling more varied data and schemas. - Improved Transfer Speed
Taps now uses primary keys to move large data sets with constant transfer speed regardless of table size. Taps will fall back to ‘paging’ the data (OFFSET + LIMIT) if no primary key is available.
Run “sudo gem update heroku taps” to get the new version.
Ever since we launched the current IP-based solution at $100/month in response to customer demand, we have been pursuing a cheaper and more elegant solution for SSL with custom certificates on Heroku.
Today, we’re happy to announce the public beta of a new SSL add-on that accomplishes this goal. It’s called ssl:hostname, and is priced at $20/month. This new add-on will allow you enable SSL traffic to your application on any subdomain, such as www.mydomain.com or secure.mydomain.com, using your own SSL certificate. Note that this is a paid beta, and you will be charged for using the add-on through the beta period.
Full docs are available here. You can install it via the heroku gem, or directly from the Add-ons Catalog.
Sinatra is one of our favorite frameworks at Heroku. Many of our apps use Sinatra, and Blake even works here. All this means we’re extremely excited to congratulate the Sinatra team on the 1.0 release!
You can use Sinatra 1.0 today on Heroku. It works with both the Aspen and Bamboo stacks. Simply add the gem to your .gems file, git push, and you’ll be running Sinatra 1.0!
The top open request from our recent survey has been for memcached. Memcached is a simple, fast and scalable in-memory object caching system. Dynamic web applications use memcached to store frequently used data, reducing database load. The Heroku memcached add-on is built on the NorthScale distribution of memcached (NorthScale Memcached Server) which includes an advanced, per-user security model. The service is fully managed by NorthScale – a company formed and run by leaders of the memcached open source project.
All Heroku users can use the add-on today. Read the docs for full details on getting started and add away. We’ll be using this beta period to analyze usage, determine final pricing, and collect user feedback. We are aiming for a late April full release of the add-on.
New Relic RPM is an on-demand performance management solution for web applications developed in Ruby. New Relic recently introduced an updated agent. Some of the highlights include support for Sinatra and rack apps, as well as background workers.
They also added a great Heroku feature; you can now view your backlog depth history. When a request comes in to Heroku it’s passed to your dynos to process the request. If more requests are coming in than your dynos can handle, the requests queue up. Our docs provide a more detailed overview of performance. The queue is often a sign that you need to increase your dynos or speed up your app. New Relic can now show you the peak and average queue for your app.
This screencast provides an overview of the new feature in New Relic, and some guidance on how to tell when it’s time to crank your dynos.
Heroku Apps run on a fully curated stack with everything from the front end caching to the base libraries selected and managed. Today, we’re making available an additional curated stack, with updated libraries and Ruby VMs. You now have the choice of running on the original “Aspen” stack, or using the new “Bamboo” stack. Both are first class citizens and the choice on which to use is yours to make.
With a single simple command, you can migrate existing apps back and forth between stacks, or deploy new apps to this updated stack. Best of all, as part of the new stack, you also have a choice of Ruby VM between Ruby REE 1.8.7 and Ruby MRI 1.9.1. And yes, you can run Rails 3 too!
$ heroku stack aspen-mri-1.8.6 * bamboo-ree-1.8.7 bamboo-mri-1.9.1
We’re excited about expanding the options and programs developers can deploy to Heroku. The existing Aspen stack & Ruby 1.8.6 remains fully supported; you can deploy new apps to either stack, and migrate back and forth. To get started today check out the docs.
We’re releasing the new stack as a public beta to solicit feedback from a larger audience. As a public beta, all accounts are already enabled for this feature. We look forward to hearing from you.
In December we asked our users to take a survey on how they are using Heroku. After collecting the responses, we wanted to share some of the results with the rest of our user community.
Who’s using Heroku?
No surprise, but the majority identify themselves as in the “Software Technology” industry, at 65% of the respondents. The rest of the user base is divided between many groups, from Consultancies with 9%, to the Arts & Entertainment industry with 6% and Healthcare at 2.5%. Respondents reported annual web application budgets as high as $10M/year, with over 13 spending >$100K/annually.
How are they using Heroku?
These users are building a huge range of applications, and often more than one per user:
55.6% of respondents are now or shortly deploying production applications onto Heroku.
Technologies
Respondents are at the cutting edge of cloud technology. Characteristics of these applications include thorough caching strategies, asynchronous patterns, and alternatives to traditional relational databases.
Reasons for moving to the cloud
In a strong shift from previous studies, respondents said loud and clear that agility is the #1 reason to move to the cloud. Cost, previously the #1 response, only just made it into the top 5 in this survey.
We thank all the people who took the time to fill out the survey, and hope you find the results as interesting as we do!
Gem Bundler is rapidly on its way to becoming the new community standard for managing gem dependencies in Ruby apps. Bundler is the default gem manager for Rails 3, but it will also work seamlessly with any other web framework (or no framework) since it has no dependencies itself.
Using it is as simple as creating a Gemfile in the root of your app:
source :gemcutter gem 'sinatra', '0.9.4' gem 'haml', '2.2.17'
…and running “bundle install” at the command line, which sets up all of your gems.
Yehuda Katz has a writeup on using bundler that outlines various scenarios for using bundler.
Heroku now has native support for gem bundler. If you push up a repo that has a Gemfile in its root, the slug compiler will bundle your gems automatically. (You can use this in addition to, or instead of, the .gems manifest. Both will be supported for the foreseeable future, so you needn’t feel pressured to switch.) Docs here.
The Ruby community has been in need of a simple, standard, dependency-free gem dependency manager for a long time. Cheers to Yehuda Katz, Carl Lerche, and everyone else involved with bundler for delivering this elegant solution!
Note to beta users: For those who used Bundler 0.8 in beta on Heroku, you’ll need to update your application to use Bundler 0.9 before your next push. If you don’t update your Gemfile, your push will be rejected. Currently running apps will continue to run unaffected.
Getting the entire ruby stack up and running on Windows is a bit tricky. To help out the process we’ve posted a new Windows setup docs page.
This 10 minute screencast walks you through the process. It follows the outstanding instructions put together by Sarah Mei for the Ruby on Rails Workshops
You get a call from your partner that your app just hit
the front page of Digg. You’re away from your computer, and need to scale your app up now! Fire up Nezumi and dial your dynos to 12 to handle the load no problem.
Nezumi is a 3rd party iPhone app that allows you to perform almost any of the functions that the CLI supports, from restarting your app, changing your dynos and workers, viewing logs, adding collaborators, and much more. It’s available now from the iTunes store.
Marshall, the developer of Nezumi, was kind enough to provide us 5 copies of Nezumi to give away. Leave a comment below, and on Friday we’ll select 5 people from random and email you a promo code for Nezumi!
You, our customers, have given us great feedback that in some places our pricing isn’t aligned with the value we provide, and in other places our pricing is just confusing.
We want to be more transparent about how we’re thinking about pricing, so today we’re announcing our pricing philosophy, as well as the first of a series of changes: moving away from storage based pricing on our database offering.
Platform Value and Pricing Philosophy
You have told us loud and clear that the value you get from the platform is saved time and opportunity cost, shorter deployment cycles, increased agility, simplified ongoing maintenance and operations, and saved head count.
You’ve also made it clear that you don’t see much added value in the commodity components of compute, storage, and network.
Our pricing philosophy moving forward will be to price for the things that provide value, and to make compute, storage, and network effectively free (like long distance) as much as we can.
There are places where we aren’t doing a good job of this today, so we are going to make a series of changes to bring our pricing more inline with this philosophy.
Database Pricing Changes
The worst offender currently is our database pricing, so we’re going to start our changes here.
There is tremendous value in having a relational database at your fingertips that requires no administration and is always seamlessly hooked up to your app. Yet, in trying to differentiate the levels of service, we priced based on storage.
This runs counter to our belief that storage should be free, so we are altering our pricing to focus on productivity and performance, and to effectively give storage away.
Shared Database
Starting today, we are eliminating the $50 Crane plan, and allowing up to 20GB of data in our $15 Koi plan. This makes Koi a very affordable offering with great storage and high (but variable) performance.
All Crane customers will be migrated to Koi immediately (the transition is seamless and won’t require any downtime), and will get greatly increased limits and a lower cost.
Dedicated Database
For predictable performance or larger databases, we offer dedicated database plans. Starting today, we will allow up to 2TB of data across all dedicated plans.
To view the updated pricing, please visit our pricing page.
Note that these limits are for database data only – there is no filesystem on Heroku.
More to Come
This is the first in a series of changes we hope will bring our pricing more inline with the value our customers get from the platform. Stay tuned!
Last month’s featured app was FlightCaster. FlightCaster provides filght delay prediction, letting you know 6 hours in advance if your flight is delayed. Today we’ve posted their success story, along with a great video with their CEO, Jason Freedman.
Jason goes into some great details on how they use Heroku to handle their complex application, including useing a Hadoop cluster to process millions of updates. In his words, “Heroku has enabled us to deliver a world class service without having the huge management and operational overhead we would have otherwise needed.”
Watch the video below, or click on through to the whole success story. For more technical details, also check out this InfoQ article.
This month’s featured app is Best Buy IdeaX, developed by Bust Out Solutions. Best Buy IdeaX is a forum for Best Buy customers to share, rate, and discuss ideas to help make Best Buy better.
“We were very interested in running IdeaX on a cloud computing infrastructure such as Amazon EC2, but the cost of maintaining our own EC2 instances was just too high, not to mention frustrating. Heroku solves those problems for us with their solid platform infrastructure and nice user interface. We’re saving time and money, and enjoying development much more.” said Jeff Linn, Founder/CEO of Bust Out Solutions
Check out the Success Story and the live Best Buy IdeaX site.