Monday, January 31, 2011

CloudBees Platform is GA

The last 10 months have been a great and crazy ride! Today the CloudBees team is proud to announce the GA (General Availability) of our integrated cloud platform, the only one on the market to provide a complete environment spanning from development to production.




This release is solid: DEV@cloud has more than 500 accounts with over 300,000 build minutes logged and RUN@cloud has more than 3,000 apps. RUN@cloud integrates the field-tested Stax platform which was the first PaaS on the market. While this release is based on Tomcat for now (see the Road Ahead below), you can already run quite a few other languages/frameworks: JRuby, Play, Scala, LiftWeb , PHP, etc.



(More images on RUN@cloud page.)

The Road Ahead

Going GA doesn’t mean our platform is locked-down, au contraire. In the good spirit of XaaS offering, expect new features and services to be rolled-out very regularly (most probably every 2-3 weeks). As always, we are very receptive of everybody’s feedback, criticisms and suggestions – so if you have any, please let us know.

We have a lot of great features being worked on in our engineering pipeline (extended scalability, HA, additional resource types, etc.), so stay tuned

Pricing

While pricing for DEV@cloud has now been published, it will only be effective around then end of February – for now DEV@cloud it is still free. As you will see, the future pricing features a base offering that will always be free. We will also launch new types of offering options in the near future.

Pricing information for RUN@cloud will be made public later in February – so usage is free for now. Much like for DEV@cloud, we will also provide a free plan.

Onward,
Sacha

Sacha Labourey, CEO
CloudBees
www.cloudbees.com
 
Follow CloudBees:
Facebook Twitter


Hudson is Now Jenkins

After some passionate discussions, the Hudson community has voted and accepted by more than 93% of positive votes to rebrand the project to "Jenkins".

A three-persons interim board has been setup to further formalize the development processes and architecture of Jenkins. One of those seats has been offered to ORCL, but it seems they've declined it. The idea is to set up proper board elections in a few months, once the dust has settled.

Let me restate that while CloudBees is an important contributor to the Jenkins project, we have no intent to "take ownership" of that project: we won't own its trademark, nor will we request contributors to assign a copyright license to CloudBees. Decisions about the Jenkins project will take place through its board and community. We certainly invite companies interested in Jenkins to join the community - and that includes ORCL. I've already received e-mails of companies indicating their intent to start working or to keep working with the Jenkins community.

The Jenkins community is an equal playing field project, code speaks.

Onward,
Sacha

Sacha Labourey, CEO
CloudBees
www.cloudbees.com
 
Follow CloudBees:
Facebook Twitter

Tuesday, January 25, 2011

Recording/Slides of "7 Ways to Optimize Hudson" Webinar

Last week, Kohsuke gave a very insightful webinar titled, "7 Ways to Optimize Hudson for Production." Since then, there have been numerous emails asking us to provide the videos and slides from the webinar.

For those of you who missed the webinar or missed the email from us with the links to the recordings, slides and the FAQ - there is good news :-).

You can find all of them on the CloudBees Resources page, scroll down to get the links to the three resources (videos - 4 of them, FAQ and the slides).

Finally, based on popular demand from Japan, Kohsuke is presenting the webinar on Feb 2nd 10am-11am JST. Registration link here. If you don't speak Japanese - this is a good reason to pick it up ;-).

CloudBees
www.cloudbees.com
 
Follow CloudBees:
Facebook Twitter

Thursday, January 20, 2011

CloudBees Announces Hudson Training

Today, CloudBees announced the availability of a one-day on-site training course in Hudson. For those who were in the CloudBees webinar yesterday,  Kohsuke mentioned the training and in fact one of the first courses is going to taught by Kohsuke (in Tokyo).

The training course is being launched in New York and Tokyo simultaneously on February 22nd, 2010, followed by London on February 24th, 2010. We are looking to offer this training in cities like San Francisco, Chicago, Paris, Singapore. So if you prefer a specific city, let us know and we can look into providing training there.

Meanwhile the details of the course and the registration information can be found here.

Onward...

CloudBees
www.cloudbees.com
 
Follow CloudBees:
Facebook Twitter

Wednesday, January 19, 2011

Java in the Cloud: Amazon Joins the Party

Amazon announced today its Elastic Beanstalk offering, essentially providing Java in the cloud. This is great news as it reinforces the message that the future of Java is in the cloud, not on premise.

Yet, beyond the signal it sends to the market, this move doesn’t radically change the current situation. If you are a Java developer, you will find that CloudBees is a more mature and more sophisticated offering. CloudBees is a global platform, from dev to production, which will shield you from IT entirely.

Let’s dig more into how CloudBees’ vision differs from AWS’.

First of all, at CloudBees we think that for the cloud to make sense to developers, it needs to provide a proper answer at all stages of an application’s lifecycle, not just at runtime deployment: code and binary repositories, building, testing, continuous integration, deployment, maintenance, integration with 3rd party systems, etc. We want multiple developers to be able to work as a team on those projects, we want them to know who is doing what, and for the more sophisticated deployments, what staging process needs to be followed before the new version of an application gets pushed to production. We don’t want you to even care about scalability, high-availability or any other IT related issue, we will handle that for you – “servers” are not what’s going to make your applications differentiated business-wise – let us handle that part. Also, let us live patch our platform so it is always the most performing and secure service you can find on the market.

Also, we see a lot of companies afraid about vendor lock-in, and this gets even more sensitive as they consider the cloud as their new platform: not only do they have to care about the software they leverage, but they also need to care about the cloud infrastructure they’ll rely-on as well as the 3rd party services they’ll closely integrate with. At CloudBees, all of our services are either based on Open Source and/or Open Standards: Java, Java EE, Spring, MySQL, SQL, etc. In terms of cloud infrastructure, CloudBees is IaaS-agnostic. We think the choice of a specific IaaS vendor should be up to the customer, either for legal issues or because they might want their Java CloudBees deployments to be collocated with other non-CloudBees deployments.

Lastly, much like we think the cloud is the new platform, we believe SaaS vendors are the new ISVs. ISVs are morphing into SaaS vendors and, as part of this transition, the old model of ISVs certifying on top of operating systems and middleware vendors and leverage them as their preferred go-to-market channels doesn’t apply anymore. The new go-to-market for those SaaS vendors are the cloud-native PaaS, and only the PaaS with a partner-friendly approach can succeed, both at the back-end layer (IaaS) as well as at the front-end (PaaS extensions, 3rd party services, etc.). CloudBees is a partner-friendly environment; we are easy to do business with.

This is what we are delivering with our DEV@cloud and RUN@cloud offering and vision, all smoothly integrated.

As the Java expert, CloudBees provides depth and precise understanding of what Java developers’ needs are, coupled with our leading vision of where the cloud is going.

Who said Java was dead?

Onward,
Sacha

P.S.: and remember, we will provide a fully integrated CloudBees+Stax offering by the end of this month!

Sacha Labourey, CEO
CloudBees
www.cloudbees.com
 
Follow CloudBees:
Facebook Twitter

Friday, January 14, 2011

Webinar: 7 Ways to Optimize Hudson for Production

On the 19th of January, Kohsuke Kawaguchi, founder and key developer of Hudson, will walk you through an essential checklist that you can follow to ensure a smoothly-running Hudson production server. This presentation will take place as a free live webinar, you just need to register here.

Hudson is the world's most popular open source Continuous Integration software, with over 25,000 sites using it to deliver superior-quality products. CloudBees’ own Kohsuke Kawaguchi is the world's premier expert on all things Hudson and Continuous Integration.

As part of the webinar, you will learn how to...
  1. Do regular backups of your servers
  2. Better estimate and allocate disk space requirements
  3. Fast and easy installation through packages
  4. Setup public key authentication
  5. and others...
Join Kohsuke for this exciting webinar and in less than an hour, you’ll learn the essential steps to create a smoothly-running Hudson production server and ensure reliable, optimized production operation.

We are waiting for you!

Onward,
Sacha

Sacha Labourey, CEO
CloudBees
www.cloudbees.com
 
Follow CloudBees:
Facebook Twitter

Hudson/Jenkins – Some More Context and Thoughts

(this post was originally posted on Sacha Labourey's personnal blog.)

Andrew Bayer just posted a blog post on Hudson-labs.org with a proposal for renaming the Hudson project to “Jenkins”. Since Kohsuke Kawaguchi, founder of and lead contributor to the Hudson project, is part of CloudBees, and I’ve helped Andrew and Kohsuke bounce ideas, I wanted to share some more context and thoughts.

Each and every Open Source project has its own DNA, its own philosophy that gets established over time. Born in 2004, Hudson has had plenty of time to find its cruising altitude. Yet, after Kohsuke left ORCL, ORCL decided they didn’t necessarily like the way the project was handled and asked for some changes to take place.

Let me clarify a key point upfront: was ORCL’s proposal stupid? No, not at all. Each and every project has a different DNA and I could very well see some FOSS projects for which such proposal would have made sense. Yet, the real question was not so much whether ORCL’s proposal could make sense for “some” project, the question was whether their proposal was making sense for Hudson, specifically -- a project with a well established DNA. And here the answer is a clear no.

So, why didn’t the community simply reject this proposal and move on? Anybody can request changes to any project, which doesn’t mean they’ll get accepted, right? Well, the difference here is that Hudson has an “asymmetry” in its community: one of its community members, ORCL, claims they “own” the brand and every contributor has to sign a contributor agreement granting them a copyright license. This “asymmetry” is frequent in many projects (JBoss, Glassfish, etc.) Yet, what is less frequent is when the “owner” of such asymmetry contributes very very little IP to the project (but receives a lot of free IP from the contributors through the CLA).

And so, the fear was that the Hudson project would be at the mercy of any random decision ORCL could take in the future. And while I trust the person at ORCL with whom I’ve been interacting to not make any stupid or damaging decisions, at the end of the day this is not an agreement with a specific individual, this is an agreement with ORCL: people come and go.

So, what was the right decision? Was it be better for the community to keep investing its time and energy in the existing brand, and take the risk that it could fire back at some point in the future or was it better to “sanitize” the situation upfront and invest those efforts in building a new brand, hence removing the asymmetry that currently exists in the community?

What about ORCL now? They essentially have two choices. They can either keep working on their own project under the good old Hudson brand, or they can participate as an equal player in the newly branded community. Personally, I’d really like to see ORCL join forces with the rest of the community, as CloudBees will. I truly hope ORCL will join us, if not now, once the dust will have settled.

Last but not least, let me clarify one important thing: CloudBees has no intention whatsoever to replace ORCL as the new asymmetry in the Hudson/Jenkins community: CloudBees has no intention to own the trademark on the new brand, to own the IP of the project or anything else. Yet, what CloudBees has every intention to do is to further invest time and energy in contributing to Jenkins.

Onward,
Sacha

Sacha Labourey, CEO
CloudBees
www.cloudbees.com
 
Follow CloudBees:
Facebook Twitter