Monday, October 31, 2011

XWiki SAS Joins the CloudBees Ecosystem

A guest post by Emilie Ogez

XWiki SAS is excited to announce a new partnership with CloudBees, the Java Platform as a Service (PaaS) company. Our Cloud wiki solution, XWiki Cloud, is now available directly through CloudBees' Java PaaS, with a simple API, unified billing and integrated account management.

CloudBees recently launched a partner ecosystem that extends its platform to seamlessly support additional high quality cloud services. Developers now have access to multiple hosted services and can manage Java web applications build, deployment, management, monitoring, and data services for Java web applications from a single location in the cloud. XWiki Cloud is now part of these services.

XWiki Cloud is a cloud-based wiki that's secure, easier to use and more organized than traditional wikis. At the same time it's a light and powerful development platform. Using structured data and in-page scripting you can create macros and applications that allow you to extend the capabilities of your wiki and customize it to match your specific needs. With XWiki Cloud there's no hardware or software to install and upgrades are automatic.

Wikis are a must-have for development teams. In XWiki, developers can store everything they might find useful for their projects, from code snippets to the comprehensive documentation of their applications. XWiki Cloud brings also many benefits:
  • Instant setup
  • Automatic upgrades
  • Email support
  • Rigorous backup processes
  • Guaranteed security
  • 24/7 hardware and software monitoring

"We're delighted XWiki is now part of the CloudBees ecosystem," explains Ludovic Dubost (CEO of XWiki SAS). And he continues: "CloudBees helps us bring next generation wikis to users from all around the world. As a result we are constantly looking to improve the way we create and deploy applications and CloudBees is a huge help in this direction. Combining CloudBees with our upcoming 'App within minutes' will make it even easier for our users to contribute and use applications."

More About XWiki SAS
XWiki SAS is a French company created in 2004 whose founding members initiated the XWiki Open Source community. It aims to provide a range of professional services for the next generation wiki, XWiki, that is more organized and easier to use than traditional wikis. The services are targeted primarily to organizations that seek to allow their users to work better together, and have their wiki reach a higher level of performance:  XWiki SAS joined the Gartner's "Magic Quadrant for Social Software Solutions in the Workplace" in 2010 and received an award at the last Demo Cup (Open WorldForum). It is also one of the 10 successful French enterprises in open source (L'Informaticien, n° 68). XWiki has today over 100 customer references and thousands of business users in France and worldwide.

Give XWiki and the CloudBees Java PaaS a try – no cost, no commitment!

Emilie Ogez is the communication and marketing manager at XWiki SAS. She is in charge of social media, communication, events organization and programs. Emilie also assists with business development efforts.

Follow CloudBees:
Facebook Twitter

Saturday, October 29, 2011

Let the WAR File be the Unit of Deployment

Each Java application or web server has a different way to deploy a Java web application, which is why the Cargo project exists. The same can be said of the Java PaaS solutions. (What is the Cargo of Java PaaS?)

The common unit of deployment is the WAR file. This is a good thing. Developers can use existing tools and it lowers the barrier to deployment.

A WAR file is just a standard packaging format consisting of Java classes, additional resources, plus some deployment metadata. There is no requirement that those Java classes be generated from Java source. Thus polyglot WAR deployment is possible for JVM-based languages.

CloudBees provides a number of ways for a developer to deploy a WAR file for Java or other JVM-based languages such as Clojure, Groovy, Ruby and Scala.

At the lowest level there is the HTTP API for deployment and management of applications. It's pretty simple, but as usual with such APIs the complexity is in the authentication mechanism.

Building on the HTTP API is the CloudBees API client library, a Java library that supports the HTTP API and encapsulates the authentication details.

Building on the API client library is the Maven plugin and the Cloudbees SDK, both of which provide command line support.

Deployment flexibility at the developer's fingertips. But, this can be taken further, integrating with other frameworks, especially those using other JVM-based languages.

For Groovy/Grails there is the Grails plugin.

For JRuby/Ruby on Rails the rails app can be packaged up as a WAR file using warbler.

For Scala/Play there is the CloudBees deployment module. There is also a plugin for Scala/SBT enabling deployment of lift applications.

Finally, and recently, for Clojure there is the lein plugin for deployment of Clojure ring applications.

Regardless of the language or Web framework all the above have two things in common: the WAR file and the JVM.

Paul Sandoz

The Babel Fish image is a trademark of Yahoo! Other product or brand names may be trademarks or registered trademarks of their respective holders.

Follow CloudBees:
Facebook Twitter

Thursday, October 27, 2011

Expanding the Integrated CloudBees Ecosystem

CloudBees launched its Partner Ecosystem in June, and it has been a success for our users and our partners.

If you're just looking into PaaS and trying to understand how it adds value over the traditional packaged software approach, take a look at the ecosystem for a real "Ah Hah" moment. Instead of you having to license, install, integrate and manage the tools you use in the development, deployment or monitoring of applications, you simply select the service(s) you need from within our Partner Ecosystem offerings. With just one click, you are automatically provisioned and up and running - all without even leaving the CloudBees environment. You'll also receive one consolidated invoice for CloudBees services and any add-on Partner Ecosystem services to which you have subscribed. It's really that simple.

Now joining our initial partners of JFrog, Sauce Labs, SonarSource, Cloudant and New Relic, we're very happy to introduce platform integrations with our newest ecosystem partners MongoHQ, Papertrail and XWiki.
  • MongoHQ, a hosted database solution for getting web applications up and running on MongoDB, fast. With it, developers can easily create and configure MongoDB databases as the data layer for Cloudbees-hosted applications. NoSQL, no problem, with CloudBees.
  • Papertrail, a log management solution for applications, servers and cloud services - available as a one-click, hosted service. Teams can use Papertrail to aggregate, tail and search log messages from applications deployed on the CloudBees platform. Driven by Papertrail's own experience as sysadmins and IT ops people, if you haven't seen it before, you'll be amazed at how useful and powerful it is.
  • XWiki, a customizable, cloud-based wiki that enables developers to easily collaborate and share details about projects. From within the CloudBees platform, developers can store everything in XWiki that they might find useful for their projects, from code snippets to comprehensive application documentation. And XWiki helps you scale up from developer-level usage to large scale enterprise usage in the cloud.
Give these solutions a try today! This kind of rich Partner Ecosystem is just another way that Platform as a Service and CloudBees are revolutionizing the way you develop, deploy and manage applications in the cloud.

- Steve Harris, Senior VP of Products

Follow CloudBees:
Facebook Twitter

Thursday, October 20, 2011

CloudBees Running for a JCP Executive Committee Seat!

At CloudBees, we are convinced that the cloud is the new platform; the platform where most of the workloads will end up running. This is a big fundamental shift in IT, one of those shifts that you only see once every two decades or so.

To navigate successfully through that transition, languages, frameworks, vendors, etc. have to adapt to that new paradigm. To quote General Erik Shineski (I tend not to quote Generals much, so please bear with me): “If you don't like change, you're going to like irrelevance even less.

For that reason, here at CloudBees, we have decided to step up and run for a JCP EC seat. We think Java needs to go through some important changes, including:

  • Java needs some cloud DNA urgently injected into it: because we have very strong credentials both in Java and in cloud technologies, we think we can bring a lot of value to the Java community;
  • The JCP itself needs to pursue its molting process: some changes have been performed, but those were the easy ones. Everybody remembers the Apache/Field of Use drama, we need to work to avoid putting Java in such a shameful corner anymore. At CloudBees, we have what it takes to understand the needs of the Java community while, at the same time, are able to be realistic about the velocity of changes that can be reasonably expected from the JCP.

At CloudBees, most of us have a strong Open Source background, hence we understand the value of reciprocity and transparency. We also have deep Java expertise: in our ranks, you will find developers who were at the core of projects such as JBoss, Glassfish, Bluestone, WebSphere, Weblogic, Silverstream, JRun, ColdFusion, etc. At the same time, our feet are well grounded and we understand the business imperatives and the need for a successful ecosystem.

Steven Harris, who recently left ORCL to be CloudBees’ SVP of Products, would be our representative on the EC. Read his insightful comments about the JCP and the unique perspective he brings to it.

If you want to help Java successfully transition to the cloud, CloudBees can help! But you need to VOTE FOR US so we can make it happen*!



*) In order to vote, you need to be a JCP member. If you are a member, the JCP has already sent you an e-mail with the link you have to use in order to cast your vote (check your spam filter).

Sacha Labourey, CEO
Follow CloudBees:
Facebook Twitter

Tuesday, October 18, 2011

Jenkins: The Safe and Sensible Choice for CI

With the success of the Jenkins User Conference that Sacha spoke about in his blog of last week, we thought it would be useful to document some key measures of Jenkins success and momentum, along with the great things that are happening in the community. In less than one year, the community has seen that 85% of existing Hudson users move to Jenkins when they upgrade; set up a governing board; instituted formal governance and process standards; provided transparency for its operations; developed more than 40 new plugins for Jenkins...and the list goes on.

It all adds up to the fact that Jenkins is where the community is - they are committed and enthusiastic. All of these factors demonstrate that Jenkins is the safe and sensible choice for your continuous integration (CI) investment. We pulled all the information about the Jenkins progress and community momentum into one place and hope you'll take the time to read the full whitepaper for the details. Here is a sampling from the whitepaper of how Jenkins and Hudson stack up.

Jenkins vs. Hudson -Ticket Activity

The numbers really speak for themselves.

We have also noticed that as Jenkins gets stronger and Hudson gets closer to emerging from incubator status at Eclipse, Oracle seems to be raising the volume on Fear, Uncertainty and Doubt about Jenkins. To head off the FUD they will likely continue to push, we also outlined the way the Jenkins community has improved its processes and governance to provide a stronger foundation for protecting your investment and your rights to use and distribute Jenkins. It's all there in the whitepaper.

CI with Jenkins is going strong, and the community continues to accelerate the pace of innovation and improvement within the Jenkins CI platform. The Jenkins butler has served up a lot of builds and is stronger than ever!

- Steve Harris, Senior VP of Products

Follow CloudBees:
Facebook Twitter

Monday, October 10, 2011

What a Week! JUC, JavaOne, TAB & More…

Last week was phenomenal in intensity: first we had the Jenkins User Conference (JUC), for which CloudBees was the platinum sponsor and key organizer. JUC was immediately followed by JavaOne and CloudBees’ semi-annual Technical Advisory Board (TAB) meeting. In between planning and execution of all of these activities a number of very important press releases were issued, along with associated media and analyst briefings.

Today it is Friday. I am back in Switzerland and it just started snowing: the perfect conditions to for me to take a moment to sit down, look back, reflect and appreciate.

First Up...Jenkins User Conference
Last Sunday, the first Jenkins User Conference was to start at 9:15am in downtown SFO. I arrived at 8:10am, thinking I was early and this would be a quiet start to the day: wasn’t it Sunday morning, after all? As I exited the packed elevator, I saw my fellow Bees already busy distributing name tags to attendees. At 9:00am, there were already more than 170 persons who had checked-in for the conference. In short order, we would eventually reach almost 250 attendees!
The speakers were very experienced and knowledgeable; as a result, the sessions were informative and of very high quality. All sessions were recorded and will be made available online in a week or two , so you’ll be able to judge their value for yourself. My only regret? There was one session I’d have loved to attend (“Continuous Deployment with Gerrit and Jenkins”). Unfortunately, it was taking place…while I was presenting mine! ;-) Oh well - I will catch the recording!
Probably the best part of JUC for me, though, was to see the passion of the attendees for the Jenkins CI platform and all that it has enabled them to achieve. This, along with their excitement at being gathered together from all over the world, made me realize how much Jenkins has grown – dare I say, exploded – over the last year or two. JUC attendees were from many countries, many companies – from start-ups to global enterprises, a myriad of industries and various cultures, but they all had the commonality of trusting the development and deployment of mission-critical applications to Jenkins. To me, that is proof positive of the robustness, quality and reliability of the Jenkins platform. On that very topic, in case you’ve missed it in the JavaOne communication frenzy, you can read here the communication that was released by the Jenkins community with regard to the formalization of their processes: rules of engagement, IP, trademark, etc.

Kudos to the Jenkins Community for holding the first JUC! I'd also like to once again thank the other vendors who, along with CloudBees, sponsored an extremely successful conference: Liferay, Red Hat, New Relic, Sauce Labs, Chariot Solutions and eXo Platform.

...Onward to JavaOne
Wasn't it Tuesday? After all, we spent the previous day at the Jenkins User Conference. Oh, right. That was only Sunday. On Monday, JavaOne started up. In the scattered set of hotels that serves as the replacement for the glory of the vast Moscone Center, it is hard to get an accurate feel for the show attendance. Even with my pessimistic hat on, I really think this JavaOne was bigger than the past two JavaOne conferences. Either ORCL is doing a good job attracting developers or Java is not quite dead yet. Or both. All I know is, there was a robust turnout of multitudes of Java developers!

The attendance at the CloudBees booth was phenomenal, with lots of follow-up activities in the pipeline as a result. I'd like to think it was our staff and our solution that attracted the crowds, but in all honesty it might really have been the Angry Birds we were giving away. Nonetheless, whether out of interest for our PaaS or the Angry Birds, it was really good to see the level of interest in CloudBees and in our offering. It was also a great opportunity for me to have a little fun with my team.

...Followed by the Technical Advisory Board (TAB) Meeting
On Tuesday afternoon, we conducted our semi-annual Technical Advisory Board meeting. Even our TAB agenda offered up some excitement. I was proud to announce that Edouard Bugnion, co-founder of VMware, was now a member of the CloudBees TAB! He joins existing TAB members Eduardo Pelegri-Llopart, J. J. Allaire, Rich Friedman and Roman Stanek. We closed the TAB with a great dinner that ended very early the following morning.

...and News

In addition to these three significant events, in the last 10 days, we’ve announced that Steven Harris has joined CloudBees as SVP Products, that we’ve released the first production-ready EE6-Web Profile PaaS implementation and that we have issued the 2011 Fall Release of our cloud platform.

These news releases have all generated a lot of interest. Stay tuned, as we have more news coming down the pipe…



Sacha Labourey, CEO
Follow CloudBees:
Facebook Twitter

Wednesday, October 5, 2011

ORCL and the Cloud: the Good, the Bad and the Ugly

In what was probably Larry’s second hardest thing to go through (after losing against Alinghi during the finals of the 2003 Louis Vuitton Cup), ORCL finally joined the cloud reality.

Let’s go through the good, the bad and the ugly in what ORCL announced…

The Good

Larry has long been in denial about the cloud: this stance was not sustainable anymore. As a matter of fact, ORCL was the last major IT company to still resist the obvious: the cloud is here to stay - and it is thriving. If ORCL hadn’t changed course, they were truly facing a risk that their application, middleware and infrastructure businesses would be ripped apart by fast growing and much more agile SaaS, PaaS and IaaS vendors – and this in probably less than half a decade.

But Larry is a wise businessman and he certainly has no intent to lead his venerable company to the “elephants’ graveyard.” Consequently, ORCL made it clear today that they intend to play a significant role in the cloud at all levels: IaaS, PaaS and SaaS.

HP, Microsoft and to a (much) lesser extent, IBM had already laid out a cloud strategy and had started executing on it. ORCL was the last fortress to resist and their stance had probably been cited by a number of CIOs as an argument to justify their own resistance to the cloud. Those days are now over and all of the largest enterprise IT vendors have clearly sent the message that the cloud is the new platform. ORCL joining the fray is a greatly symbolic step forward for the cloud.

The Bad

The problem is that if you take a closer look at ORCL’s current cloud offering you’ll quickly realize that ORCL is not really moving into the cloud, it is more…moving the cloud into ORCL.

You want to pay as you go? You want elasticity? You want on-demand? Fine. ORCL’s current cloud offering is essentially a repackaged vertical stack of the good-old ORCL you’ve always known; they’ve simply made it possible to consume it in a cloudish way. We are still far away from the generic cloud infrastructure offering of an Amazon AWS, a true cloud platform à la CloudBees or a multi-tenant application offering à la Welcome [b|h]ack to the ASP model by the hour, welcome to 1996.

My gut tells me that ORCL’s customers won’t be satisfied with such a vertically-closed view of the cloud. ORCL will have to do better much better. But it takes more than a snap of the fingers to move such a large ship towards a new paradigm, so let’s give ORCL some time, the benefit of the doubt and let’s see how they execute.

The Ugly

The reality is that despite ORCL’s efforts to enter the space, and independently of their technical offering, it will be very hard for ORCL to incentivize their sales force to drive any meaningful cloud sales.

In order to be successful, their cloud solution would have to be better, faster and cheaper than their current offerings.

ORCL's offering, as we have seen, is currently no way better or faster: being a mere hosting offering of their current products, it doesn’t provide any meaningful value-add and it is unlikely to generate a gold rush-like stampede to ORCL's cloud platform.

As for the cheaper part, I doubt ORCL will convert their very-high, per-CPU prices into marketplace give-aways just because the cloud is cool.

ORCL’s prices will either have to be compatible with their current pricing scheme and level – which means absolutely non-competitive with the cloud offerings out there – or aggressively priced, hence in complete competition with their own sales force.

The fundamental question for many entrenched software vendors trying to enter the cloud is how can they incent their sales force to move away from highly priced, multi-year upfront licenses deals, in favor of pay-as-you-go, pay-what-you-need, self-service offerings, in complete disruption of their current account-level or territory-based sales model. This will be hard to swallow and a tough selling transition to make.


As the last major IT vendor to commit to the cloud, ORCL closed the introductory chapter of its cloud story this week.

Ten years ago, it was less and less sustainable for companies not to have a clear open source strategy in order to i) protect their IP, and ii) increase their productivity. The exact same thing is true today with the cloud: now is the time to embrace the future.

Welcome to the cloud era, Oracle!


Sacha Labourey, CEO
Follow CloudBees:
Facebook Twitter