CloudBees is the only cloud company focused on servicing the complete develop-to-deploy lifecycle of Java web applications in the cloud – where customers do not have to worry about servers, virtual machines or IT staff. The CloudBees platform today includes DEV@cloud, a service that lets developers take their build and test environments to the cloud, and RUN@cloud, which lets teams seamlessly deploy these applications to production on the cloud.
This is a guest blog, written by Gary Kennedy, Founder and COO, Clarus Financial Technology, London. Clarus provides services such as technology due diligence, enterprise risk architecture, central counterparty clearing, financial engineering and software development.
In football, the home team supporters energise their players by showing appreciation of good plays and creating an intimidating and distracting atmosphere for the opposing team. This advantage can be so great that is likened to having an extra player in the team, referred to as the ‘twelfth player‘ in the team.
In many traditional software companies, the development and release infrastructure is handled internally, either by a small dedicated team, or on a part-time basis by some of the experienced developers. A modern approach is to consider a Platform-as-a-Service (PaaS) to host and manage the development infrastructure, freeing resources to concentrate efforts on one’s core strength, the product. At Clarus we have used CloudBees from day one to provide source control management, continuous build management (via Jenkins), hosting databases and deploying web applications. Our experience has been very positive and over time it really feels like there is an extra member in our team completely dedicated to our infrastructure.
The decision to break from our previous experiences of internally managed infrastructure was not an easy one, we had instinctive fears around Security, Reliability and Flexibility. Without doubt the fremium model helped us get comfortable with using CloudBees, a new company we had not heard of before.
Security was the easiest hurdle to overcome, we absolutely needed to have the infrastructure accessible from outside our physical office. CloudBees had some significant customers who were already comfortable with their security protocols, moreover we reasoned that CloudBees could do as good a job as we could.
Reliability has been very impressive, whilst no service can be 100%, we have only experienced one day when CloudBees was down (a period of 3 hours). At that time we were using a free account and I could see from their support on twitter that other paying customers were down for a much shorter period of time. When we have had some technical support questions, the responses have been very quick and of high quality (even during the initial free period). Generally reliability has been significantly better than our experiences with internally managed infrastructure.
Whilst there is less freedom than internally managed infrastructure, there is certainly enough functionality to be very effective and we have not found this to be a problem at all. It certainly encourages us to follow standard processes, and we find it to be an excellent example of keeping a service simple yet effective. Furthermore, CloudBees services have grown since we first looked at it, for example one can now easily deploy releases onto amazon web services or google app engine.
CloudBees uses a fremium model. There are two main hurdles which force conversion from free to premium,
the number of minutes of build time
number of users
We hit both hurdles in the same month which I suspect is not an accident. I can imagine CloudBees are at such a scale that they can fairly accurately predict when a startup will convert.