Sacha Labourey, the CEO of Cloudbees and former CTO of JBoss, was recently in Lausanne to present the Cloudbees platform to the Lausanne Java User Group. Cloudbees is a platform that allows to develop and run Java (or more precisely JVM-based language) software in the cloud. The company has been famous for hiring recently Kohsuke Kawaguchi, the creator of Jenkins (or “the software formerly known as Hudson” as Prince would say).
Sacha started with a presentation of the Cloud, giving definitions of the famous IaaS, PaaS and Saas acronyms that represent the Infrastructure, Platform or Software as a service markets. In the PaaS segment where Cloudbees locates itself, he mentioned that there was a lot of difference between the PaaS solutions. Some are very close to an infrastructure, like Microsoft’s Azure, and other are closer to a software vision of the Cloud, as the Google App Engine. Another way to differentiate the competition is to assess the flexibility of the platform: what constraints are imposed to run your software on the Cloud? You have to remember that some of these restrictions might exist because the supplier has a “free” offer and wants therefore to limit the resources that customers are allowed to use.
The basic goal of Cloudbees is to provide “frictionless development”. In most large organizations, there is a divide between the developers and the IT operation people. Cloudbees aims to provide the operation parts of Java platforms to developers, giving a transparent and instantaneous access to runtime resources. There will be no more need to ask (and more importantly wait) for installation of new hardware or another database before to deploy your application. Everything should be as simple as pushing a button to deploy your apps. You will then pay for the exact resources you use without restrictions. It is naturally not always as simple as that, but the objective is to establish this situation for a majority of the applications.
The Cloudbees offer is currently divided in two parts:
* DEV@cloud is an environment where you develop and build software in the Cloud
* RUN@cloud is runtime environment to deploy applications in the Cloud
Cloudbees has been created recently and employ around 25 persons around the world. It follows the same model than JBoss with a distributed organization and the goal to push expansion through developer’s adoption of its continuously enhanced solutions. Currently there are around 1800 accounts and 4500 applications running on the platform. You can open a free account on https://grandcentral.cloudbees.com/subscription/plans
The DEV@cloud is based on the continuous integration capabilities of Jenkins and is opening to external solutions, as it was the case recently with Sonar for continuous inspection of project quality. The RUN@cloud provides currently a Tomcat and MySQL-based environment for applications. Although Java is the main language targeted, all other JVM-based applications (Grails, JRuby, ColdFusion, Scala) can be hosted by the platform. The capabilities are constantly improved as the development team work on new issues. For instance access to NoSQL databases should be possible in a near future.
Finally, Sacha ended his presentation with a demonstration that showed interaction with the DEV@cloud and the RUN@cloud part of the Cloudbees platform. He started with a simple command line example followed by the activation of the platform through a GitHub push and using Eclipse.
The questions from the audience put in perspective some of the issues related to running applications in the Cloud. As we were in Switzerland, security and privacy were the first topic mentioned. Sacha answered that some of the companies asking these questions seem to forget that they have already all their customer data on salesforce.com. However, Cloudbees recognized that this was a concern and has started offering its solution for private clouds.
Supplier failure was another topic, as the recent Amazon outage reminded it to some customers. Cloudbees has currently Amazon as its unique infrastructure supplier, but it aims to share its infrastructure between different companies to enhance service continuity, even if the management of a multi-supplier infrastructure has its share of technological challenges. We should also not forget that the average downtime of major infrastructure like Amazon or Google is often better than inside capabilities, but when they fail they make the news headline.
There was also an interesting discussion about the issues with multi-supplier SaaS configurations. If you want to host your application on Amazon but use the MongoDB service supplied by another company, you might have the risk of latency problems between your application and your database if they are located in different datacenters. You are therefore restricted to you choices not only by technology, but also by geographical location. Even if your SaaS vendor is using the same supplier, Cloud infrastructure providers are not very keen to give you information on where exactly your application is running, which is kind of normal as this is what the concept of the “Cloud” is all about.
Pingback: Sacha Labourey Discusses Java in the Cloud