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.
After last week’s announcement of dotCloud going GA, a few persons asked me how such an approach differentiates from other PaaS.
In summary, while I think dotCloud’s offering has merit and solves some interesting use cases, it actually lives closer to the IaaS layer than being a real "PaaS".
What is a PaaS?
As I wrote a few months back, a PaaS should really aim at i) improving developer’s productivity and ii) provide them with a layer of abstraction to the IT infrastructure so that they can focus on what they are good at (and paid for): building quality applications. This shouldn’t be about servers, SSH and IP addresses, this should be about applications, continuous integration, load testing, etc.
A PaaS reaches that goal by making sure it efficiently solves the most typical use cases a developer will face while developing, building, testing, deploying, scaling and maintaining an application.
What is dotCloud?
dotCloud can be seen as a "Chef-on-steroïds” (and is probably how Opscode should have monetized Chef in the first place). As such, it allows you to easily create new virtual machines based on some "recipes" (called "Build Files") that will match typical scenarios such as "I want a VM with PHP and MySQL installed", or "I want a VM with node.js installed". You can then customize the resulting VM (by running shell scripts), access it over SSH, etc. It is really a VM-automation service.
Where is the mismatch?
While dotCloud solves some interesting problems (see next section), it simply is not a PaaS. dotCloud is a solution that will help you build typical software stack as virtual machines and instantiate them in the cloud. While the resulting VM can be used by a developer, this is no different than if an IT operation team had setup this machine for him: developers will not gain any productivity in doing so, nor will their code, build, test, deploy, scale and maintain use cases be helped in any way shape or form by using dotCloud. Developers will still have to decide where and how they will store their code, where and how they will build and test it, on what application server they’ll deploy it, how that application server will need to be configured, tuned and setup on the operating system, how they are going to setup clustering, how to rollback their application in case something goes wrong, how they can transparently live-update their application running in production with no service interruption, how will the application server be patched in real time by the PaaS provider, etc. None of that is solved by dotCloud.
dotCloud is really a service that will help you build and run virtual machines, not applications.
So, is dotCloud useless?
Useless? Certainly not, especially as a number of on-premise enterprise systems do not have a "cloud-equivalent" yet.
Companies will typically want to leverage a best-of-breed PaaS for their applications in order to get true productivity gains, yet will typically have a number of "legacy" systems that rely on a typical software stack that have to run in a traditional fashion inside a VM. In that case, the dotCloud approach is very elegant as it provides an easy way to define what your stack looks like and provision it in the cloud – process which would be much more complicated if you were to directly rely on EC2 VMs.
Once this dotCloud VM is up and running, it can be consumed by any client, including by applications running on a true-PaaS.
If you have a number of legacy systems that are infrastructure-centric that you want to run in the cloud, dotCloud provides an easy way to instantiate such VMs. However, if you are a developer and you are looking for ways to boost your productivity and solve your typical development use cases, what you need is a true-PaaS - such as CloudBees if you are developing on top of a Java Virtual Machine.
If you want to experience it by yourself, why don’t you sign up for free and deploy a test application?
A guest post by New Relic, provider of extraordinary real-time web monitoring and analytics... delivered as a service.
Today CloudBees launched a new partner ecosystem, which extends the company’s core Java platform as a service offering through support for additional services. The initial list of services is pretty impressive, and includes tools from Cloudant, JFrog, SonarSource, Sauce Labs, and of course yours truly. So now, through the partner ecosystem, developers building and deploying apps on CloudBees’ proven platform will have access to hosted services such as build and deployment management, data services, and app performance monitoring all from a single location in the cloud.
Former JBoss core contributor Sacha Labourey founded CloudBees with a focus on servicing the complete lifecycle of cloud application development and deployment — without any servers, any virtual machines or any IT staff. The CloudBees platform today includes DEV@cloud for build and test environments and RUN@cloud for production cloud deployments. New Relic can be enabled as part of your RUN@cloud environment. It’s easy…
CloudBees customers get your free New Relic today!
With its talented team of industry experts and its leadership position among Java platform providers, CloudBees is a great match for New Relic. We both share a customer-centric outlook and believe that organizations migrating to the cloud should have access to the very best tools to help them be successful. Case in point: we’ve mentioned before (and it’s worth mentioning again) that CloudBees is giving away free New Relic Standard with your deployment on RUN@cloud. Additionally, the CloudBees team has integrated New Relic with the CloudBees console so that you can manage your web app deployments as well as monitor real user experience and app performance in one UI. Easy! What are you waiting for? Just create a CloudBees account if you are not already a CloudBees customer, sign in, click on Subscriptions, and select New Relic. Choose “Learn More” for a complete description of the service then just hit “subscribe.” The entire signup and implementation process takes all of about 5 minutes.
Just select New Relic from the list of available services and you're on your way!
Manage your web app deployments and monitor performance in one UI.
[New Relic provides real-time visibility into performance analytics, real user monitoring, web transaction tracing, availability monitoring, and much more. If you deploy a web app, don't you want to know how it's doing? Check New Relic out! Like they said, their service is free on CloudBees, so why not try it? -- Lisa]
In Jenkins, the security mechanism is completely pluggable (see my earlier webinar for more details.) While this is good thing, it does make my life difficult in several places. One of them is to authenticate users with Jenkins CLI.
For those of you who haven't heard of Jenkins CLI, it is yet another mechanism to non-interactively access Jenkins from a remote machine and perform a bunch of useful operations, such as create a job, start a build, etc.
Jenkins is primarily a web app, so some of its authentication mechanisms revolves around web protocols that are just plain impossible for authenticating CLI clients (think OpenID and OAuth.) So up until now, support for authentication in Jenkins CLI was limited to those security realm that uses username and password.
This is where one of the fruits of the JAX San Jose Jenkins hackathon comes into play.
Starting 1.419 (which will be out July 4th), Jenkins CLI supports authentication based on the SSH key pair. Just like CloudBees DEV@cloud (or GitHub, or other similar sites), you interactively login from the web UI, then associate your public keys with your user account. Then CLI will silently authenticates itself using your ~/.ssh/id_rsa, ~/.ssh/id_dsa, or ~/.ssh/identity.
Aside from the fact that this is completely independent of the authentication mechanism currently employed on your Jenkins, what I really like about this is that in many places you already use SSH public key to access Git, Subversion, or doing deployment. So it nicely takes advantages of your existing investment, and "it just works."
When CloudBees launched our Partner Ecosystem on June 21st, our partners responded with such insightful blogs of their own, we wanted to share them. We hope you enjoy this guest post by Sauce Labs CEO John Dunham.
Three key software trends motivated us to form Sauce Labs:
- The rise of agile practice
- The domination of open source in the development and deployment process
- The rise of PaaS
Those three flows suggested that mainstream approaches to software were in for major change and we wanted to help with that. On the rise of PaaS, we asked ourselves “if we move all our dev tools to the cloud, how are users going to test that stuff?” ”With machines under their desk?” “No, we don’t think so” we answered ourselves.
And so today is a red-letter day at Sauce Labs. We proudly stand beside CloudBees supporting their newly announced CloudBees Ecosystem. CloudBees shares our vision that manual and automated integration testing must be an integral part of any cloud development system. We believe in their vision that as the line between development and operations continues to blur, and deployment is in the cloud, the full development process must therefore live in the cloud.
Paraphrasing Damon Runyon, the race is not always to the swift, but that’s where the smart money is. The software teams that deliver new value to customers the fastest are the ones most likely to win. Embracing a thoughtful balance of automated and manual testing, dev teams take on appropriate levels of risk as they accelerate deploying new features and value to their users. By inviting Sauce Labs to participate in their Ecosystem, CloudBees showed their keen understanding of this, and their view of the puzzle pieces necessary to make seamless dev-to-deploy in the cloud the game-changer it’s destined to be.
So, right on, CloudBees. Congrats on your launch!
[Thanks, John. We think it's pretty cool that CloudBees users can now take advantage of Sauce Labs' manual and Selenium-driven cross-browser testing on the cloud. More tests + faster tests = better quality + lower costs for all! -- Lisa]
Today CloudBees is reaching a strategic milestone on executing on our founding vision: we are launching our "CloudBees Ecosystem" program.
A Bit of History...
Historically, ISVs have been aggregating around leading platform vendors – such as Operating Systems (Microsoft, Red Hat, etc.) or Application Server vendors (Weblogic, WebSphere, JBoss, etc.). The platform vendors would certify those ISV solutions and provide peace of mind to customers: customers would know that those certified ISVs would work well on those platforms and would be properly supported by both vendors in case a problem would occur. For platform vendors, reaching a "critical mass" of ISVs certified on the platform was also critical: with too few 3rd party solutions certified, they knew their platform would be disregarded by customers.
Fast-forward and watch the cloud become the new platform : ISVs are morphing into SaaS vendors and the new platforms live in the cloud, they are called "PaaS".
In the cloud era, we can do more than simply mimic the good old ISV/Platform relationship. The cloud is all about increased productivity and separation of concerns: if you are a developer, you should be focusing on building a great application, not busy setting up an application server or a 3rd party solution.
To that end CloudBees Ecosystem program enables to you to browse all of our partner solutions online, from our GrandCentral dashboard, decide whether you want to enable each partner’s solution as part of your CloudBees subscription, in a totally self-service fashion. Most partners will typically offer both a free subscription (trial or limited usage) as well as a set of for-pay subscriptions to best match your needs. Once you have enabled a given partner solution, there is nothing else you need to do: provisioning of the service, identity and SSO integration, subscription management, billing, etc. is all handled through CloudBees. Typically, at the end of the month, you will get a consolidated bill that contains the CloudBees services as well as all 3rd party SaaS solutions you’ve enabled from CloudBees. Quick and easy.
Furthermore, since the CloudBees platform spans the complete application lifecycle, from development to deployment, our CloudBees Ecosystem also covers the entire lifecycle. Consequently, you’ll find partner solutions extending both our DEV@cloud and RUN@cloud offerings.
Ecosystem Launch - Welcome to Our First Partners
Today, we are announcing the program as well as on-boarding our first 5 partners: JFrog , Sauce Labs, SonarSource for DEV@cloud and Cloudant and NewRelic for RUN@cloud.
JFrog, home of Artifactory, is the only company to provide a cloud-based Binary Repository manager. While CloudBees offers a basic Maven repository structure, JFrog offers a feature-rich and highly sophisticated repository manager. Very appreciated in a SaaS environment, JFrog features "Zero Setup Time" and will set up HTTP access rules, software installation, configuration of common accessed public remote repositories, maintenance and backup automatically. Anybody serious about Maven artifact management should consider JFrog.
Sauce Labs, the web application testing company, provides a cloud-based service that allows users to run automated cross-browser functional tests fast (as well as manual tests) while eliminating the need for you to maintain your own test infrastructure! This is really neat: do you want to test your web application UI against, say, 15 different OS/browsers mixes? Fine: click a button and voila, your tests will automatically launch in parallel on those specific OS/browser targets, in a snap, with no setup or maintenance effort. If you are serious about UI testing, the mix of Sauce Labs and Jenkins-as-a-Service provided by DEV@cloud is the perfect match.
SonarSource is the company behind the very successful Sonar project, which does static and dynamic code analysis and is used by many teams around the world to continuously validate the quality of their code – again, a great complement to your Jenkins DEV@cloud environment. Since SonarSource didn’t have a SaaS offering, we have worked closely with them to “SaaS’ify” Sonar so that our customers can enjoy the power of Sonar without having to set up anything. Open Source projects who have subscribed to our free DEV@cloud offering will also soon be able to automatically populate the Nemo Sonar instance through a simple configuration setting.
Cloudant is providing a data platform based on the Apache CouchDB project. The Cloudant team has over two decades of experience solving ‘Big Data’ problems and led the MIT team that interacted with multi-petabyte data sets from experiments that include the renowned Large Hadron Collider. Cloudant is backed by the power of multiple cloud providers and can easily scale to hundreds of TBs. Cloudant takes care of all of your database concerns, including redundancy, availability, backups, maintenance and monitoring. If your Java application requires a BigData solution for unstructured data, you definitively need to look at Cloudant.
Last but not least, NewRelic is the all-in-one web application performance management provider for the cloud and the datacenter. Its SaaS solution, which combines real user monitoring, application monitoring, and availability monitoring in a single solution built from the ground up, changes the way developers and operations teams manage web application performance in real-time. More than 10,000 organizations use New Relic to optimize over 6 billion transactions in production each day. NewRelic has been a long time Stax partner and we are very happy to pursue this relationship now that the Stax team is part of CloudBees.
As you start building your new applications or perhaps maintaining your old, you soon find that automating as much part of the development lifecycle makes for faster and more robust development. We are now moving to the next phase in the “Continuous Integration” lifecycle, in which development is moving to “Continuous Deployment”. In continuous deployment, applications are deployed straight to production systems after they have been successfully built. A successful build would include steps like testing, staging on a production system etc. This article shows you hot to take a simple application that is built on a local system and move it to the cloud (in this case using DEV@cloud SaaS and RUN@cloud PaaS). The article takes you through the following steps:
Build a local app
Local App -> manual build -> manual deploy -> Local Tomcat
Pull app from SCM -> build on local Jenkins -> continuously deploy -> Local Tomcat
Pull app from SCM -> build on local Jenkins -> continuously deploy -> RUN@cloud PaaS
Pull app from SCM -> build on DEV@cloud SaaS -> continuously deploy -> RUN@cloud PaaS
This article will help take your application (wherever it fits in the above lifecycle) and move it to the cloud. Check it out.
Do you provide Sonar as a service or do I need to set up my own Sonar instance?
We provide "Sonar as a Service", in partnership with SonarSource. Similarly to Jenkins-as-a-Service, you don't need to worry about installing Sonar, maintaining it, setting up a database, etc. It is a SaaS!
What Storage Services/APIs are offered for file storage?
Currently we offer the same as what the Servlet API requires i.e. local temporary file storage
Any plans to expose the underlying IaaS storage? Like AWS EBS as an abstracted filestore? Otherwise devs will be forced to use REST based file APIs tied to IaaS providers...
We are discussing options, we understand that a proper storage solution is needed. Ideally, we'd like to find a non-AWS dependent solution so you can easily move from one IaaS to the other, transparently.
What is available for multi-casting across nodes to support products that use clustering like Coherence and others?
You would need to use our clustering solution instead (unless those vendors are interested in partnering with us
Which IaaS abstractions are supported/roadmap other than AWS? Eucalyptus/OpenStack...?
We have announced support for OpenStack (it is in works) and VMware vSphere.
How can someone prove the platform security meets certain standards? If there are platform security
requirements that you specifically require, you will need to get in
touch with us and we can see how to address those requirements.
Are there plans to get federal security accredidation for the underlying platform? This is currently not on the
roadmap. If you have a specific project in mind that would require this,
please contact us and we'd be glad to discuss this with you.
Can't you get a better speaker? He sounds French! The thick accent guy is our CEO, so we cannot fire him that easily. We are sorry for the inconvenience.
Does CloudBees use their own AMI to build the appcontainer? or user has to provide their EC2 credentials? You do not need to provide your credentials, you will run under "our" account, this is totally transparent to you (and easy!)
Do you have any plans to add collaboration platforms (trac, jira, etc) to the Cloudbess stack ? We are soon going to announce an
ecosystem program that will add additional services to CloudBees. (we
demo-ed Sonar as part of the service today). If you have specific ones
that you will like, please send us an email/or on forums and we can fast
Do you support full Java EE app servers (Jboss, Glassfish, etc) and MySQL DB? Today
we only support tomcat-based deployment but we are working on a EE6-web
profile container, this should be transparent to you.
Do you support full Java EE app servers (Jboss, Glassfish, etc) and MySQL DB? Yes we provide a MySQL as a Service, it is very convenient and easy to use.
I am an avid Led Zeppelinfan and was wondering what would happen if roles were reversed: Led Zeppelin built a cloud platform and CloudBees wrote classic rock. These are some things I could think of:
1.We wouldn’t have any of the kick-ass songs from them - no "Stairway to Heaven" That would be a tragedy!
2.No disrespect to the CloudBees team (myself included) but I think we would suck making music – it would all sound like bees buzzing. Also, as software engineers, would we release versions of songs? "Please upgrade to Stairway to Heaven 2.0 - it fixes some issues with the guitar-ing in version 1.0." ;-)
3.Led Zeppelin making software would even be weirder. Would forums be called "Kashmir"? “A perpetual stalemate of complaints and responses between users and the Zeppelin coding team :-D. Then again, maybe we’d have had the Cloud 40 years ago.
This is turning out to be a slippery slope…
On a related topic, what if you (software developers) really could be in the heaven when building and deploying web apps in the cloud. Is there a cloud nirvana? I think there is!
The CloudBees Platform can be appropriately considered a "Stairway to Heaven...in the Cloud" and you can use it to climb the steps to cloud nirvana (admittedly I am a bit biased - so sue me ;-) )
Join CloudBees CEO Sacha Laboureyand the Bees as they demonstrate the ease of building and deploying Java apps in the cloud, using mature, rock-solid technology that's already running more than 4000 applications. The team will do a complete “develop to-deploy” walk-through of building a web app in the cloud using all the instruments at CloudBees' disposal. Sacha acts as the orchestrator as we "Rock and Roll" and ascend the stairway of solutions to build an application from scratch and deploy it to the cloud.
(Note: for a more detailed, serious ;-) description and registration for the webinar on June 8th at 10 am Pacific Time,GO HERE)
Since the CloudBees adventure started, a little over a year ago, we've made very fast progress and delivered the only end-to-end, develop-to-deploy, Java PaaS on the market, available in GA.
But our progress hasn't been solely on the product side, we've also made considerable steps forward on the business side with - for example - the recent addition of Josh Allen to the team. Today, we are announcing a key hire: Jim McLoughlin is joining CloudBees as VP of Sales.
Finding the proper profile for this position has been an interesting challenge. We wanted somebody who understands developers on one hand, who understands enterprises on the other, and, since we are in the cloud era, somebody who also perfectly masters the SaaS no-touch/low-touch business models. Furthermore, since the cloud is a nascent market, I wanted somebody with substantial "depth."
Thanks to his past experiences at Borland, Peoplesoft, JD Edwards and more recently Appirio, Jim has this unique mix of skills, and I am very proud to have him part of the team.