Why a PaaS? - The Hudson Use Case

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 Master-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 – (http://nectar.cloudbees.com) 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.

Comments

Post a Comment

Popular posts from this blog

Ringside Winding Down

A year ago, a group of us met in a pizza parlor to discuss how we could bring the social web to every website and business. In January, we launched Ringside Networks with seed funding from Matrix Partners, one of the best VC firms in the country. By the end of March we released into open source an initial beta of our Social Application Server – a very ambitious project. We got some very positive reviews on our approach, our implementation and the need in the marketplace for every website to become social. We were ready for our Series A round of funding, and in late May we received a number of term sheet offers from the very best VC firms. As we were about to finalize our funding, one of the biggest non-evil Internet companies asked if we would have interest in being acquired instead. After a lot of thought and debate, we decided that the larger company would enable us to get our technology to market sooner and with more impact. The story sounds almost too good to be true. And it w...
Read more

Capitalism vs. the Three Legged Stool

Image
Wikipedia defines: " Capitalism  is an  economic system  in which trade, industry and the  means of production  are controlled by private owners with the goal of making  profits  in a  market economy ." This definition has always bothered me. I prefer a different model where there is equal recognition of the three primary drivers behind the success of a company: Owners Employees Customers I like to think of it as a three legged stool, where each leg is as important as the other.  One gets too large or small and the stool tips over. The free market is supposed to take care of Employees and Customers.  Employees because the Owners will create so many jobs that due to supply and demand, employees will receive competitive pay.  Customers because if the owners are not building the right thing, then they can go elsewhere. As someone who has helped to build about 10 startup companies now, I have seen the power in mak...
Read more

Galbraith Revisited

Image
To follow up on my post from a while ago, Galbraith sited 5 key reasons for the 1929 crash and following depression: 1. The bad distribution of income. 2. The bad corporate structure. 3. The bad banking structure. 4. The dubious state of the foreign balance. 5. The poor state of economic intelligence. To compare this to today: 1. Bad income distribution. 1929 - Top 5% received about 33% of all personal income. 1929 - Top 1% held 44% of all wealth. 2000 - Top 1% received about 20% of all personal income. 2004 - Top 1% held 34% of all wealth. Here is a picture of the real income gains between 1979 and 2005 by percentage. It is clear that the top income groups are gaining ground faster than lower income groups - creating an income distribution that approaches 1929. 2. Bad corporate structure. In the 1929 era there had been a large rise in a "vast structure of holding companies and investment trusts... In particular the dividends from the operating companies paid the interest on t...
Read more