CloudBees Acquire InfraDNA
JAXenter gets the low-down on the acquisition, from CloudBees CEO Sacha Labourey.
Java cloud computing company CloudBees have announced the acquisition of InfraDNA, but what does this mean for CloudBees customers? JAXenter spoke to CloudBees CEO Sacha Labourey, to find out………
JAXenter: How will CloudBees’ acquisition of InfraDNA affect CloudBees customers?
Sacha Labourey: CloudBees customers will now be able to choose between an on-premise version of Hudson, called Nectar, a cloud-based version as part of our [email protected] offering as well as a mixed scenario where they can deploy their core Hudson infrastructure on-premise while at the same time leveraging the cloud to handle peak-loads. This is really the best of both worlds.
JAXenter: You’re releasing Nectar 1.0 – what is the Nectar product?
Sacha Labourey: Nectar is our productized, on-premise version of Hudson. It features a regular release cycle with backward compatible patches that satisfies the need of IT operations as well as a set of features not included in the FOSS version of Hudson. It is more ideal for large and sophisticated Hudson users, as it runs on premise and is available as a subscription offering that includes value-added plug-ins for extended capabilities such as security, manageability and improved transparency and visibility into the development process. Enhanced features in Nectar 1.0 include:
- VMware Virtual Machine auto configuration and deployment for on-premise scalability;
- Enhanced backup services;
- Pre-bundled and configured plug-ins
- Auto-update service
JAXenter: In your experience, what is the current attitudes of companies, when it comes to hosting their code in the cloud?
Sacha Labourey: As I blogged, most developers are ready to do so. They understand that a good chunk of their IP and sensitive information is already in some way shape or form stored in the cloud, so they are pragmatic about it. IT Operations on the other hand tend to react negatively to this idea initially, that doesn’t seem intuitively “right” to them. Yet, while they are cautious about storing their code in the cloud, they don’t realize that, while they are publicly traded companies, they already store their entire sales pipeline, customers and prospects list and competitive information at Salesforce.com. It is time for a long due wake-up call.
JAXenter: CloudBees recently added a build-timeout plugin. What functionality does this bring to the CloudBees experience?
Sacha Labourey: Several customers voiced concern that they were worried about what happens to their money when a build gets stuck. It was for this reason that we developed a build-timeout plugin, which lets customers specify elastic timeouts, i.e., timeouts as percentages of good builds. With CloudBees, since you get as many resources as you wish, a lagging test suite will simply keep “running” while other jobs execute in parallel on other fresh machines. When resources seem unlimited, it is good practice to put in place tools to prevent waste. This elasticity allows stricter timeouts that still accommodate natural growth in build times as tests or modules are added.