Cloudbees bets big that the dev/IT universe is ready for Jenkins everywhere

1 Comment

Cloudbees’ decision to drop its PaaS, or platform as a service, to focus on continuous integration and delivery is a bit like a car maker deciding to stop building cars to focus on building assembly lines instead. The analogy is imperfect but you get the picture.

Continuous integration is a software engineering method which requires the merging of all working copies of a piece of software into a shared mainline or trunk repository as the project continues. In traditional software development, integration happened infrequently or at the end of the process, which often led to all sorts of problems getting various pieces of the application to work together.

Cloudbees CEO Sacha Labourey (pictured above) said Jenkins, an open-source continuous integration (CI) product, has been a focus for a while, but now it is the sole focus as [company]Cloudbees[/company] helps PaaS customers move to Cloud Foundry, Google App Engine, AWS Elastic Beanstalk, Heroku etc.

The reason for this change of plans (or, ugh, pivot)? “In the last two years the market as started to shift from continuous integration to delivery and what’s interesting is that Jenkins is not only used by developers any more but is becoming the hub where dev, devops and IT people meet. It is where you define your end-to-end pipeline, from source repositories to Chef and Puppet deployments — it becomes your big IT orchestrator, and as such becomes as critical as your production environment,” he said.

Cloudbees’ product roster is now Jenkins Enterprise Jenkins Operations Center and DEV@cloud, a cloud-based service.

And the Jenkins ecosystem has boomed. Where there were 200 plug-ins a few years ago there are now at least 1,000, he said. And, it doesn’t hurt that [company]Google[/company] has embraced Jenkins for use with Google Compute Engine and Google App Engine.

Cloudbees’ founders came from [company]Jboss[/company], now part of [company]Red Hat,[/company] which gives them a good idea of which open-source projects can support a business, Labourey added. CloudBees’ CTO, Kohsuke Kawaguchi, doubles as founder and community lead for the open source Jenkins project, according to the company.

Jeff Schneider, CEO of Austin-based integrator MomentumSI, welcomed Cloudbees’ move with open arms because he sees Jenkins in the “vast majority” of his clients. “It works, it has a huge ecosystem, it’s gaining traction and is an extremely important element in continuous delivery,” he noted. He also felt it was striking that there wasn’t a enterprise-grade licensed version of the tool already available.

But this move also brings up the long-simmering question of whether a full PaaS is overkill for most companies. A full PaaS encompasses a set of integrated set of services — for database, load balancing, continuous delivery etc. — that developers use not just to build and test applications but to deploy them once that is done.

Schneider said Jenkins’ narrower focus makes it an easier sell because the CI tool is typically selected and paid for out of the same application development budget, whereas PaaS can require buy-in from many more stakeholders.

The countervailing argument is that companies are just not ready for continuous delivery — by Jenkins or any of its competitors — yet. And there are competitors, products like CircleCI, Atlassian’s Bamboo, Codeship, Wercker, and others.

1 Comment

bmccallion

CloudBees must have figured something out in the course of speaking with customers. In the enterprise much of configuration is performed manually because once provisioned, hosts and clusters tend to retain a somewhat stable OS / Network configuration.

We all know this is “wrong” because horizontal scaling is far superior. Yet many businesses do it “wrong.” Even so, these firms do recognize the need to improve. The chief weakness I’ve seen with Continuous Delivery as it’s pitched to enterprise is that it doesn’t speak to where enterprise is today. And to an extent that may be a challenge for PaaS. Everybody in Corporate IT at one point in their career was on a project where some cool new tech was adopted. In my case it was IBM WebSphere 3 at a large investment bank. It was a very interesting project and the managers stayed late at night and worked weekends. We all learned a lot. And one of the things you learn is to be sensitive to the impact of a “big bang.” No matter how much you try to explain how great an approach is, a technology is, it’s very difficult to force mid-level people to start using something that goes to the core of stability and operations. At all level’s everyone is very much leery of a solution where they don’t know what’s going on and can’t fix it if it breaks.

In subsequent roles I wrote software and process that enabled continuous integration using J2ee (WebSphere). Managers recognized that as much as there are many workflow and CI products were offered, at that time not one of them actually did the work of deploying and configuring a J2ee application to an AppServer and managing all the dependencies. I call the part I wrote “the last mile”. Most vendors leave that last mile portion as an exercise for Professional Services, or the user. But mostly the result was “shelfware.” I succeeded because I made the process really simple and used very simple technology, and worked really closely with the stakeholders to define the requirements. I also knew enough to avoid some of the rocks. There’s a lot to be said for a solution that actually makes everybody’s life easier.

CloudBees, taking a step back and looking at the challenges from the customer perspective and taking this new approach seems to have recognized that sometimes it’s necessary to provide the required solution, not the ideal solution one has imagined and expects users to adopt. Customers are much more likely to move along a continuous path than to take an abrupt jump. I don’t think I’ve written anything new here, but started writing and figured I would put some thoughts done.

Comments are closed.