After the announcement of the new Celadon Cedar stack for Heroku in May and the current availability of two new deployment languages - Node.js and, surprisingly, Clojure in addition to the existing Ruby stack, InfoQ took the opportunity to speak with Adam Wiggins, the co-founder of Heroku, about this new development.
Cedar has been developed since Q1 2010 - it involved more effort than the initial Heroku platform itself - is the culmination of the many things that the Heroku team has learned and experienced not only by providing the PAAS stack but also by running more and more of their own infrastructure on top of the Heroku stack.
We'll try and summarize the very interesting discussion in this article:
Adam wrote two blog posts this year which underline the current development at Heroku. The first one in April was about Ephemeralization: “the ability of technological advancement to do ‘more and more with less and less until eventually you can do everything with nothing’.” (Wikipedia). According to Adam, this is one of the goals of Heroku as a PAAS provider. To create a cloud operating system, that, like any other operating system, frees you from the actual details on how and where to run your processes (services) and how to handle their resources, scheduling, updates and availability. So you don't care where on the cloud fabric your components of your application run, how they are scaled, deployed or migrated.
Interestingly, Heroku tries more and more to remove custom built components from their stack and replace them with the proven toolbox on the operating system and library level, both of which are powerful on their own and even more so when combined in lots of different ways. "The beauty of Unix: you can achieve quite a lot with a combination of a few sharp tools."
One example is reusing the operating system mechanics of system level services also for web-applications and their associated workers. After having served dynos and workers on their own stack for quite some time, it became obvious that they are not so different and also not very different to the typical system level processes. Using a tool like foreman, which allows taking process descriptions (Procfile) and turning them into an arbitrary system level services (like Upstart on Ubuntu) make it easy to define web-apps and workers as well as specialized processes like scheduled, high or low priority processes, etc.
Example Procfiles:
# clojure web: lein run -m demo.web # node.js web: node web.js # ruby web: bundle exec ruby web.rb -p $PORT fastworker: QUEUE=urgent bundle exec rake resque:work slowworker: QUEUE=* bundle exec rake resque:work clock: bundle exec clockwork clock.rb tweetscan: bundle exec ruby tweetscan.rb
Adam hinted that in the future it might even be possible to run services (which are currently provided externally by Add-On-Providers) as those processes. The challenge there is handling their different protocols (if they are not running a HTTP based one).
Using this process approach also allows a much easier integration of other languages, you just run their appropriate execution environments (like the JVM for Clojure or node for Node.js) as a process. This makes it also easy for Heroku to add new deployment languages on the Cedar stack. There are some languages (like, for instance, Python) in private beta now and will be released in the not so far future.
If you enable a powerful mechanism like running your own processes you should also put that power in a protected environment. Heroku employs subvirtualization with LXC (Linux Containers) and chrooted jails to create that environment.
Using git as deployment mechanism is another sign of Ephemeralization at Heroku. Using available, mostly open-source, power-tools that are best suited for a certain task frees you from writing and maintaining your own solution.
Heroku not only built on top of open source tools (e.g. Ubuntu, PostgreSQL, Ruby, RabbitMQ, Memcached, Beanstalkd, Nginx) but also provides back to the open-source community. Either by releasing pieces of the infrastructure as open source - like Logplex, Doozer, Pulse, WAL-E, and Taps. Or by their developers either creating or contributing to many open source projects like Rails, Chef, RabbitMQ, Sinatra, Gem Bundler, Ring, RestClient, Beanstalkd.
The same goes for higher level libraries as dependency managment with bundler or the discontinuation of a custom for of Ruby on Rails.
When discussing the execution environment of Clojure, Adam pointed out that it is just a stock OpenJDK running as process for the clojure applications. He also stressed the fact that although the ability to run any language environment in this way regardless of being a virtual machine or not, the JVM still provides some unique advantages for language designers that allows them to focus on the details of their language without having to care (too much) about the lower level details of the execution platform.
Regarding Clojure itself:
We chose Clojure as the third officially-supported language because, as a functional programming language and a Lisp, it adds the capability for new types of apps and new use cases for developers on our platform. It was also a natural choice because we use and love Clojure for ourselves, we participate in the Clojure community.
The vision for the future of Heroku is that more and more of Heroku's services will also run on the stack itself while only a small (custom) kernel provides the PAAS environment. Some things on his wish-list are: support for even more deployment languages and major improvements in the log analysis/alerting facilities (partially available now via log-drains). Another interesting topic that is being watched at Heroku is the emergence of gems/libraries for auto-scaling. This is a difficult topic which will mainly resolve around the developer being able to set criteria and actions for auto-scaling.
The ultimate goal of Heroku is to remove the need for developers to think about servers, routers, application deployments or upgrades and other sysadmin details and focus on the actual domain-level application development.
Asked for mobile development - Adam said that many mobile developers used Heroku as backend solution because it was so easy to get a service up and running. There is no concrete focus on mobile development at Heroku but when being asked about Objective-C as deployment language, he answered that that would indeed be an interesting option.
We also used the opportunity to ask Adam about the new Chief Scientist of Heroku Yukihiro "Matz" Matsumoto:
We're are really thrilled to have Matz working with us. He'll be working full time on what he does best: continuing to improving Ruby. Ruby's aesthetic and ease-of-use have been very inspirational for us in building the Heroku platform. We're delighted to be able to give back to the core of the Ruby language.
Finishing the discussion, we talked about the Salesforce acquisition, how it affected the Heroku operations and which current and future synergies he sees from that. Obviously Heroku stayed very autonomous having all its staff still in place and operating on its own roadmap. The main synergy between the two companies is the attraction of different audiences. Heroku focusing on developers and Salesforce on business and management. It is mostly about showing their individual audiences what possibilities the other platform provides and at the same time offering easier integration.
While talking to Adam, Amazon AWS experienced the second large outage this year which led to the question of the dependency on the underlying IaaS layer. We also rose the question for Heroku's current dependance on AWS EC2 as sole IaaS provider, especially in the larger context of SalesForce as a company.
Platform-as-a-service is not yet 100% mature. When lower-level issues (e.g. hardware failures, networking failures) affect the higher-level abstraction, that's a leak in the abstraction. A year or two ago you saw this constantly. Today it's infrequent, but it still occurs. In the medium-term future, I expect it to approach being a non-issue.
We've looked at other substrates, and we've built our platform to be relatively substrate-agnostic. At the moment, AWS offers the best combination of cost, flexibility, and robustness for a provider of our size. But we are continually evaluating other options, and won't hesitate to switch if it allows us to provide better service.