Wednesday, February 29, 2012

March Madness at CloudBees

Time sure flies when you're having fun at CloudBees. January and February has quickly passed us and we're approaching March in full force. Join us as we trot the globe to pollinate some CloudBees love.

Agile Best Practices: Exploiting the Cloud For Speedy Development & Continuous Delivery
March 6 @ 1PM ET
Join this webinar to learn how the cloud can provide you significant advantages that allow organizations to substantially improve efficiencies and delivery times at a much lower cost, reducing the overall total cost of delivery of applications.

Mastering Continuous Integration
March 29,  Broadcom, San Jose, CA

Houston Ruby User Group
March 13 @7PM CST,  Houston, TX
If you're a Ruby developer in the Houston area, join us for an evening of food and drinks
while you learn how to develop and deploy Ruby apps using CloudBees DEV@cloud
and RUN@cloud services. We promise it'll be worth your time!

Come & network with other Ruby developers!

Jenkins - Selenium Meetup: Selenium, Jenkins, Robots, Oh My!
March 14 @ 6PM PST,  San Francisco, CA

Join Jenkins creator - Kohsuke Kawaguchi, Selenium creator - Jason Huggins, and Eventbrite Jenkins engineers - John Shuping & Theo Cincotta, as they explore and celebrate the myriad ways that Jenkins and Selenium go hand in hand.  Sign up (using Eventbrite, of course!), it's mostly full already.

Bordeaux JUG
March 14,  Bordeaux, France
Our very own engineer extraordinaire, Nicolas de Loof will share his real life experience on software factories and how he got to be in the cloud. Nicolas will demo by creating a web application from scratch, set up a continuous delivery to show how the cloud can make a developer's life simpler..all using the CloudBees integrated solution.  Visit Bordeaux JUG!

Toulouse JUG
March 15, Toulouse, France
If you missed the Bordeaux JUG, Nicolas
will be at Toulouse JUG the following day to give the CloudBees integrated solution demo here as well.  Visit Toulouse JUG!

4th Cloud Computing Summit
March 23, Thistle Marble Arch Hotel,  London
Visit us at the CloudBees booth -- S7.
Francois Dechery will be representing CloudBees. He is also giving a talk focused on Platform as a Service (PaaS) that will include a demo of how CloudBees provides unique coverage, entirely in the cloud - that encompasses  the entire application lifecycle: source code management, build and continuous integration (CI), deployment and management of applications and databases for test or production, monitoring, logging and more.  Check it out!

Conference Cloud Computing
March 26 @ 5PM CET, Limoges, France
Take advantage of this FREE event to learn what many have been saying about the emergence of the cloud. Come to learn and speak with people who are currently living the cloud experience. You, too, can have the cloud experience. Join us to learn how...after all, it is FREE!

Phorum 2012 Cloud Computing Conference
March 28, The Inn at Penn, Philadelphia, PA
Our very own VP of Marketing, Andre Pino, joins a panel of cloud technology enthusiasts to discuss the key market needs they've identified and how those market needs are being addressed through the use of cloud technology.  Join us!

Cloud Computing World Expo

March 28-29, Paris, France
If you're in the area, stop by our booth -- G20. At this year's Cloud Computing World Expo we will present a session called, Develop and Deploy Enterprise Applications in the Cloud. We will also be on a panel discussing why and how you should move to Platform as a Service (PaaS).

Learn more about Cloud Computing World Expo

Agile ALM Connect

March 29,  The Hyatt Regency, Reston, Virginia
Senior VP of Products, Steve Harris, will be giving a presentation on how a continuous integration (CI) development process benefits from being in the cloud. He will also highlight challenges and lessons learned in such environments, and in large deployments, and how people have solved them. He'll examine the techniques PaaS+CI enable, such as automated deployment to staging and testing, pre-tested promotion to production, and better visualization and accurate audit trails.  Come along!

We hope to see you at one of these events! Go here for more information or to review all of our upcoming events.

-- Alyssa Tong, Events Manager
Follow CloudBees:
Facebook Twitter

Monday, February 27, 2012

Open Sourcing the Credentials Plugin

I thought we would start off with

A story...

A team is just starting off on a new project, getting things done is the priority.

Source control, minor scuffle as the team argues the relative merits of Subversion, Git, Mercurial... (the one lone CVS fan storms off with a bruised ego and maybe more). A winner is declared and somebody sets it up.

Access control, well just give everyone on the team an account and give them all the same password: “password123”, so that password forgetting and subsequent resets will not be a problem. Anyway, it's a small team that trusts each other.

Continuous integration, somebody downloads Jenkins, grabs a spare machine, stuffs it under their desk... 5 minutes later... up and running.

Jenkins needs the source control password to do some task or other.  Well, it's “password123” no big deal, sure everyone knows that password.

At some point in time, the bureaucrats enter the scene, and this cozy little “password123” realm gets disbanded.

Now source control is integrated with some corporate LDAP or other scheme providing the glorious single sign-on.

The password Jenkins uses to access source control changes every 30 or 60 or 90 days, and somebody has to run around the Jenkins user interface on “password change day” changing that password from “$cr3wITp0licyJan12” to “$cr3wITP0licyFeb12” hoping they have not missed one of the many places Jenkins stores password (email auth, scm auth, issue tracker auth, etc) before Jenkins tries for the 5th (or 3rd) time with the wrong password and the account gets locked out and needs a reset (with a repeat run around).


If any of this sounds familiar, then CloudBees releasing our Credentials plugin for Jenkins as Open Source will be the first step along the road to a better solution.

It's not the complete solution, only because all the current Jenkins plugins that store credentials will need some modification to use the credentials plugin, but those changes should be minor.

What does the Credentials Plugin do (for users)?

The credentials plugin provides a standardized API for other plugins to store and retrieve different types of credentials. If you were to take a stock Jenkins installation and just install the credentials plugin, you wouldn't see anything different... to see something different you would need to install a plugin that defines a type of credential. Once you did that you would find:
  • A “Manage Credentials” screen on the “Manage Jenkins” screen allowing you to manage system and global credentials.
  • If you are using Jenkins security, when you go to “Users” / your username / “Configure” you would see the option to manage personal credentials.
  • Anywhere those credentials are needed, there is a drop down list of the appropriate available credentials, and you just select the appropriate one.
  • When the time comes to change the password, you just change it once. 
And that is about it, from the end-user's perspective. A single point for managing each credential. Change it in one place and you are done.

What does the Credentials Plugin do (for Jenkins plugin developers)?

The credentials plugin provides two main extension points:
  • Credentials - a base class for all Credentials types managed by the credentials plugin. Most plugin authors will just want to subclass this type to define what they need to store in the credential type... better yet, if you can find an existing Credentials subclass that stores your credentials.  So, for example, if somebody created a ssh-credentials plugin that just defines a SshCredentials class, then anyone needing ssh credentials could just depend on that... [Note that careful use of readResolve can allow this to be introduced after the fact]
  • CredentialsProvider - an extension point for something that can provide credentials. For example, the CloudBees Folders plugin uses this extension point to provide folder scoped credentials, so that the credentials are only available to jobs within the folder.
When you need to get back some credentials you just call CredentialsProvider.lookupCredentials(type,item,auth) to retrieve the appropriate credentials. 

The type parameter is the class of credentials you want to retrieve. 

The item parameter is the job you want to retrieve the credentials for, but this could also be the Jenkins instance itself; e.g., if getting the email credentials when Jenkins is sending emails, if getting the ssh credentials for Jenkins to start a slave node with, etc.

The auth parameter is the authentication that is requesting the credentials. In general this will be ACL.SYSTEM but, for example, the soon to be released version 2.0 of the CloudBees Deployer plugin adds a “Deploy Now” action which allows a user to use their own user-scoped credentials to deploy an already built web application to their own RUN servlet container instance (useful for testing older builds to see if you have a valid test case for that bug).

Why are we releasing this plugin open source?

Jenkins needs this functionality, and releasing it as open source lets the community retrofit all the existing plugins with confidence that the source is in the open and not CloudBees proprietary.

Where is the source and when is the source available?

Relevant documentation

- Stephen Connolly, Elite Developer and Architect
Follow CloudBees:
Facebook Twitter

Thursday, February 23, 2012

Let Jenkins Hit Itself in the Head without Fear (a.k.a. Restart Safely)

While recent improvements in Jenkins have removed some of the need for restarting, there will always be times when you need to restart. If your Jenkins instance is busy, running lots of jobs on multiple nodes, finding a window in time when you can restart safely because there are no running jobs can be next to near impossible. You could use the “Prepare for Shutdown” management option to stop new jobs from being scheduled, but then you have to remember to actually restart the Jenkins instance... and if a 36h build job is 15h in, chances are you will forget to login in 17h to restart the instance so that new builds can start again and Jenkins can keep your codebase’s back safe from developers breaking tests.

Enter the Safe Restart Plugin, which will wait those 17h for you and then restart Jenkins on your behalf.

Stable Release Versions
The latest release is 0.2 which was released in September 2011 and has no known issues.

Requirements for Plugin-Use
Jenkins 1.421 or newer.

Step-by-Step Instructions on How to Use the Safe Restart Plugin

  1. Go to your Jenkins instances root page.
  2. If your Jenkins instance has security enabled, login as a user who has the Overall | Administer permission.
  3. Select the Manage Jenkins link on the left-hand side of the screen.
  4. Select the Manage Plugins link.
  5. On the Available tab, select the SafeRestart Plugin and click the Download and Install button at the bottom of the page.
  6. (If you are using a version of Jenkins prior to 1.442) Restart Jenkins once the plugins are downloaded.
Nothing to configure.

  1. Click on the Restart Safely button.
  2. Click on Yes.
  3. Go make a cup of coffee.
Tips & Tricks
  • Note this plugin just puts a link on the main page, Jenkins' core functionality provides the safe-restart functionality, i.e. you can still use the http://jenkins-url/safeRestart link to restart safely without installing this plugin.
Known Issues
  • If your Jenkins instance's servlet container does not support a web application restarting its own context, then this plugin cannot provide restart functionality, and the “Restart Safely” link will not appear.
Relevant Documentation
- Stephen Connolly, Elite Developer and Architect
Follow CloudBees:
Facebook Twitter

Wednesday, February 22, 2012

CloudBees Introduces Subversion, Git Plus Other Best of Breed Development and Agile Tools with CollabNet

A guest post from Guy Marion, VP & GM, CollabNet Cloud Services

CollabNet is excited to join the CloudBees Partner Ecosystem today.  This partnership brings to developers a comprehensive development experience in the cloud, improving productivity of distributed development teams via the introduction of CollabNet’s Cloud Services Platform, Codesion, to the CloudBees Platform.

With Codesion, developers using the CloudBees Platform can now instantly provision Subversion and Git code repositories online, track and manage bugs, and make use of Codesion’s broad range of popular Agile development tools.

Who are CollabNet and Codesion?

CollabNet is the recognized leader in enterprise cloud development and Agile ALM, with more than 7,000 global customers that range from single workgroups to large enterprises. CollabNet has deep open source roots, including the creation of Subversion (
now formally known as Apache Subversion®), the industry leading version control system with millions of users. CollabNet helps enterprise customers build and deploy better software through its focus on collaboration, enterprise Agile methods and cloud development and computing.

Codesion is CollabNet’s cloud services platform and is the leading enterprise-grade cloud development and deployment platform, with more than 3,800 customers and 70,000 users around the world.

What services are now available to CloudBees customers?

With the integration of Codesion and CloudBees, the following enterprise-grade services are now available on the CloudBees Ecosystem in just a few clicks:

•    Source control management hosting (Subversion, Git, CVS)
•    Wiki, issue and bug trackers (Trac, Bugzilla)
•    Agile project management (ScrumWorks Pro)
•    Shared drive (WebDAV)
•    External integrations  (Basecamp, FogBugz, Lighthouse, Pivotal Tracker, Rally, JIRA and VersionOne)
•    Automated deployment (Codesion Publisher)
•    Multiple project workspaces
•    Advanced security (SSL, role-based access control, password control, IP whitelist)
•    Offsite backups
•    High availability infrastructure (99.9% availability)

This tight integration gives you a single place to manage your code and includes unified support and billing. It will help you…
•    Improve the efficiencies of development teams,
•    Offer freedom of choice of best of breed development tools and
•    Lower the overall cost of delivering quality applications.

Enjoy this one-stop shop for your cloud development, deployment and management needs.

To learn more about the Codesion services, visit the CloudBees Ecosystem.

Follow CloudBees:
Facebook Twitter

Sunday, February 19, 2012

Jenkins IRC Plugin

Jenkins is a continuous integration switchboard centralizing the communication with many different protocols, such as SSH, Git and SVN. This blog entry will focus on the IRC protocol and how one can turn Jenkins into IRC bot with the IRC plugin.

When the IRC plugin is installed and configured, Jenkins can send notification messages to a chat room (or channel), such as build information, and users can send messages to Jenkins to obtain information and perform actions, such as builds.

Stable Release Versions
The latest release of the IRC plugin is 2.18 and was released in November 2011. It has known issues.

Requirements for Plugin-Use
Jenkins 1.392 or newer and the utility plugin "instant-messaging" (called "Instant Messaging plugin").

How to Use
To demonstrate the use of the IRC bot plugin I first set up a test channel at FreeNode called ##jenkins-irc-bot-test. Then I configured Jenkins, from the main configuration page, to connect to FreeNode and that channel:

Using the Mac OS Colloquy chat client, I can connect to the same channel and also connect to Jenkins itself for the configured nickname, jenkins-irc-bot-nick, and send commands, such as !jenkins help that lists all the commands:

The command prefix !jenkins identifies a chat message as a command and is configurable from the IRC configuration section of the main Jenkins configuration page.

I set up a job called test and then "chatted" a few commands:

The transcript shows that I first listed all the jobs and also obtained the status of the job test. Then I built job test, checking the queue, and finally checking the status again. The chat room (or channel) ##jenkins-irc-bot-test shows that there are two new messages:

Jenkins is sending messages that the test job was started and completed. I configured the job test to send such messages:

How to Use the Plugins on DEV@cloud/RUN@cloud?
The IRC plugin is available to install on a DEV@cloud Jenkins instance on CloudBees Platform as a Service (PaaS) and it may be used in the same manner as with any other Jenkins deployment.

Relevant Documentation
--Paul Sandoz, Developer
Follow CloudBees:
Facebook Twitter

Thursday, February 16, 2012

Service-Based PaaS Architecture

Our AnyCloud announcement pulls together some important variables in the PaaS equation that enterprises are trying to solve. First, it's clear that you don't need to sacrifice the benefits of a fully serviced PaaS to get low-latency, secure access to your local resources and investments. Sacha covered this in detail, and how AnyCloud means you don't have to choose between public and private PaaS. Second, it further opens up the PaaS marketplace to European developers, who have privacy and regulatory concerns that are much different than their US-based counterparts. Fran├žois covered these issues. Finally, AnyCloud also brings a unified means to access and interact with deployments regardless of whether you're deploying to a specific region, to a specific hosting provider, or to your local data center. CloudBees can offer this kind of flexibility and unified experience because of our service-based architecture, and I want to cover that in a bit more depth in this post.

When you look at AnyCloud under the covers, you can see that we're following a proven SOA-style, scalable architectural approach. Here, for example, is the way AnyCloud looks in a hybrid, or "tethered" style deployment to your data center or a hosting provider's data center:

Our underlying shared services that we use for Identify/Account Management, Provisioning, and so on, are independent, and all interaction goes through an AMQP-based message bus. Agents are co-located with the services they touch. This approach gives us scale, resilience across lossy networks if needed, and lets us secure interactions properly. It also gives us the flexibility to host services on "any cloud".

The CloudBees PaaS goes a level deeper, though, when we talk about it being service-based, and it's a key distinction compared to a more application-centric approach, such as Heroku, would take. In an app-centric approach, everything starts with creating the application. All resources and management commands are attached to the application itself. This has the advantage of simplicity, and there is little chance of one application affecting another. In an app-centric world, the database can be instantly provisioned for the application and bound to a well-known location. But, if you want to share a database or other resources between applications, it may become difficult. You likely have to invest in an application architecture that makes sharing possible within each app (via REST interfaces, etc), and it becomes difficult for an application to deal with more than one type of the same resource. Furthermore, service partners are not app-centric themselves. Partner accounts must be provisioned for each application that wants to use a service, because each application has its own namespace of resources that it owns and manages.

In a service-centric architecture like CloudBees, no single service is the "primary" service. Instead each service is attached to a CloudBees account, and is able to expose account-level functionality (like its admin UI) and can provision resources that are part of the account that can be referenced by other services or resources in the CloudBees PaaS. Since each service manages its own set of resources, CloudBees exposes binding facilities that allow resources on one service to be bound to resources of another service. So, on CloudBees:
  • If you are subscribed to use our Jenkins, Forge, Application, or Database services independently, you can use them together to piece together workflows that make sense for your team. When your application intersects with lots of moving parts internally and externally, and you're pushing toward a more agile continuous delivery approach, you need this flexibility.
  • If you want to create an application that uses a database, you create the application and the database separately, and then bind them together to make the database available as a resource inside your application. If you later want to create another database for test, and want to to switch the application to use the test database, you just rebind. In an app-centric architecture, where the application can only connect to the database that was created for it, you would have to tear down the database data and build it all back up, versus just swapping which database your application is using.
These are just two examples where CloudBees' service-based PaaS architecture make hard things simple. They're also classic real-world, important cases in the enterprise. And they're part of the reason that you can expect CloudBees to be a big part of accelerating PaaS adoption in the enterprise this year.

For more information about AnyCloud, download our AnyCloud white paper.

Steven Harris, Senior Vice President of Products
Follow CloudBees:
Facebook Twitter

Wednesday, February 15, 2012

AnyCloud: Centralized Control, Local Flexibility

The announcement of our AnyCloud architecture has a significant relevance for cloud computing specifically in Europe and, more generally, for all the regions of the world. Since the cloud is supposed to be global and borderless by nature, why would AnyCloud matter more to some countries or regions than to others? In short, if your product or service is digital and can be delivered on the Internet, you just have to put it online and the world will come to you, right? Well, not so fast…we strongly believe at CloudBees that the ability to reach out to the whole world does not mean that you should ignore local requirements.

Why is AnyCloud an expression of that need to pay attention to local expectations? Because AnyCloud only keeps central what really needs to remain central in a PaaS. And it leaves as much freedom and flexibility as possible to all the other PaaS services in the CloudBees Platform. This is the cloud equivalent of the "think globally, act locally" principle that business consultants have promoted over the last twenty years, aka "glocal", and that many companies still struggle to implement.

Where did we draw the line between central and local in AnyCloud? Basically, shared services such as configuration, management and monitoring remain central, in a unified cloud service, while we decentralize the runtime services that allow applications to be actually deployed and run.

Shared services should remain central because if you just create a PaaS software and then throw it over the wall so that people download it and try to figure out how to make it work, you are not delivering a cloud service, you are just delivering a piece of software, the old way. On the other hand, runtime services should be as decentralized as possible, because this is the only way to truly take into account the diversity of local requirements.

Let's start with two obvious local requirements addressed by AnyCloud, and then we will look at a few regional IT players that will also greatly benefit from AnyCloud.

The first obvious requirement is location of data in your own country. Many countries have put in place legislation in that area. This is a complex topic that is not a cloud question, by the way, since it applies to any company that operates multiple datacenters around the world. The US Patriot Act makes these local laws even more relevant today. This legal environment is in itself a huge driver for AnyCloud. If your company is located in a country or a region where you face such legal constraints, you can now safely use CloudBees' AnyCloud while being fully compliant with local laws.

The second significant local requirement is the ability to connect cloud applications with databases or applications that cannot run in the cloud today. For instance, you might use a legacy ERP system that manages critical master data about customers, suppliers or products. Some of your cloud applications might need to have fast access to these data stores. That might force you to either co-locate your cloud applications with this ERP system or run them at a local hoster who can guarantee a fast connection with your own datacenter. AnyCloud is by design built to support these two deployment scenarios.
Beyond location of data and fast connection between cloud applications and non-cloud systems, we think that AnyCloud is also meaningful for many IT players in Europe or in other regions of the world, with a direct impact for end-users.

First of all, regardless of the ubiquitous and borderless nature of the cloud, business relationships and business decisions are still hopefully taking place between human beings. Trust and local understanding remain key dimensions. Therefore, companies want to build on their existing local trust relationships when moving to the cloud, instead of having to rely on a new and anonymous infrastructure provider. However, their existing hosters must be empowered with PaaS technologies that let them focus on their core infrastructure expertise, while delivering the full CloudBees experience. This is where AnyCloud becomes extremely relevant again. Why? Because AnyCloud does not require your hoster to become a PaaS expert and a PaaS software maintainer and manager. Those who try to implement and maintain very complex PaaS software today are struggling and find themselves sidetracked, because maintaining a PaaS mandates very specific skills and experience.

AnyCloud is also very meaningful in Europe for system integrators, in particular SIs with fifty to a few hundred employees who have a strong focus on software development, agile methodologies and web/mobile applications. They are often selected by enterprises, and sometimes by the larger global SIs, to deliver new and innovative IT projects. First, these SIs are embracing our DEV@cloud/Jenkins services right away because, as developers, they clearly see the value the services bring to their own efficiency and reactivity.

Secondly, with AnyCloud, they can now work hand-in-hand with their customers to define the best architecture for them, by smartly combining all the configuration scenarios that are made possible with AnyCloud. Most, if not all, of our highly visible projects in Europe today are supported by this special category of SIs and it helps them differentiate from competition by proposing innovative solutions to their customers.

Last but not least, AnyCloud means a lot to the European Independent Software Vendor (ISV) community. This is a very rich community, with strong ties to specific professions and local legislation, covering a vast array of languages and vertical markets. All of them are in the process of building a SaaS version of their products, or are transforming themselves into a pure SaaS provider. What were their choices until today when looking for a way to deploy their SaaS solutions? How could they implement a reliable and affordable disaster recovery solution? How could they deploy in several countries without facing significant technical and organizational headaches? These questions and many others faced by SaaS providers are now addressed by the CloudBees AnyCloud architecture.

Let me conclude by underlining two core principles that have driven the creation of CloudBees AnyCloud, taken directly from Bob Bickel's recent blog:
1. Middleware is now a Service - not Enterprise Software.
2. Deployment of applications and load should be completely flexible and open.

As we have seen in this article, CloudBees has not just delivered on these two principles for the sake of it. We have put them at the heart of AnyCloud, because both of them matter a lot to Europe and other regions of the world, in many specific and practical ways.

Beyond an apparent layer of global uniformity enabled by cloud computing, there are many subtle differences between countries and regions that we must take into account. We are fully aware that it is a never ending process, and a fascinating one, even for a horizontal technology such as PaaS. With AnyCloud, by making deployment a truly local choice, we have a rock solid foundation to go further in the near future, for the benefit of our customers and partners around the world.

-- Francoise Dechery, VP of International Business Development
Follow CloudBees:
Facebook Twitter

Selenium, Jenkins, Robots, Oh My!

Join CloudBees, Sauce Labs, and Eventbrite as we explore and celebrate the myriad ways that Jenkins and Selenium go hand in hand.

Wednesday, March 14, 2012 from 6:00 PM to 8:30 PM (PT)

Hosted at Eventbrite (map):
651 Brannan St, Suite 110
San Francisco, CA 94107

Featuring talks by Jenkins Creator Kohsuke Kawaguchi and Selenium Creator Jason Huggins, the event will give you an inside look at some recent improvements to how Jenkins and Selenium integrate together, as well as what's been going on with Huggins' show-stopping robot Bitbeam. You'll also hear a talk by John Shuping & Theo Cincotta, Senior Engineers at Eventbrite, who will show how the popular site uses uses Selenium & Jenkins in production.

This free event kicks off at 6pm with food and drinks, followed by talks from 6:30-8pm.

Please RSVP early to reserve your spot -108 people have already registered in 2 days. No worries if you can't make it though - the talks will be recorded and posted to YouTube after the event.

P.S.  If you aren’t already a member of the San Francisco Selenium meetup group, check it out – the group supports a steady stream of awesome events like this one.

Follow CloudBees:
Facebook Twitter

Tuesday, February 14, 2012

Solving the Private vs. Public PaaS Dichotomy: Discover CloudBees AnyCloud!

Demonstrating CloudBees' leadership in PaaS innovation, today we are announcing AnyCloud: a unique offering that will redefine and further broaden the PaaS market. AnyCloud provides the ability to have a unified view of your applications managed by CloudBees' PaaS, while physically deploying those on any infrastructure: public, hosted provider or even on-premise, in your own datacenter. Any cloud, anywhere.

A growing number of companies are increasingly turning to Platform as a Service (PaaS) as a way to improve their time-to-market, increase their agility and reduce their costs. The CloudBees Platform, for instance, provides application development, deployment and management services and eliminates much of the operations cost and IT hassles normally encountered by developers. And because it is available as a SERVICE, there is no need for you to setup either infrastructure or any software.

Unfortunately, for some companies, the promise of PaaS bashes up against the reality of enterprise constraints:
  • How can I use a PaaS and get low-latency access to data that sits on-premise and that I cannot move to the cloud?
  • How can I abide by security and privacy rules and still use PaaS?
  • How can I keep my processing and data in a specific region?
One solution to these problems is to a deploy a private PaaS – or “Platform as a Software” – a PaaS that you install, configure, patch and upgrade much like you do your existing middleware products. In doing so, IT is taking on another layer of software to maintain, update and pay for support on.

The truth is that a key part of the promise of PaaS lies in the “S”, as in SERVICE. When you choose a private PaaS path, you are forced into delivering the service for the PaaS yourself! Your IT team hopes it can forget everything it has learned about operating system and middleware configuration and support, but in reality it will have to be re-trained for something entirely new! You therefore continue to bear the infrastructure capital costs, in addition to the operational costs for maintaining the infrastructure. Thus, as illustrated conceptually above, the potential operational efficiencies of PaaS compared to IaaS are masked by the continued burden for both the infrastructure itself as well as your continued operational obligations associated with it.

In contrast, when you use a service provider, as opposed to a software vendor who is “enabling” you to provide service, you get a number of benefits that lead to lower cost and better service:
  1. The service provider reduces your operational cost. The expertise to manage the technical intersection between complex middleware and complex PaaS software is part of the provider’s responsibility, not yours. You can focus better on your core business.
  2. Service providers get better economies of scale. The expertise they have in-house is leveraged across thousands of customers.
  3. Service providers have an incentive to invest in operational efficiency. Any vendor has an incentive to improve its margins.

Getting Rid of the Public vs. Private Dichotomy!

Consequently, companies considering using a PaaS face what has become a typical dichotomy:
  • Either they can opt for a Public PaaS and enjoy all of the benefits of increased agility, much improved time-to-market and reduced costs, but not be able to move some of their applications onto that PaaS for technical/latency or privacy issues;
  • Or they can opt for a Private “PaaSoftware” in order to satisfy their technical and privacy requirements, but they will most probably never see the full benefit from increased agility, time-to-market or reduced-cost compared to their existing middleware setup (au contraire).

Announcing CloudBees AnyCloud

As a solution to this recurring problem, today, as the Java PaaS innovation leader, we are announcing CloudBees’ AnyCloud.

The AnyCloud architecture solves the above dichotomy by providing the best of both worlds: a fully-serviced PaaS (by CloudBees) that enables a multitude of deployment scenarios at the same time: on public cloud infrastructure (IaaS) in multiple regions, on traditional hosting providers (on vSphere for example) as well as on-premise, on your own servers, inside your own data center!

(NOTE: More information on the AnyCloud architecture is available in our CloudBees AnyCloud white paper.)

By opting for a supported CloudBees AnyCloud hosting provider or by registering servers in your data center, CloudBees AnyCloud delivers the operational cost savings and cloud efficiency of a fully-managed PaaS to your business – on any cloud – while satisfying your technical and privacy constraints.

With AnyCloud, your developers and lines of business get the benefits of zero-friction development and deployment and faster-time-to-market while getting low-latency access to your most important on-premise resources and existing investments. Same if you’re concerned about keeping your applications and data in a specific region due to privacy or regulatory concerns: AnyCloud is the answer. And if you already have a trusted hosting provider or preferred infrastructure cloud vendor, AnyCloud helps you enjoy the benefits of a fully serviced PaaS with the vendor relationship and investment you’re comfortable with.

More information on the AnyCloud architecture is available in our CloudBees AnyCloud white paper.

In addition to our existing production US-based offerings, we are currently rolling out support for AWS in Europe, OVH in Europe, as well as AnyCloud support in your own datacenter. If you are interested in AnyCloud, just contact us.



Sacha Labourey, CEO and Founder
Follow CloudBees:
Facebook Twitter