CloudBees Acquire InfraDNA
JAXenter gets the low-down on the acquisition, from CloudBees CEO Sacha Labourey.
Born in Neuchâtel, Switzerland, in 1975, Sacha Labourey is an entrepreneur specialized in information technologies. He is the founder and CEO of Cloud Bees, Inc., a startup in the fast growing cloud computing market. He is also advisor and investor in several other ventures, including eXo Platform and Wallix. In 2003, Sacha Labourey founded JBoss’ European headquarters and, as General Manager for Europe, led the strategy and partnerships that helped fuel the company’s growth. While in this position, he led the recruitment of some of JBoss key talents and acquisition of key technology. In 2005, he was appointed CTO of JBoss, Inc. and as such, oversaw all of JBoss engineering. In June 2006, JBoss, Inc. was acquired by Red Hat (NYSE:RHT), leader of the Linux Operating System, for $420m. After the acquisition, Sacha Labourey remained JBoss CTO and played a crucial role in integrating and productizing JBoss software with Red Hat offerings. In 2007, Sacha became co-General Manager of Red Hat’s middleware division. He left Red Hat in April 2009. Prior to JBoss, Inc., he was the founder of Cogito Informatique, a Swiss IT consulting firm. Sacha Labourey holds a Master.
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 DEV@cloud 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.