CloudBees introduces Hudson-as-a-Service
CloudBees introduces it's fist PaaS offering, Haas (Husdon-as-a-Service), that liberates the continuous building and testing of projects into the cloud. By utilizing elastic server resources in the cloud "as needed" workloads needed to building projects can be better assign, resulting in reduced build times. CloudBees HaaS works with existing GIT or SVN repsoitories, or CloudBees can provide you with a private and secure SVN or GIT repository, as well as a Maven repository.
Underpinning the HaaS, is CloudBees PaaS infrastructure. As they themselves put it:
At CloudBees we think the cloud is the new platform, where applications will shift to over time, lowering hardware and IT costs. Yet, for this to happen en masse, true cloud-native infrastructure has to be available.
With this in mind, they have build up a set of goals that the PaaS needs to include, these are:
- IaaS-agnostic - by supporting multiple vendors in a custom transparent way
- Open - leverage open, standardized, and free/open source technologies, including data formats
- Friction-less - focus of making application development easier, and reducing all other overhead associated with the development, including constant scale-DUO (scale-down, scale-up, scale-out)
- Real application - remove restrictions and limitations that prevent "real" applications from being deployed in the cloud
Their initial HaaS takes advantage of all these features, and plans on leveraging more of these features as new services and new features to HaaS are introduced.
InfoQ spoke to Sacha Labourey, CEO and Founder of CloudBees, who was able to answer a few additonal questions:
Taking the approach of leading a company with CI is a rather bold move, how did you come to this decision?
CloudBees aims at providing a cloud platform that covers the entire application lifecycle, from development to production and maintenance, through staging and QA. Consequently, starting from the CI angle makes a lot of sense since, on one hand, it really solves a pain point most development teams face (i.e. you never have enough capacity for your CI jobs) and on the other hand it has no impact on your current runtime environment - which is typically a domain where decisions are much more strategic and take a longer time.
So we will first solve a typical IT pain point by providing an AS-agnostic SaaS for developers that comes with very little constraints and build our PaaS from there. Once our PaaS will be ready, our customers will have an easy way to test their application on CloudBees RUN@cloud: since their application will already be built and tested there, it will be easy for us to automatically determine whether their applications is are compatible with CloudBees.
Also, CloudBees HaaS leverages our PaaS subsystems (such as our provisioning engine) and consequently our SaaS is really our first PaaS customer.
Can you list some of the deployment technologies you are looking to supported (i.e. which nosql, rdbs, web servers, etc.)?
Let's split the Java platform itself from its resources. The Java platform will provide all typical services you'd expect from a quality EE environment but with no notion of specific "web server" VM or "App server" VM, etc. We will provide a fully virtualized Java platform that offers those services in an integrated manner: you won't have to define how many nodes of a specific type you need. We want our platform to be free of friction less, it will handle all typical IT matters for you: from scalability (clustering) to high-availability, through transparent upgrades, etc. You focus on your application, we will do the rest.
What provisions are in place to secure data in the multi-tenant infrastructure?
Our first implementation will be mostly based on process-isolation (and well-known OS techniques to guarantee isolation between users and processes) but we are also evaluating an in-process multi-tenant infrastructure that could lead to increased resource efficiency. This will be an iterative process. Yet we do measure how critical this aspect is and it is really at the core of our design. For data, we follow best practices and want all tenant-specific data at rest to be encrypted.
Can you expand more on your constant-scale-DUO infrastructure and features?
What we call "Scale-DUO" (as in Scale -Down, -Up, -Out) is our platform ability to dynamically allocate more resources at a pretty fine level - to satisfy the current load. To make an analogy, this is very similar to what you get from your electricity provider: when you plug a device, you simply get the power you need, not less, not more and you pay as you go. To pursue this analogy, in today's IT, you would need to tell your provider weeks in advance how much electricity you need, for what kind of device, and would probably have to buy it in 10,000 Watts increments. If we want our development to become more agile and less dependent on heavy IT processes, we will have to do much better than this.
Can you share some thoughts on how you foresee companies transitioning from a service-based Hudson to a completely cloud-based development infrastructure? This is clearly a larger step that simply provisioning VMs to be used.
There is no need for this transition to happen as a single step. Companies will first look at ways to eliminate their biggest pain points, one after the other, and the cloud will probably offer the best solution for most of those issues. And once key parts of the development process will happen in the cloud, it will just be a matter of time until companies move the remaining parts in the cloud in order to have a unified development bus. But this cannot be a forced transition it will happen over time, with assets split on both sides of the fence for quite some time. That's why at CloudBees, while we offer a fully integrated environment, each and every piece can also work independently and hook into 3rd party systems (on-premise or in the cloud).
How are you looking to support automated testing? A on-demand selenium grid, seems to be a perfect fit and a missing piece in the development to production transition you've outlined in the vision.
That is correct; our current offering is a great foundation on top of which we will start offering new services over time. We already have some pretty specific ideas about what our next services should be. For each of those additional services, we will decide whether we implement this internally or whether we partner with an existing player.
Can you outline how your own development / process has improved by utilizing CloudBees?
Our entire development process takes place on-line. Since we started from scratch, we started using GitHub services and, once our CI was ready, started using it. We are very close from being able to instantiate a complete cloudified CloudBees staging environment (HaaS, PaaS provisioning, billing&payment, forges, etc.) in a clean Amazon account through our HaaS, straight from our code repositories. We are clearly an IT-less company, we do not own any server and entirely rely on SaaS services for both engineering and business (salesforce.com, Loopfuse, Zendesk, PagerDuty, etc.)
For more information on the CloudBees Haas offering, and to find out more about their upcoming PaaS features, the web site address is www.cloudbees.com.
Cloud could be the new development environment
MikeCI is another example of cloud CI services which offers a true multi tenant service in a sense that you pay $10 per month instead of paying your monthly fee and then paying per minute.
By the looks of things if you want to use Hudson in the cloud it might be worth installing the plugin. If you want an affordable scalable solution then choose a multi tenant service like MikeCI.
Re: Cloud could be the new development environment
Concerning MikeCI, as far as I can tell it doesn't expose Hudson, which is what interests people in our opinion (to install existing plugins, etc.) As for "affordable", I guess its definition might be different based on how important CI is for you.
Laurie Williams and Catherine Louis Nov 28, 2014
Edmund Jorgensen Nov 27, 2014
Lisa Adkins and Michael Spayd Nov 27, 2014