CloudBees, the Java PaaS provider founded in 2010, today went live with the PaaS offering targeted at enterprise Java developers. Unlike few other PaaS providers, CloudBees doesn’t restrict developers on their platform. Moreover, unlike VMForce, CloudBees platform can be used by both Java EE and Spring Developers. Their platform service has an IDE component and a runtime component. They split it up into two offerings:
- DEV@cloud – It is a fully integrated development environment available as SaaS for developers. The most interesting part of this offering is the integration of Hudson based continuous integration solution (I will later explain why this is important). It also comes with private and secure Git and SVN repos as well as Maven repo. It is priced at an affordable level for developers with a usage based fee for Hudson agent
- RUN@cloud – This is their planned PaaS offering expected to be available in January, 2011. This is where today’s news comes into picture. Stax Networks offers platform services on top of Amazon EC2 for Java EE developers. By picking up Stax Networks, CloudBees is well positioned to build a more robust Java PaaS offering
When I wrote about them in December, their Run@Cloud was not available as GA and their acquisition of Stax Networks was seen as an attempt to accelerate the development of Run@Cloud. With the CloudBees Platform, customers handle their entire application lifecycle in the cloud, from development to deployment without bothering about issues like scaling.
Their Dev@Cloud has been used by over 500 customers and it is based on Jenkins Continuous Integration Server (formerly called as Hudson Continuous Integration Server). Run@Cloud, which is based on Stax Networks’s application platform, has been used by over 3,500 developers who have run more than 21,000 application deployments. While DEV@cloud and RUN@cloud are optimized as an integrated platform, they can be used independent of each other. DEV@cloud and RUN@cloud are based on open source software and open standards like Java EE, so that developers can use their existing expertise and seamlessly move to the cloud.
Some of the key features of the platform are
- It can scale down, up or out
- Multi-tenant
- Caching
- Robust Management console
- Metered billing
- IaaS agnostic, support for multiple cloud infrastructures
Regular readers of this blog know that I am also pushing the theme “PaaS is the Future of Cloud Services“. Cloudbees is preparing for such a future keeping an eye on the enterprise developers. More importantly, they have plans to support multiple languages in the future and it sounds great for such a PaaSy future. If you are someone monitoring the PaaS space, CloudBees should be on your radar.
Related articles
- CloudBees’ Java Dream Team Lands $4M From Matrix Partners (nytimes.com)
- Matrix Leads $4M Deal for CloudBees (xconomy.com)
- The cloud according to CloudBees (nofluffjuststuff.com)
- Java cloud fluffer lands Hudson build brain (go.theregister.com)
- CloudBees’ Java dream team lands $4M from Matrix Partners (venturebeat.com)
- CloudBees launches Java cloud (infoworld.com)
- CloudBees Raises $4 Million From Matrix Partners For Java Cloud Computing Play (techcrunchit.com)
- CloudBees Gets Stax (xconomy.com)
- CloudBees Acquires Java Platform-as-a-Service Company Stax Networks (techcrunchit.com)
- A new run at the Java PaaS – CloudBees buys Stax – Brief Note (enterpriseirregulars.com)
I don’t get “PaaS is The Future of Cloud Services”.
Are you saying that all Cloud Services should be PaaS offerings or that all Cloud Services will be deployed or integrated into PaaS environments?
PaaS in which its centered around application deployments into a completely locked down & vendor controlled (in terms of options and offerings) environment is likely to die off pretty quickly once the enterprise starts to do anything of real meaning & complexity. How many more consoles can IT handle?
The “Platform” is the cloud which should be defined in terms of contractual (& quality controlled) service interactions and flows across & up/down the entire service supply chain – a chain that is largely open for integration and extension which PaaS is never likely to be in the practical sense.
I see most PaaS as expensive and limiting public phone booths. I’ll pass on this one.
http://blog.cloudbees.com/2011/01/java-in-cloud-amazon-joins-party.html#comments
I didn’t really mean either of them. I am only arguing that more and more developers will move towards platform services (it can be Heroku model or AWS Beanstalk model) and IaaS will slowly lose its shine. I don’t necessarily agree with you that PaaS implies lock-in. I can take the same code I use at Heroku platform and run it on AWS. I guess I could do the same with Cloudbees. I do agree that some PaaS vendors try to lock you in but I wouldn’t generalize it.
On a side note, we lock ourselves in the moment we choose our programming language. The idea is how one can mitigate any possible lockin issues while trying to take advantage of what PaaS offers.