A short while ago Heroku [1] announced support for Scala using the Typesafe [2] stack. Two weeks ago Typesafe extended their stack with Play! [3], a simple to use web framework, and here Scott Clasen, Engineer at Heroku explains [4]how they came to partner with Typesafe to support the stack, Scala, Play! and Akka, on Heroku.
Scott:
I came to Heroku in spring of 2011. There I learned that they had been working on a vision for something they called 'polyglot platform'. The thesis was that development and deployment workflows were similar or even identical across most languages. After Salesforce, an organization with tons of Java talent, acquired Heroku, Jesper Joergensen and I were the first of a small team to move over to Heroku. We were tasked with building out the support for Java as quickly as possible. While doing that, being a big fan of Scala, I got Scala support using SBT 0.7 working on Heroku and thought it would be really great thing if Heroku could officially support Scala too. It was right around this time that Typesafe had its public launch.
At that time, the Java piece of our strategy was very secret so I had to get buy in from Adam and Oren (Heroku co-founder & CTO Adam Wiggins and COO Oren Teich) that we should support Scala, and also explore a relationship with Typesafe. They quickly saw the strategic importance gave me their blessing and the mandate to get it done. Timing was perfect, ScalaDays 2011 was just around the corner. Being a minor committer on Akka, I knew Jonas and Viktor, and thought the conference would be a great place to get the ball rolling by discussing potential synergy between Heroku and Typesafe. Things went quickly. The Monday following ScalaDays, Martin Odersky and the rest of the team came over to Heroku, talked a lot about visions for cloud computing with Adam, and soon the benefits of a partnership became obvious to us all. We got down to working out the details of how we could make it all happen.
Separately we had been targeting Play for first class support on Heroku, because Play really embodies the progressive type of technology that Heroku embraces, and seemed like a great fit. We were in communication with the Play team, and knew that they were in talks with someone to partner with, but we didn't know who. I guessed that it might be Typesafe, since both Typesafe and Play represent the progressive vanguard of JVM development, and it seemed like an ideal fit. We were very excited to find out that was in fact the case.
Scott:
No it turned out to be relatively straight forward. The Cedar stack, Heroku’s third architectural iteration, was designed from the ground up to support multiple languages. The whole focus had been on simplicity for the developer, reducing the work they needed to do to get things done and getting the clutter out the way to create a great development experience. Supporting a specific language or framework on the cedar stack is just a matter of creating a buildpack A buildpack is a bit of code that is the adapter between the general-purpose Heroku runtime, and the specific language. So I'm the Scala Buildpack Owner at Heroku. Here's the source code for the Scala buildpack [5].
Heroku Java support is based on Maven, so naturally the Maven Scala plug-in provides a simple way to push Scala projects. Alternatively you can use SBT support.
On being pushed a given a project Heroku detects the correct buildpack to use. If Heroku detects an sbt project, 'sbt clean compile stage' will be run, where ‘stage’ is an sbt convention that means ‘prepare the project to run in place’.
We worked closely with Mark Harrah, SBT creator and Havoc Pennington of Typesafe on this project. Behind the scenes, Typesafe put out the xsbt-start-script-plugin. It adds a ‘stage’ task that creates a start script which sets up the application classpath so that one or many main-class(es) can be easily executed with the correct classpath. This means that any application -- Akka, Jetty, and so on -- that you can bootstrap through a main class will run on Heroku. You are not constrained to Tomcat or any other server specific tools.
Scott:
The application is expressed through the dependency management tool, not just code dependencies but server dependencies too. You can specify a particular Jetty or Tomcat release to use, for example. This means you can upgrade to a patched version when you need to fix a critical bug and not be dependent on the cloud service being upgraded generally. You just change your SBT or Maven build and push the new version of the app. A Heroku Procfile has a manifest of the types of processes you have in your app, web, batch, workers, etc and the path of the executable to run for the given process type. This all gives the developer a lot of control over their deployment environment and consequentially leads to more robust applications.
Scaling is simple too. At the Heroku command line you just specify the number instances of a given process type in the app you want running. Type ‘heroku scale web=10’ and you get 10 instances of your web process with ten times the throughput. In the same way it is really easy to scale out other dependent processes too. Under the hood it is all managed through a Rest API. For example you can do scaling of Akka workers manually from the command line but it is equally possible for the developer to establish an auto-scaling policy in the application and dynamically call the API to increase resources under load. For example, there are a full set of metrics available on messages, latencies, etc in Akka, to allow a range of scaling policies to be implemented. A web site business manager can decide what is the right quality-of-service vs. cost trade off and know it's simple for a developer to implement it.
Scott:
I had been really pleasantly surprised by how easy Play is to use. After doing heavy-weight Java web development for many years using Play almost feels like cheating. You code, hit reload and there it is running the changes in the browser. No rebuilds, no redeploy, restarting servers, none of that. No fuss. What more can you want? I’ve lost some of my Ruby-on-Rails envy, Play is slick and you get all the static type safety too.
It's really a joy to use and easy to get started. There are simple to follow tutorials and pre-canned examples that get your first app running fast. You only need to add a Proc-file to the standard Play app, commit it into Git, run the ‘heroku create --stack cedar’ with the command line tool, and ‘git push heroku master’ and you are up and running. That's' it. From there you can iteratively modify the app, and just ‘git push heroku master’ whenever you want, very agile.
Play! 2.0 supports both languages fully. If you have experience in Java or Scala, Play is really easy and natural. You can make rapid changes, do quick iterations and just get started fast. No messing with tons of boilerplate config, Spring context files, getting a Maven or sbt build up and working, adding your initial set of dependencies, Play has none of that, so it is a much nicer experience. Java programmers will love it.
Using Scala gives you a big productivity boost. Much less boilerplate and much more concise and expressive. The really nice thing is that as a Java developer you can start using Play with Java and move to Scala when and if you want to.
We are working hard with the Typesafe and Play folks to make sure that Akka 2.0 and Play! 2.0 will run as simply and cleanly as possible. Using Play and Akka on Heroku will be a super experience. You can start small then scale to any size as you grow. We provide the first 'dyno', the unit of resource use, for free. Any developer can freely try their web business ideas with the security that it will scale out to any size as they grow with no change, no migration, no worries.
Scott:
For a number of years I have been a big Java enterprise guy watching Scala because I thought it had a huge potential. I got seriously interested about a year and a half ago. There were a lot of open source folks I respected, like James Strachan and Hiram Chirino, and all of a sudden all of their stuff on github was Scala. All their new stuff was being written in Scala. Having guys I respect going that way meant it was time for me to spend some more serious amounts of time investigating Scala hands-on. I started small, doing some open source projects using Scala, first by translating a Java project into Scala in an idiomatic Java style. While doing that I learned more about Scala and how to write in a more idomatic Scala style. If you want to learn Scala its going to take some effort, it takes some time to fully understand. But it is really worth it. You can learn from the community experts, follow open source projects, look at code or try to make minor patches, Then it all clicks and you find yourself writing idiomatic Scala.
This was my introduction to the community. Once I got a feel of what was going on, I was really interested in Akka, so I contributed some code, and ended up becoming an Akka committer. Akka is an exciting project and a key piece of the Scala community. I felt privileged to be working with all those brilliant guys.
After working with Scala for a few months it was very jarring to go back to Java. Now I have done the context switch more and more it is much easier. But once you've taken the initial dive into Scala it's really jarring to go back to Java for the first time.
Now I just use Scala whenever possible.
Scott:
Over time I think yes it could be. But Scala is a sharper tool than Java, much more expressive but you can also cut yourself more easily. Evaluate the team you have, their comfort with new technology, the existing code base size in Java. If you have a top notch, progressive team then Scala will be a good choice. They will love it and be much more productive. It isn’t right for every team or organization though, and that is ok. On a personal basis Scala is just fun to use and broadens the way you think.
Scott:
One way to get started is to follow some getting started guides:
Developers can also clone some of the Scala & Play demos apps on Heroku by visiting:
Links:
[1] http://www.heroku.com/
[2] http://www.typesafe.com/
[3] http://www.playframework.org/
[4] http://www.scala-lang.org/node/11761
[5] https://github.com/heroku/heroku-buildpack-scala
[6] http://devcenter.heroku.com/articles/scala
[7] http://devcenter.heroku.com/articles/play
[8] https://github.com/playframework/Play20/wiki/ProductionHeroku
[9] http://scala.herokuapp.com
[10] http://playframework.herokuapp.com