CloudBees is the only cloud company focused on servicing the complete develop-to-deploy lifecycle of Java web applications in the cloud – where customers do not have to worry about servers, virtual machines or IT staff. The CloudBees platform today includes DEV@cloud, a service that lets developers take their build and test environments to the cloud, and RUN@cloud, which lets teams seamlessly deploy these applications to production on the cloud.
Since CloudBees was born, our vision has always been that at some point - say 2020 - the majority of the overall computing workload would take place in public clouds. What has been less clear is how things would play out between now and 2020 since this evolution would depend on so many complex factors (including the maturation of public cloud offerings, how fast entrenched vendors will fully embrace the cloud, the availability of cloud standards, etc .).
As a testament to that vision, we released the CloudBees Platform - first DEV@cloud , then RUN@cloud - on top of a public cloud infrastructure. This strategy clearly sets our vision and addresses where the market is going ultimately, setting up CloudBees as leading PaaS provider with a solution today!
Back to the future...
Yet, very early on, large enterprises reached out to us to tell us that they liked what we were doing, but that they simply couldn’t run in the public cloud. Sometimes for regulatory reasons, sometimes because their internal policies were forbidding any IP to leave “the walls” (public cloud or not), sometimes because the T&C/SLA/commitments of IaaS providers weren’t high enough, sometimes because they had extraordinary amount of existing CAPEX investment in data centers. Whatever those (good) reasons were, there was an impedance mismatch between the value CloudBees were providing and the problems we were solving vs. where we were providing that value.
As we gathered more and more feedback pointing in the same direction, and given how strong Java is in the Enterprise, we decided we needed to offer a way to solve Enterprises’ problems in today’s infrastructure, but with tomorrow’s technology. Consequently, we announced today our plans to provide the CloudBees Platform (both DEV@cloud and RUN@cloud) as a "Private Edition", running on-premises.
In terms of the first cloud management/virtualization platforms we will be supporting, we will focus on VMWare vSphere (because of its obvious ubiquity in today’s Enterprises) and OpenStack (because of its very fast growth in Enterprises – looking for a robust yet much less costly alternative).
Hybrid as an evolution, not as a compromise
"Hybrid" solutions are sometimes perceived as being a compromise that offers “the worst of both worlds” while trying to fly under the marketing radar. This is clearly not how we understand the need for hybrid solutions.
Enterprises interested in leveraging a PaaS realize that transitioning their processes and training their teams will not happen overnight and that their existing applications will take time to transition to a PaaS - and some never will. Consequently, they want to start early, in the best possible conditions, and they want to do this without having to decide today what their policy with regard to external private clouds or public clouds will be. These are two independent issues: i) adapting their internal tools and ii) defining whether/how they can leverage a 3rd party infrastructure.
Taking on a hybrid strategy allows Enterprises to parallelize those two tracks and make it possible to line up their ducks for the day shared infrastructure will be an option to them, selectively, application by application.
Consequently, CloudBees’ hybrid PaaS strategy is about enabling a smooth and selective evolution towards the cloud, it is not about compromise.
If you are an Enterprise interested to participate or hear about our DEV@cloud and/or RUN@cloud beta program, please contact us . If you want to get a better feel for what a PaaS can bring, just sign up for free and build, test and deploy an application in minutes.
During the weekend we have been able to unlock the last remaining SVN accounts, all services are now fully up and running, and all data has been full restored. No customers suffered from any loss of data.
As previously mentioned, we would like to apologize for this downtime and reiterate that we will work on processes to make sure we can improve our availability in case of a future serious downtime of our hosting provider.
Using Jenkins? Thinking about Moving to the Cloud? Both? Then you'll enjoy the two webinars we have coming up...
The State of Jenkins, April 27th at 10am PT - Jenkins users and contributors have seen big changes over the last few months. Join Kohsuke Kawaguchi, the creator of Jenkins, as he goes over concrete numbers that illustrate the current state of the Jenkins project. Jenkins users will not want to miss Kohsuke's talk - the project has a very bright future!
Stairway to Heaven... In the Cloud, May 18th at 10am PT - A mature, full-featured PaaS allows your team to move deployment and production activities instantly to the cloud, where you'll enjoy faster deployments, no IT hassle, lower overall costs, no up-front costs and better scalability. CloudBees CEO Sacha Labourey and the team will demonstrate building and deploying Java apps in the cloud, using stable technology that's already running 4000 applications. It's much easier than you think to achieve cloud nirvana!
If you can't attend at the scheduled time, no worries - register anyway and we'll send you the recording. And if you want something to watch now, check out replays of previous webcasts on our Resources page.
Starting yesterday at 12:00 GMT, CloudBees has experienced partial downtime of its services.
CloudBees is currently hosting its services on AWS, on the East-1 region. Yesterday, AWS started experiencing serious problems on their infrastructure. Most notably, its EBS service (used to store data) was primarily impacted.
While most of RUN@cloud applications were able to run properly, DEV@cloud services were impacted by AWS' outage. Also, our users were not able to log into our services anymore.
We have quickly taken actions to make sure that CloudBees' users were able to use our services by moving load to less impacted AWS zones. At midnight (GMT), most services were up and running again (login, SSO, GrandCentral, Jenkins, RUN@cloud). However, our forge services (Git, SVN and Maven repositories) were still experiencing difficulties.
Currently, we have been able to resume forge operations. However, the data we have been able to recover for now predates by 12h the initial down-time i.e. all data that would have been stored in Git/SVN/Maven between Thursday morning at 0:00GMT and Thursday 12:00GMT is not part of the recovered information. However, this information is not lost: it is being kept "hostage" of AWS' recovery procedure as they re-mirror their data. Once this process will be done, our goal is to reconcile the 12h of missing data with the current forge data. This process will depend on the type of repository:
Git repositories: those repositories are accessible as of now. If you have information missing from the 12h period, you can simply PUSH from your local repository to recover information.
Subversion repositories: we have decided to forbid WRITE access to those repositories and only allow READ access. That way, we will be able to properly reconcilie them once data is made available to us by AWS. If you do not want to wait and do the reconciliation by yourself now, please open a support ticket.
Maven repositories: much like for the Git repositories, those are accessible in Read-Write and will be reconciliated once AWS is fully back online.
We will provide a new report as soon as we have more information available from AWS.
We would like to apologize for this down-time and we will work on processes to make sure we can improve our availability in case of a future serious down-time of our hosting provider.
Recently Kohsuke from CloudBees talked about the state of the Jenkins project at the Continuous Integration summit (which was hosted by LinkedIn in Mountain View, CA) along with Yoav from JFrog/Artifactory and Hans from Gradle.
JFrog gurus demoed the Artifactory integration for Jenkins. One of JFrog's advantages is that you can hold off publicly versioning and releasing an artifact until you know for sure that all other dependent builds can successfully use it. This situation happens quite a bit in more sophisticated development environments: you have to release artifacts that - while building properly - could be problematic for other consuming sub-systems. Handling those scenarios is typically pretty painful without a repository manager such as JFrog.
Amongst other things demoed were the “smart search capability” - to find the right modules - as well as the "license analysis" mechanism - which provides a centralized view of all artifacts, their dependencies and their corresponding license. JFrog allows you to associate additional metadata with artifacts, and that metadata can then be used for searching later. For example you could tag artifacts with quality measures (passed-alpha, passed-beta, general-availability). Even better, you can even create virtual repositories by cross-cutting metadata, e.g. exposing a repository which only contains artifacts that have passed-beta. This is really neat!
Kohsuke has blogged more about the integration here. You can find further information about the plugin here.
Finally, Kohsuke is presenting a “State of Jenkins” webinar on April 27th, 10am PST. Register here.
Deploying Java apps on CloudBees' RUN@cloud PaaS for Java? Monitor and manage them with New Relic Bronze. (Bonus: it's free for RUN@cloud users!)
A guest post from John Essex at New RelicSince we started New Relic a couple of years ago, one of the key tenets of our company vision has been to partner with leading PaaS providers to make it easier for them and their customers to gain application-level visibility in the Cloud, and in turn, deploy and maintain high-performance apps. In keeping with that tradition, we are very pleased today to be announcing that we have partnered with CloudBees, a leading platform service provider for Java apps.
CloudBees' RUN@cloud, a Java Platform as a Service that enables developers to deploy instantly on the cloud, now includes integration with New Relic Bronze, an on-demand web performance monitoring solution. Even better, CloudBees is making New Relic Bronze available at no cost to RUN@cloud customers.
Read on to see how to take advantage of FREE New Relic Bronze on RUN@cloud...
The CloudBees platform delivers reliable and elastic on-demand resources, unlimited scalability, "pay-as-you-go" pricing, a seamless transition from development to production, and an IT-free environment that relieves teams of both software and hardware maintenance hassles. It supports Java EE web applications – and applications written in all JVM-based languages – in an IaaS-agnostic environment. RUN@cloud builds on the power of the CloudBees platform to allow developers to deploy Java applications into the cloud. It brings traditional application server functionality to the cloud, providing load balancing, scalability, and high availability for web apps, Java EE apps, and Spring apps. Your team can write software in the same way you always have, using the same tools you would normally use for a traditional Java EE middleware deployment... then deploy instantly on the cloud!
With seamless integration in the RUN@cloud console, enabling New Relic has never been easier. If you are not currently a CloudBees customer, simply sign up and create your account.
After you create an application, just hit the Configuration tab and check the "Enable New Relic" box at the bottom of the screen. Simple!
Existing CloudBees customers can just go directly to the Configuration tab for any RUN@cloud application to enable New Relic.
If you have previously enabled New Relic (through Stax partnership for example), just contact CloudBees for more details.
So, if you haven't signed up for CloudBees and New Relic, now's a good time to start!
Kohsuke presented a webinar titled "Securing Jenkins" last week.
He talked about the best ways to control access to Jenkins. He talked about how to authenticate people using various authentication protocols, how to control what people can do/see on Jenkins through team memberships and on a projects basis.
Kohsuke touched upon Jenkins Security Design, major implementations, tips and tricks for configuration and wrapped up with Q&A.
For those who missed the webinar and are not on our email lists - the slides are available here.
This year, some of us ex-JBossians will be returning to JBoss World, taking place a month from now in Boston. It will be a bit of a homecoming in some ways, as I had to travel frequently to Boston during the three years I was at Red Hat. I have also been at every JBoss World since the first (in 2005) – except for last year, when I was busy getting CloudBees off the ground (April 1st is our anniversary!).
When I left Red Hat two years ago, I had nothing in mind except to do nothing, and I was highly skeptical of the cloud. In fact, when I first heard about the cloud – that is, as a bunch of machines running somewhere in the cloud – I really did not see much of a revolution there. But a couple months into my ‘temporary retirement,’ it became clear to me that the concepts behind the cloud did not just apply to servers, but could equally well apply to “applications”– and this was the real way to bring value to developers.
A year later, CloudBees was born. I wanted to focus on applications as a first-level construct and apply the cloud concepts of on-demand, scalability and pay-as-you-go to applications – not to virtual machines or servers, which make no sense to application developers. IT infrastructure is no longer a key differentiator. It’s a layer that’s well known, and which provides a good fit for VM-centric “legacy” applications, but they certainly do not provide a good foundation for deploying applications. Cloud is an opportunity to move away from IT that is customized for each and every application, the haute coutureof IT, and instead define the ‘Lego blocks’ of IT. So instead of having to reinvent the wheel for every application we build, the cloud lets us leverages basic elements that enable accelerated development at lower costs.
Yet another year later, I’m really pleased to see the responses so far.
To be sure, we are still working out kinks (thank you for your ongoing feedback), but at a fundamental level, we’re achieving our raison d’être.
If you are going to be at JBoss World / Red Hat Summit, stop by booth #1011 and see what we’re all about! (BTW, you can use our discount code, RHCUSTCLB34, to get $150 off the registration.) I expect to be quite busy meeting up with my former colleagues but send me a tweet if you want to meet up.
It is a bit old school, but as they say "no school like the old school" - you can reach CloudBees developers on #cloudbees on the IRC server irc.freenode.net.
For those who are not familiar with IRC applications - there are many good ones available for each platform if you are interested.
For those who really don't want the hassle, happily you can use the freenode web chat UI - with just your browser. Head on over to http://webchat.freenode.net
and then enter in your details:
The channel name is #cloudbees
You will find someone online most times of the day, from different parts of the world - feel free to just chat or ask questions or advice. Do note that it is a public room, not official support and you may get advice from non-CloudBees staff! (but that is just fine).
Since we launched our private beta of DEV@cloud, back in August 2010, DEV@cloud went through numerous changes and improvements. In January 2011, both DEV@cloud and RUN@cloud were released as public GA and in February 2011 we released our Git, Subversion and Maven repositories hosting services. At this point we have more than one thousand subscribers to our DEV@cloud offering (and much more on the RUN@cloud side – which pre-dates DEV@cloud) and it keeps growing at a rapid pace.
Some of the additions and improvements we made to our platform won’t be immediately apparent to you but they are critical to the future of CloudBees. They relate to how we meter services usage, manage subscriptions, bill our customers, etc. Driving all of these changes is our vision to build a complete partner ecosystem around the CloudBees platform both around DEV@cloud and RUN@cloud. And this requires a very stable yet flexible metering and billing platform with sophisticated subscription management. With our last release, we now have that and can start opening this to collaboration with partners.
The first service that will leverage our new subscription management engine is DEV@cloud. Starting on the 3rd of April, DEV@cloud is available in multiple subscription levels. While we still provide a free subscription, we now also offer for-pay subscriptions scaling with your team and your needs. RUN@cloud will soon undergo the same evolution (while maintaining a free subscription as well) – in parallel with the addition of some very neat features.
Stay tuned for a lot more as we continue to bring innovation to the new generation of Platform as a Service for the Cloud…