If they supported git pushing a war file, then I wonder what the performance improvements would be with Warble-ing a RoR app and running it on a JVM?
Edit
Oh wait, they already did. But not using a WAR file it seems.
For example, JRuby is one of the most frequently-requested languages on Heroku. Matthew Rodley has already put a Rails app onto JRuby on Heroku by adding JRuby to pom.xml. Scala, another common request, could be done the same way. We do look forward to being able to offer the same kind of first-class support for JRuby and Scala that we offer for Clojure; but in the meantime, bootstrapping via Java is a reasonable strategy.
Now if we could just get some performance comparisons between the Ruby and Java platforms on Heroku... pretty please?
try dyno-blitzer https://github.com/pcapr/dyno-blitzer which scales up dynos, runs a load test and tells you how many dynos you'll need to support x concurrent users.
That's not what I mean. That will make it run with concurrent threads per request. However, I'm fairly certain it isn't threadsafe.
Somewhere around 3.0.6 I made a simple jruby rails app and a sinatra app. They were both a thin REST layer over data in mongodb (No AR). I did load testing and the sinatra app ran fine, the rails app would fail on about 7% of requests with seemingly random stack traces. When I reran the tests with config.threadsafe! turned OFF it never failed.
Also, on Bob Lee's OSCON talk he mentioned some unthreadsafe code in AR that he found.
I've had good experiences with several jruby on rails apps under tomcat using warbler and they all seem to perform fine with config.threadsafe! enabled. You should probably investigate those stacktraces, maybe they were caused by unthreadsafe gems or application code?
Wonderful news. Heroku keeps going from strength to strength. I know a lot of people who'll be interested in this... I'm very pleased that Scala is deployable.
You do have to wonder what the moves of the last few weeks mean for DotCloud. With Heroku launching support for many non-RoR languages and CloudFoundry being adopted by other PaaS players, you have to wonder whether small players like DotCloud are going to get squeezed out.
As far as I understood it, it's apples and oranges. DotCloud provides specific services, for example, running a Solr cluster, which is a higher level of abstraction really than providing support for a specific programming language.
I don't. Besides Heroku is supported by salesforce.com, so there's at least some longevity and synergy between the two.
Also, not all PaaS players will commoditize over the same feature-set. Example in point, Heroku's Java support doesn't allow you to put a .war file up like you can do in Amazon's Elastic Beanstalk.
Not really, Amazon web services launched Elastic Cache based on Memcache thats Dotcloud's meal. Since Amazon is mostly customer driven more the need for specific platform AWS will launch likely.
I've tried a few others. Both Dotcloud and Duostack (before the acquisition). But I always ran into one or two little sticking points or things it couldn't do or things it could do but not easily.
I keep coming back to Heroku, for both Ruby and now Clojure. (And now that their Node.js hosting isn't awful, I'd probably use it for that too if I did something in Node). It makes it so easy for me to get an app out, even with little wrinkles like needing some configuration variables that I don't want to check in to my codebase.
Google App Engine has a fairly restrictive Java implementation. It means that most libraries that you are familiar with would likely not work there. So you can't really just take a war file that works somewhere else and stick it on App Engine. They do provide a few nice built-in service like image manipulation.
The problem with services like Cloudbees and Amazon's Elastic Beanstalk is that you end up updating an entire war file that you build locally. This can take a long time.
Cloudfoundry only serves up deltas, but you still end up having to build the entire war file on your local machine ( at least for Grails ).
Heroku's approach seems much nicer, you get some initial setup pain, but then you can just use a standard git workflow.
Tomas, this is not true, at least with CloudBees you have a delta deployer that makes it a breeze to update your applications as it just sends the delta from the last upload!
> In the classic software delivery process (development → packaging → distribution → install → deployment), code passes through many hands before it finally reaches the end user. Developers build, QA verifies, ops deploys, and finally end users can access. In this environment, the feedback loop for information about how code behaves in production is slow and inefficient — it may take weeks or months for this to make it back to developers, and often in a highly-filtered format.
> Heroku is built for the new era of software-as-a-service. An app is built by a small, cross-functional, relatively independent team which builds and deploys everything itself, with few or no hand-offs to other teams.
What's the difference here? Developers still build and QA still has to verify. If your code is split up into several repositories, you still want to track versions (packaging & distribution, even if a package is just a branch + revision number).
They are talking about 'cross functional' teams. So Devs/QAs/Ops can be in the same team, even the same people. Because they (Heroku) are handling all the edge-knowledge of server setup/maintenance etc.
You only need to track revision number, in a single repo (maybe with branches, sure). I'm not sure what you mean by "code split into several repositories" ?
The difference is deployments become cheap thus "delivering software" becomes cheaper.
It has to do with how quickly you can iterate on your production software and what the distance is (in terms of time) between a developer committing a change and that change making it out in front of an end-user.
In traditional enterprise software (e.g. insurance) the deployment cycles are long because the organization are large, heavily layered, and extremely resistant to change. There are many reasons for this, some sensible and some not. (And then some that are legislated - they fall into both categories).
For a startup that is trying to build a service, or a mid-sized corporation, particularly in the ecommerce space, the faster you can change a deployed solution, the better off you are.
Say you're running a large ecommerce website and a bug is discovered on the user account page. It's a "P1 issue" that needs immediate attention, i.e. as long as the bug exists, revenue is impacted.
In a situation like this, you want to be able to identify a fix, commit it, and ship it to production ASAP. This becomes an issue in traditional organizations where the "developers" are different from "the network people" who themselves are subdivided into database/network/sysadmin/etc. These groups are change-averse and tend to gate releases into maintenance windows. Which makes sense, but can hinder rapid deployment.
If you don't have a traditional Ops team, there's no stakeholder who feels you're impinging on their fiefdom when you wantonly hit the deploy button. (Though I don't mean to imply that you shouldn't have discipline around releases).
The question you're asking is very relevant for teams making the transition to processes like Agile and infrastructures like Cloud. Because these things are disruptive, they lead to change and break-down of traditional org structures. A dedicated QA department always seems to be one of the first things targeted. (Though I don't necessarily think that's a good idea).
I think you will find that even in large organizations with dedicated teams owning server ops, if a problem is impacting customers in the middle of the day, there will be a way to get the deployment window open quickly.
Doing away with maintenance windows altogether sounds great from our point of view as developers, but it shouldn't come at the expense of customers suffering horrible latency during peak hours because the servers are at reduced capacity while a significant percentage of them are busy with deployments.
I understand the benefits of rapid iteration through continuous deployment (and intensive automated testing), but cloud platforms like Heroku and Beanstalk don't really help here. Cloud deployment and the ability for developers to push a button and have their changes show up in production quickly also doesn't mean you don't need QA anymore. That's a separate decision.
I understand that making deployment a simpler process through hosted server farms is great in that it takes off a lot of pressure from your ops team, but that doesn't change the development process.
I agree, just because you have less friction with IT doesn't mean you suddenly write high quality code with no bugs.
Plug: if you are interested in Java deployment and do not anticipate to write bug-free code just yet, you might want to look at CloudBees: this is not just a production PaaS but it also provides a complete Continuous Integration SaaS based on Jenkins and many other services.
Right, the justification here is a bit blurry. The framework they present is pretty much J2EE redux. If you are going to take this angle, stick with Tomcat and its huge enterprise base. Unfortunately, this is far from reinventing Java for the web.
That has more to do with the underlying provider (Amazon) than the language hosting provider. It's a hard problem for cloud providers to solve but I'll bet you Amazon will get there sooner rather than later.
Amazon's Elastic Beanstalk is a good compromise in this regard. I've been using it to develop some JRuby/Sinatra backend services, and though it's not quite as simple as Heroku, it's pretty close. Since the applications are just EC2 instances underneath the hood, you can tweak the server image quite a bit too, which is nice when you need to run some odd binary programs along side your web application. I haven't played around with Beanstalk's autoscaling feature yet, but that might come in handy for processing background jobs that fluctuate a lot.
Don't you get that by FTP'ing your WAR to Tomcat, whether running on a dedicated server, VPS or in the Cloud, or am I missing something and overly complicating my life?
You're missing the bit where you run Tomcat on a VPS. Deploying RoR isn't much more complicated, but still infinitely more complicated than dropping it on Heroku and having it just work. Plus scaling: breaking a sweat on Heroku? Push a button. On your VPS? All kinds of trouble, just when you probably have other things on your mind.
Yeah, it's not a big one, certainly. In practice, you'll almost never do it from scratch, but use an archetype [1] that you tweak.
Tools like Ivy, Gradle and Buildr will play nicely with Maven repositories to get dependencies, and I would hazard were all largely born out of a frustration with the pom syntax. That said, like it or, more likely, not, Maven is the defacto Java standard, so it tends to cling on.
I've been hoping for this since I first used Heroku for Rails/Sinatra apps. I feel that with this change, Heroku is really getting serious about their offering (not that they weren't already).
But as someone who's worked on enterprisey stuff, the thought of push-button Spring deployment makes me giddy with glee.
Heroku folks - if you're reading this - you just achieved maximum awesome! :)
Are there times when you prefer Java EE over Spring and the like? Java EE does some things well, but it seems like lots of comparable libraries/etc are offered in the open source side of things.
Not knocking, really just curious about your opinion.
Maybe it's preference/bias but I found the latest Java EE6 offers a lot simpler programming model than its predecessor or Spring.
I also prefer to stick with 1 container as opposed to mix-n-match Spring modules + Hibernate + Apache CXF/Axis2 or whatnot. Most libraries out there boasted that they implement the JSR standard but they don't stop there as they also added their own extensions + configurations.
There are a few missing parts in Java EE: MVC and dealing with NoSQL which both will be addressed in Java EE7 from what I know. Spring has SpringMVC and SpringData so they're ahead right now.
What I don't like from Spring is the complexity of the setup (dependency, albeit Maven helps) and knowing various Spring modules and how they works with your preferred app-server. With Spring, at some point, you need to know a few key integration points between Spring and your app-server. For example: deploying an EAR solution that contains multiple WARs and JARs would require to understand Spring lifecycle, setup/configuration if you'd like to behave according to your requirement.
A plus point using Java EE6 is to trim down your EAR/WAR. Spring pulls many JARs.
That's a fair point, I guess I've been spoiled. I guess I just don't mind knowing those integration points and working with them, but I can definitely see how it would put a bad taste in your mouth after a while.
The NoSQL integration I think will be big. I know some folks using SpringData to talk to MongoDB and they've had positive experiences so far.
Maybe in the future things will get simpler - so far I've found that I'm pretty happy with either embedded Jetty or Tomcat. And then Spring/Jersey + Hibernate/JPA.
Have you found that EAR/WAR size has hampered you? I tend not to worry about how many JARs I'm pulling.
I use GF3.1 as they are the only one that implement JEE6 in full. There's an issue with deploy/undeploy app (memory leak due to pushing ClassLoader to the edge) which is kind of annoying to me personally because we do frequent build/deploy. I wish we can use Jetty (I used Jetty, Servlet, GWT in my previous company) since it is way leaner and faster to reboot; especially via Maven.
Although I've never measured the deployment performance, I'm quite sure the smaller your EAR/WAR size the faster it deploys because the ClassLoader is required to scan + load those libraries (again, it depends on the behavior of your library: up-front or lazy loading).
You definitely want to try jrebel to solve your problems with redeploys and wasting time. It'll reload your classes and resource as you compile/provide them. Check it out, http://zeroturnaround.com .
disclaimer: I work there, but jrebel is awesome anyway.
I recently moved from Glassfish back to good old Tomcat because of this classloader leak. With GF, I could typically do no more than 1-2 redeploys before having to kill -9 it. That was really painful. We found that we weren't really using many GF/JEE features that couldn't be added to Tomcat as a simple jar dependency (J2EE connection pooling was one nice built-in, but we'll use c3p0 or something similar soon). Tomcat is a breath of fresh air- starts/stops in < 4 seconds, and redeploys never hang.
It's not pretty, but it is the lowest level of abstraction. If they used a prettier example, they'd have to pick a framework and then people would complain "hey, why'd you pick X and not Y?"
Edit Oh wait, they already did. But not using a WAR file it seems.
For example, JRuby is one of the most frequently-requested languages on Heroku. Matthew Rodley has already put a Rails app onto JRuby on Heroku by adding JRuby to pom.xml. Scala, another common request, could be done the same way. We do look forward to being able to offer the same kind of first-class support for JRuby and Scala that we offer for Clojure; but in the meantime, bootstrapping via Java is a reasonable strategy.
Now if we could just get some performance comparisons between the Ruby and Java platforms on Heroku... pretty please?