Jenkins - The Man Behind The Curtain
While most of the cloud world was obsessed with price reductions coming from Google and Amazon last week, some of the more astute observers picked up on what is ultimately an even more important theme.
Right. Google seems to have understood very deeply that the key to upping the competitive game with Amazon and Microsoft in the public cloud is through developers. More than live migration and race-to-the-bottom pricing, they know that they can use their savvy as developers to differentiate the platform for developers. They use the phrase “meeting developers where they are,” and have committed big time to using Jenkins - as Google's Chris Smith put it - as the “man behind the curtain” to orchestrate continuous delivery from code to production.
1411 People Stared in Awe at the Mighty Power of the Jenkins Update Center During Google Cloud Platform Live
That phrase “meeting developers where they are” is kind of interesting, too, almost un-Google like. They’re not inventing a new Google-icious CI or build tool. They’re giving developers what they’re used to and are productive with - IntelliJ (aka Android Studio), Git, Jenkins, Maven and Gradle. They’re glueing those powerful tools together in a simple flow that fits seamlessly across their properties and Google Cloud Services, all leading toward deployment on Google Compute Engine and App Engine and Android devices.
That’s a pretty expansive vision, a fundamental change to the way developers build, test and deliver applications in the cloud world. A real platform play. It’s something we at CloudBees have been delivering on for a while now and that our customers have been depending on 24x7 to run their businesses. Here are a few of the important things we've learned in our journey to delivering the most advanced developer-centric Platform as a Service in the market:
Hybrid is reality, and will be for a long time. We love the cloud and run our business on it, but most businesses have existing investments (technical, capital and procedural) that are reality for them. Those businesses and the developers in them want to use the cloud, too. So, you need to live in both worlds and connect those worlds. For continuous delivery to be meaningful to the developers living in this hybrid world, you need to bridge them securely and painlessly, and that’s particularly true for people in the enterprise. That's why we've invested in things like RBAC, on-prem executors, VPN connectivity, and SAML support. Meeting developers where they are sometimes means you need to meet them in their own data center.
Continuous integration - and continuous delivery even more so - requires connections to all kinds of surrounding systems. This is one of the reasons Jenkins is so incredibly popular, because if you can’t do that using one of the 900 or so plugins in Jenkins today, you can build one yourself. Heck, that’s why Google is using it, too! Part of the “trick” of providing Jenkins as a hosted service is to do it in a way that exposes the flexibility and community-powered plugin set. The Update Center is the window into those plugins, so it's nice to see it being visible in Google's demo. Ultimately, all this relates to "running at scale" - supporting teams and the larger scale business processes that developers live within. Those developers will demand direct access and tweaks to the plugins and the ecosystems they unlock. Developing and deploying a web or mobile app is often just a part of a bigger chain of automation, which often spans reusable common libraries into post-deployment testing. Giving teams of developers the tools to collaborate and thrive within this kind of larger flow, continuously - that’s running at scale.
Community is key. The great thing about the Jenkins project is that Jenkins itself is built to encourage community, and it is operated to build community. Like any community, it has leaders and highly engaged participants. But, it also welcomes people who jump in and dabble, who do a quick project to solve a specific problem, or who extend the work of others. People participate because their investment pays back and often makes them feel good at the same time. So Google, my advice to you is to jump in. Don’t just keep the butler downstairs waiting for you to ring the bell for CI service. Come on down and have a beer with the rest of us. I guarantee you’ll be welcomed!
This last week was a big one for cloud. The message should be crystal clear for competitors to the Google Cloud Platform. If you want to leapfrog Amazon (or Amazon: if you want to avoid being leapfrogged), you need to connect with developers. Those developers have long ago gotten used to instant access to on-demand infrastructure. Yawn... has the price dropped again? They want to consume a service, not build it if it’s not core to the problem they’re solving for the business. What’s more interesting to these developers and the people who employ them - and whose businesses depend on them - is how to create, update and deliver better software faster, continuously. The man behind the curtain to make that happen, to put the power of community and connectivity to work, turns out to be Jenkins.
-- Steven G. Harris
Steven Harris is senior vice president of products at CloudBees.
Follow Steve on Twitter.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.