It is no secret that CloudBees is building a Java Platform as a Service offering for release in 2011. But a lot of people who develop Java apps don’t really understand what that buys them, or how it is really any different than traditional middleware like JBoss or Spring. I thought our own running of Hudson as a Service on top of our pre-PaaS might be a good way to explain the differences.
We will look at three levels – 1. Plain vanilla Hudson, 2. Nectar, the version of Hudson for larger on premise sites, and 3. CloudBees DEV@cloud
offering which includes Hudson as a Service built on our underlying PaaS. Then we will dig down to see what is happening underneath and what role the PaaS is playing in this (sorry in advance for the length of this blog).
1. Plain vanilla Hudson – on Premise. Hudson is the leading Continuous Integration server, created by our very own Kohsuke Kawaguchi (KK), and is used in over 25,000 organizations. It uses a controller-Agent architecture that makes it simple to deploy Hudson jobs across many servers or Virtual Machines. Larger deployments will have dozens of servers dedicated to the task of running Hudson. Users must buy and deploy and maintain these servers. Hudson administrators must then manage how builds are deployed to agents. Talk with a large Hudson deployment, and they spend significant resources on this. They also have the constant problem of either not having enough servers or having too many sit idle. And if they have a large server farm they can use as a utility, they lose performance by having to reload entire workspaces.
2. Nectar – on premise . KK had formed a company, InfraDNA which recently combined with CloudBees, to help customers with larger deployments thru the ICHCI subscription offering. We have renamed this offering to Nectar – and KK has added easy VMWare scalability. The basic idea is it helps you allocate a pool of pre-configured VM's and to easily start, stop and restart them for the purpose of scaling the agents in a cl ean environment. You can read more about Hudson - VMWare Scaling.
3. CloudBees Hudson as a Service . While Nectar offers far easier scaling than Hudson, there is still the need to manage servers, VMWare, configure Nectar/Hudson and the VM’s. And you still may have too much or too little capacity. The CloudBees DEV@cloud offering of Hudson as a Service eliminates all of that overhead. New agents spin up and down as needed, and there is optimized workspace management to cache data and make agent spin-up ultra fast. There is no need to buy additional servers. No need to manage VM’s. No need to administer upgrades of Hudson or plug-ins. The savings can be quite dramatic in terms of hardware, software, maintenance, and people cost.
So, now you know about Hudson (and related plug-ins like Maven, Ant, SVN, Git, etc.) and how it can be scaled and deployed in these three environments. That background was necessary to take a look at what role the PaaS plays in scaling in a Cloud deployment.
The CloudBees PaaS is still in development, but major parts are done:
Scale DUO – Down, Up and Out . Basically starting, stopping and allocating virtual machines.
Basic Multitenanting . The ability to have multiple customer share a service. Lots of security involved here.
Metering & Billing . This is how we “buy” machines from Amazon for an hour, and then bill multitenant use by the minute.
Caching . We do some neat tricks to save Hudson workspace data to optimize the Scale DUO of agents.
Management . This is our back-end management system to assure maximum uptime and availability.
These pieces made it simple for us to make a Hudson as a Service. But they are things that most any application would want. Lower cost, unlimited scaling (Down, Up and Out), no administrative and operations overhead. Far different than traditional middleware and IT operations.
Sacha has created a chart that shows vividly what we are trying to do – basically cut out all the overhead of IT.