{"id":5683,"date":"2010-12-14T11:37:45","date_gmt":"2010-12-14T17:37:45","guid":{"rendered":"http:\/\/www.redmonk.com\/cote\/2010\/12\/14\/cloudbees_stax\/"},"modified":"2010-12-14T11:37:45","modified_gmt":"2010-12-14T17:37:45","slug":"cloudbees_stax","status":"publish","type":"post","link":"https:\/\/redmonk.com\/cote\/2010\/12\/14\/cloudbees_stax\/","title":{"rendered":"A new run at the Java PaaS – CloudBees buys Stax – Brief Note"},"content":{"rendered":"

\n\"cloudbees-diagram.png\"<\/p>\n

CloudBees<\/a> has purchased Stax Networks<\/a> (see their write-up<\/a>) to build out their ambitions to become the leading Java PaaS. Thus far, CloudBees has been known as the Hudson in the cloud company, running the continuous build tool in the cloud (on Amazon) for it’s beta users. Doing a build in the cloud is one thing, but tooling all of the activities around the build-test-deploy-run-repeat cycle is a bigger pie to eat from.<\/p>\n

(As a minor note, by “Java PaaS” I mean “any VM-based language,” not just the Java language.)<\/p>\n

Cloud ALM<\/h2>\n

There are many efforts underway to do “cloud ALM” though, wisely, no one calls it that. “ALM” has long been thought of as more of a bureaucratic-hell for developers than something useful. Still, for any sane organization the checks-and-balances and quality-through-process that ALM drives towards is required. It’s one thing for some slick .com to eschew ALM, but all those Toyota owners out there probably appreciate the mounds of process paperwork that ALM and higher paper-pushing practices stocked up<\/a>.<\/p>\n

As the diagram above shows, CloudBees is looking towards Stax to help them fill out the “deploy to production” part of that cloud ALM vision. I’d suggest that this “production” (the running of the code) is the area that needs the most innovation in the cloud space and is, therefore, the most difficult nut to crack. The idea<\/i> of push button deployments to production is great, but the actual reality of deploying, diagnosing problems, rolling back, and so on get messy. And, indeed, solving those problems is (or should<\/em> be) the value that a PaaS brings.<\/p>\n

As a thought-experiment, I’d suggest that the ultimate PaaS would allow you to fire your entire ops team (as needed by the applications in that PaaS, at least) and just rely on the developers to run all that. Whether that’s a good idea or not is yet to be seen – I doubt developers want to strap a pager to their belt every night.<\/p>\n

In essence, you need “fully automated provisioning” as some of the dev\/ops crew would describe it<\/a>.<\/p>\n

It’s getting crowded<\/h2>\n

As a comparison, the Code2Cloud crew<\/a> is tackling the problem from a tools perspective, where-as folks like CloudBees are going for an approach to build and own the entire ecosystem, not just service it. Another example: you can see this general idea being worked out in the mobile space by PhoneGap\/build<\/a>. I come across “build in the cloud” folks all the time now-a-days, and I expect to see even more of vendors moving the entire software development and<\/i> deployment tool-chain into a cloud – if only “cloud-like” (CloudBees said they have an on-premise version for the weak-kneed) – environment.<\/p>\n

More<\/h2>\n