This news comes on the heels of CloudBees being positioned by Gartner in the “Visionaries” quadrant of the newly published Magic Quadrant for Enterprise aPaaS and our recent partnership announcement with Verizon Cloud. Needless to say this is a great time for CloudBees!
2013 has been a very important year for CloudBees. Continuous Delivery is radically re-shaping the way enterprises deliver value to the business by accelerating the way applications are built and deployed. CloudBees holds a strategic position at the core of this phenomenon and has been going through tremendous growth, both on-premise and in the public cloud, thanks to our innovative Jenkins CI and PaaS-based solutions.
I'd like to take this opportunity to share my pride for the amazing work that has been achieved by our team and congratulate them all: working in an environment where the overall good of the company comes before individual egos and performance is very powerful. And humbling.
In 2014, we obviously aim to drive continued sales growth and product expansion, but we will also be announcing more partnerships aimed at bringing the power of Continuous Delivery to more developers, more solutions and more businesses around the globe.
Sacha Labourey is the former CTO of JBoss, Inc. He was also co-general manager of middleware after the acquisition of JBoss by Red Hat. He ultimately left Red Hat in April 2009 and founded CloudBees in April 2010.
Follow Sacha on Twitter.
Vivek Pandey has fifteen years of experience working with key web technologies. Prior to CloudBees, he spent ten years at Sun Microsystems as the dynamic language lead for Glassfish, ensuring enterprise-grade deployment and scalability of languages and frameworks such as Ruby/Rails, Groovy/Grails, Python/Django, Scala or Lift on Glassfish.
Vivek was a lead engineer in Sun's GlassFish team. At Sun he worked at various middleware projects related to web services technologies. Being an OSS fanatic, he was lead developer and committer on various open source projects. Vivek lives in the San Francisco Bay area with his wife, two daughters and a dog. Vivek is based in the CloudBees Los Altos office.
You can follow Vivek on Twitter.
Vivek, what is your role at CloudBees?
At the top of Mission Peak, in California.I am an engineer and architect at CloudBees. I work on various platform pieces - GrandCentral, the services platform, security services, integration systems and services. I also lead partner engineering, which involves on-boarding partner services as integrated CloudBees services. I also get to work on Jenkins and DEV@cloud engineering and hack RUN@cloud whenever I get the chance.
In my spare time, I like photography, hiking, movies, reading books and, of course, hacking - in reverse order. I am not much into workouts or outdoor activities except occasional hikes to Mission Peak or a trip to the movie theater. :)
What are some of your best tips for developing or testing apps?
Everyone's favorite butler!I start my development projects by first doing a high level spec to define various abstractions and their relationships. Then I continue further, breaking down each component. Most of the breaking down happens while writing code for high level abstractions. It lets me think in terms of how each software component interacts with other components. Often this cycle gets repeated to optimize my design. The thing is, once abstractions are defined well, the rest of the pieces fall into place easily. Also writing good and comprehensive tests is very important to avoid expensive regressions, but it's a challenge to balance delivering code with good code coverage and delivery timelines.
Above all, continuous integration and continuous delivery are the key. Simply put - use Jenkins!
What has been the best thing you have worked on since joining CloudBees?
Recently I worked on new ways to represent collaborative distributed REST resources. We have named this work Cloud Resources. At CloudBees almost everything is defined as a REST resource or some kind of HTTP service accessible via API. These resources have the potential to integrate, interact and collaborate with each other in a secure way. Cloud Resource defines such contract where each of these resources expose themselves as publicly accessible HTTP URLs, define their capabilities, their types in a consistent and secured way. There is a central registry for all Cloud Resource providers, making them discoverable. We envision all of our APIs will be Cloud Resources and we are making them so they collaborate with other Cloud Resources running anywhere on the Internet.
What is your favorite form of social media and why?
None in particular. I am more a passive user of Twitter and some Facebook.
If you could eat only one meal for the rest of your life, what would it be?
Some hot and spicy dosa, waiting to be devoured by Vivek
I love South Indian food, the most flavorful and spicy food you can find on the planet. :) To be specific, if I had to pick one thing, it would be dosa.
Helping customers help themselvesLarge enterprises are service providers themselves to their departmental and divisional constituents or customers. These business customers of Verizon Cloud will be able to rapidly build applications that their employees and own end customers need. Mobile, web, social apps, the new applications that an enterprise needs - e.g., a sales applications for their field force that depend on existing back-end infrastructure, e-commerce applications that drive revenue, support applications that cut costs and help with customer care - all can get to market more quickly with the help of the CloudBees PaaS on Verizon.
More choiceOur customers will benefit from a great service through a new partner. Verizon Cloud has a great sales and support team and enterprise customer relationships that both overlap with and are incremental to our own. Success with this joint effort is in making more customers happy with enterprise PaaS in the public cloud.
Accelerating application deliveryThe CloudBees PaaS speeds development and improves quality as there is a consistent experience across products from coding to building to testing to staging to production. Enterprises also want a solutions benefit and a better way of doing things, like continuous delivery, not to be sold unstitched patches of disparate tools from various vendors. While the CloudBees PaaS and Verizon Cloud are key anchor elements to this, we also rely on other technology partners to complete the cycle. Still, offering that in an integrated and cohesive experience is important to our developer users and customers.
More to comeThere’s still more work to do as the the Verizon Cloud is currently in beta. We expect to offer CloudBees on Verizon Cloud in a reasonable timeframe after general availability. CloudBees itself has been a generally available service since Jan 2011. So, get to know us and then get to know us on Verizon Cloud.
Andrew Lee is vice president, business development, at CloudBees
underneath all of the recent snow in BostonAt CloudBees, we have a lot of seriously talented developers. They work hard behind the scenes to keep the CloudBees Platform as a Service (PaaS) and our on-premise Jenkins solutions up-to-date with all the latest and greatest technologies, gizmos and overall stuff that makes it easy for you to develop amazing software.
In our last Meet the Bees blog, we met Kohsuke Kawaguchi, CTO at CloudBees and founder of the Jenkins CI project. This week, we head to Boston to visit Jesse Glick, developer extraordinaire. Stand by while we help Jesse dig out from underneath all the recent snow…winter is in full force, but this Bee doesn't hibernate!
NetBeans: The Definitive Guide,
co-authored by JesseA Massachusetts native, Jesse left the wild frontier of web marketing in 1998 (think Kraft Interactive Kitchen!) for Prague. In Prague, he soon began work at a tiny company called NetBeans, run by Roman Staněk. NetBeans offered a Java IDE. At NetBeans, Jesse weathered acquisitions by both Sun Microsystems and Oracle. Jesse worked on the IDE's core module system and its plugin tooling, the project system including its Ant and (later) Maven integrations and various other components. He also contributed to the project's own extensive build system and the migrations from StarTeam to (open source) CVS to Mercurial. Along the way he became an Ant committer and contributed to other key software including Maven and Mercurial and, of course...Jenkins CI, for which he was an early committer, developing the IDE integration. He co-authored an O'Reilly book, NetBeans: The Definitive Guide, about (of course) the NetBeans IDE, and has spoken on related topics. He now lives, once again, in the Boston area. Jesse came to CloudBees in 2012 as an elite developer and architect.
Jesse, what is your role at CloudBees?I have been writing Java code since the late 90s, most of that time working on the NetBeans IDE and thinking about how to make the life of other developers a little smoother. So when in 2012 I decided to work on something new, CloudBees was a natural choice: a big part of our business is ensuring that programmers can focus on programs, without all the overhead that application delivery usually entails.
With a few exceptions, I am working on or with Jenkins most of the day: the core of the continuous integration server, various of its community plugins, the Jenkins Enterprise extensions; and sometimes our hosted DEV@cloud service, including the VPN support.
I also occasionally help support the marketing team, by being one of the technical experts at the CloudBees booth at conferences like JavaOne, for example. But more on that shortly...
What’s a typical day look like for you? What are CloudBees customers like?Like many Bees, I work from home (just outside Boston), so the inbox comes up as soon as I am sufficiently awake. Usually the morning is focused on new customer support tickets, especially Jenkins Enterprise customers. Tickets run the gamut from simple questions about how to use some feature, to alarms about serious outages, to suggestions for enhancements, to requests for diagnosis of possibly significant error messages. Several of our customers are quite sophisticated Jenkins users—and even contributors to the Jenkins project—but still rely on our expertise to make sense of puzzling problems or recent developments. While maybe half of the tickets can be handled with a quick reply based on my own experience/ knowledge, the other half require real investigation and sometimes fresh development to solve and are true challenges.
With the timely items out of the way, perhaps by lunchtime, I often work on Jenkins core or plugins. There are an astonishing number of people actively contributing features and fixes of all kinds to the Jenkins open source code motivated by their own observations and needs, but often what our customers really need are less visible changes: more powerful APIs that allow optional features to be farmed out to plugins where they can be more readily managed; better scalability to hundreds of jobs and slaves, or thousands of builds; tighter security; more robust handling of errors; more thorough logging and diagnostics; and prioritization of bugs that keep on coming up.
Or I may be working on our Jenkins Enterprise extensions, which are crucial to our biggest customers, especially. For example, recently I spent a lot of time on the Templates feature, cleaning it up internally and making it better suited to organizations with several teams. As Jenkins Operations Center gets deployed more widely, I expect to see a lot of interesting ideas come back to us from customers who already run several systems and have a longstanding wish list of ways they should interact. Something fun to work on in the late afternoon hours, probably at the standing desk by this point so I do not fall asleep.
What’s your PaaS prediction for 2014 and beyond?My standing prediction for the past decade or more is that the massively complex tower of languages, frameworks, application code, network protocols, UI frameworks, virtualization and clustering that we seem to rely on more every year, will just become irretrievably stuck in its bloat. There may have been very good reasons to replace RMI with web services, or RAD builders with HTML 5, but the result is far more awkward to write and easier to get wrong. (NoSQL databases may be the only exception.) Perhaps people on the front lines will be forced to abandon much of it in favor of something with a radically different structure: implicit concurrency, distributed data, mobile code, access control based on cryptography not location, UIs that emerge from an ongoing task rather than a static design.
In the meantime, none of that seems ready to happen, so we are here to help you at least deal with the mess and get things out the door!
What is your favorite form of social media and why?I would have to say GitHub more than anything else. I could hardly care less about other people’s personal lives unless I am in the same room with them, but during the workday I definitely want to know what they are working on and what they think about what I am working on. Pull requests are obviously a good way to focus a bunch of people on one problem, but the simple @mention feature is a really handy way of keeping someone informed of a change you think they would be interested in.
If you could eat only one meal for the rest of your life, what would it be?
It is hard to imagine ever getting sick of any of the great vegetarian offerings at my favorite Indian restaurant, Guru the Caterer, in Somerville, MA. That would be my choice!
Now, about that marketing support...
As you can see, it takes a lot of technical knowledge (along with a good Bee costume and a pot o' honey) to really create buzz at a developer conference! Here I am with my fellow Bee, Steven Christou (on the right), in the CloudBees booth at JavaOne last September.
Of course, there always has to be an alpha Bee, so here Steven and I are engaged in some antennae-butting to stake out our turf. Nicolas De Loof is only too happy to officiate!
Kohsuke Kawaguchi presenting at one of the
1,000,000+/- conferences that he has spoken at!Here at CloudBees, we have a lot of really talented developers. You may or may not have interacted with them, but they work hard behind the scenes to keep the CloudBees Platform as a Service (PaaS) up-to-date with all the latest and greatest technologies, gizmos and overall stuff that makes it easy for you to develop amazing software.
For our last Meet the Bees blog, we were in France with Nicolas De Loof, support engineer. This week, we head back to the United States to catch up with Kohsuke Kawaguchi, CloudBees newly-named chief technology officer, in Los Altos, California.
Kohsuke is the founder of the open source Jenkins project. Jenkins is a popular continuous integration (CI) platform, used by thousands of organizations around the world. CloudBees leverages Jenkins in two ways: by providing additional functionality and professional support for open source Jenkins and by offering "Jenkins in the cloud," in our DEV@cloud development services. DEV@cloud is part of the CloudBees Platform as a Service (PaaS).
Kohsuke is a well-respected developer for founding and leading the Jenkins project. He is also a popular speaker at industry and Jenkins community events. He's often asked to speak about his experience and approach in creating Jenkins; an approach that has enabled Jenkins to become a widely adopted and successful community-driven open source project. The principles behind the Jenkins community – extensibility, inclusiveness, low barriers to participation – have been the keys to its success. Kohsuke's sensibilities in creating Jenkins and his deep understanding of how to translate its capabilities into usable software have also had a major impact on CloudBees' strategy as a company. Before joining CloudBees, Kohsuke was with Sun Microsystems and Oracle, where he worked on a variety of projects and initiated the open source work that led to Jenkins.
Follow Kohsuke on Twitter and on his blog.
Who are you? What is your role at CloudBees?The Jenkins ButlerI’m the creator of Jenkins, and my role at CloudBees is a little bit of everything in and around Jenkins. Sometimes I hack on open-source Jenkins core and plugins, while trying not to fail Jesse Glick’s razor-sharp code and spelling review. Sometimes I hack on our value-added Jenkins Enterprise by CloudBees. Sometimes I help DEV@cloud by patching Linux kernel modules and writing Chef recipes while fooling Ryan Campbell into believing I know what I’m doing, and sometimes I help handle some of the tricky support tickets, which I really cannot complain about because it’s all my fault, if you think about it.
I recently took on the role of CTO, which means I now have an opportunity to help make everything a little bit better. Ultimately, I’m just a guy who likes to create stuff. Mainly in software, but also in LEGO, cross-stitching, electronics, etc.
Why did you choose to work on continuous integration?Mostly by coincidence.
I like creating stuff, and as such, I have a large number of open-source projects. Sometimes I just come up with what I think is an interesting idea, and I just go write it.
Jenkins (then Hudson) was just another such piece of software. I wanted to write a web application, and I had an interesting idea for a web framework (this was back in the day of the Cambrian explosion of Java web frameworks), and perhaps most importantly I was a guy who breaks the build and I wanted to have software that catches my mistake before others do.
It somehow got more traction than most of my other software projects, and so I kept at it. Unlike some other people I genuinely enjoy making users happy one person at a time, fixing bugs one at a time, and gradually making the software better. And thanks to the amazing people who became a part of the Jenkins project, it eventually turned out to be a very popular piece of software.
What is your best memory from working at CloudBees?While I do a little bit of everything, what I really enjoy the most is those times when I get to concentrate on something without getting distracted into anything. I sometimes do that all on my own, but it’s more enjoyable when you are doing it with another engineer.
Ryan has been the biggest victim of this. At one time, I had him kidnapped for two weeks to hack on DEV@cloud mansion. I picked him up from the hotel in the morning, hacked the code all day in a conference room in our Los Altos office until pretty late, then dropped him back to the hotel. The amount of progress we were able to make was amazing. It was pure joy to have the face-to-face bandwidth with someone smart whom I normally work remotely with.
I’m hoping to do more of such sessions with Ryan and others in the future!
What else do you make other than software?Lego Earth Project
Kohsuke's favorite hobby -
being with his daughterI’m a big LEGO fan, and while I’m not as talented as other LEGO builders, I make it up by calling upon my ability to program. One of my recent projects was to build an accurate scale model of Earth by reverse-projecting a satellite image of Earth back onto a sphere, and deciding individual brick colors from there. Spending time with my daughter while having fun with my hobby at the same time is a wonderful thing, too.
I also enjoy electronics. I’ve done a little bit of this back in the electronics club in my junior high school. It was hard back then, but as electronics basically became programming micro-controllers, I started doing more of it. After all, I know a thing or two about writing software. I’ve built a growing orb (video) a while back, and since then I’ve used Raspberry Pi to build a large LED board with help from my daughter and a borrowed power tool from our SVP Steve Harris. It even comes with a custom designed PCB board, which was a first time I did it.
Several of Kohsuke's cross stitch projectsAnother hobby of mine is cross-stitching, which is a very simple form of needlework. This is a hobby I picked up from my wife, and it’s generally a girly hobby. People normally stitch something cute, but I usually like to stitch 2D pixel arts from old video games (more pictures). There’s also an interesting mathematical aspect to it --- you do cross-stitching for a while and you become capable of filling arbitrary continuous region of the same color with a single minimally long thread. For some time I have been hoping to “prove” that it takes no more than absolute minimum length of thread by writing a program that computes the precise movement of needle, but so far I have been unable to do so.
Needle-less to say (sorry, couldn’t resist!), the cross stitching population and the math/programming geek population do not really intersect, so I have yet to find a single person who I can really talk about this. When I find such a person, that’ll be the best day in my life.
I have a pet Android application project that I use to try out various build/test features of the Jenkins CI platform, and recently I decided to experiment with running those automated test suites on real devices using AppThwack's device cloud. I've written a lot in the past about how to run tests using software emulators to simulate real devices and there's definitely a place for that: with DEV@cloud, it's easy to configure and I have a job set up to build whenever I push a commit to the GitHub repository where the project is hosted, in classic CI style. You can see that job online here; it's a pretty good example of how to set up and run builds with automated tests using the Android Gradle Plugin with an emulator.
However, for real-life continuous integration and testing of mobile applications, that's really just the starting point. Emulator-based testing alone isn't enough - you need to see how your application behaves on real devices. When I develop, I normally have at least one device permanently connected to my laptop and I run gradle clean connectedCheck regularly to check that I haven't broken anything: I want something similar as part of my continuous integration process, and that's where the service from AppThwack is really handy. There are quite a few vendors out there offering device clouds for testing and, to be honest, I tried AppThwack more or less on a whim - however, I have been very impressed with their service (and their API/plugin support, more on that later) and I think that most people who use Jenkins to build and test mobile applications would find them a great fit. As always, I've put some detailed examples online, so that you can see exactly how it works.
In this blog, I'll go over the basics of how to use a device cloud with CloudBees' DEV@cloud Jenkins CI service (actually, it works exactly the same if you are using Jenkins Enterprise or your own local Jenkins installation). In a follow-up blog, I'll dig a bit deeper into automated Android/iOS testing and some useful lessons learned from this exercise. Being able to do multiple tests in parallel really forces you to think carefully about your testing strategy and definitely helps to drive out any issues with the tests themselves, but more on that next time.
Getting started with AppThwack is easy: just go to https://appthwack.com and sign up. There's a free trial option, so you can get started straightaway. Go to the Profile page (drop-down menu under your username, top-right on the home page) and make a note of your AppThwack API key, as you'll need that when configuring the Jenkins plugin. You'll also want to create an iOS or Android project (make a note of the name, you'll need that too) and define one or more device pools for your tests. Create your project and then upload your .apk or .ipa app build by clicking on the green button: that will take you to the screen shown below, where you can either select from a pre-defined set of devices, or define your own ("select from list"). In my example, I've created a custom device pool: again, make a note of the device pool name.
If you have an iOS or Android test project handy, then you can go ahead and upload that to run your tests directly from the web page, but I'm going to focus here on how to use the service with automated Jenkins CI build jobs. Make sure you have the AppThwack Jenkins Plugin installed via the update center; then go to Jenkins -> Configure Jenkins and scroll down until you see the AppThwack section. Enter your API key and save. Now go to the Jenkins configuration for your iOS or Android project and add a Post-Build Action ("Run Tests on AppThwack"). If you don't see that option in the drop-down list, it means that the plugin hasn't been installed: did you remember to restart Jenkins? You can see example builds online for Android and iOS projects. Here's what the Android configuration looks like:
In this example, my project is "gasp" and I'm using a single-device pool ("nexus72" - an Asus Nexus 7.2). This is a Gradle build using the Android Gradle plugin, so the debug and test .apk files are located in the build/apk folder, but if you're building your project with ant you'll find those in the <project>/bin and <test-project>/bin folders. I'm running JUnit and Robotium tests, but AppThwack supports a variety of iOS/Android test frameworks. Save the configuration and you're ready to run the build. Assuming that your project builds without errors, your application and tests will be uploaded and and the test runs scheduled. You'll see a link in the console output that will take you to the details for the test run: here's what it looks like for a completed project:
There's a wealth of information about the test run by device, with performance data plus of course the full test results. You can publish that data (click "Share" for the link) directly from AppThwack, but we want to get that information back into Jenkins, so that we can configure other, post-build actions based on the success or failure of the build. As I write this, the current version of the AppThwack plugin (1.4) doesn't support that, but hey, this is Jenkins and the plugin is open-source, so I added some code to poll the AppThwack server to get the job status and to download the results to the Jenkins workspace when the test run completes. Give the credit to the AppThwack folks: they have done a nice job exposing their APIs (check out the AppThwack github page), so extending the plugin was easy enough. By the time you read this, there should be a new version with this functionality but just in case, here's the link to my repo with the change, so you can cut your own SNAPSHOT build.
Now the console output looks like this:
Browsing the workspace for the project, you'll see a folder named device-results-<id> for each test run, with sub-folders for each device tested containing test results in raw and JUnit XML format, like this:
Bottom line: using a device cloud service like AppThwack is definitely the way to go for continuous integration of mobile applications. You can test your app on literally hundreds of devices: all using non-rooted, commercially-available models. You can structure your CI setup to build up from simple compilation, through emulator-based tests, to single-device and multi-device test runs, all the way to beta testing using services like HockeyApp, TestFlight or Zubhium. You can do it all in the cloud with DEV@cloud, or from your local Jenkins CI installation. There's no excuse for submitting a buggy app to the App/Play Store!
Mark Prichard, Senior Director of Product ManagementCloudBeeswww.cloudbees.com
Mark Prichard is Java PaaS Evangelist for CloudBees. He came to CloudBees after 13 years at BEA Systems and Oracle, where he was Product Manager for the WebLogic Platform. A graduate of St John's College, Cambridge and the Cambridge University Computer Laboratory, Mark works for CloudBees in Los Altos, CA. Follow Mark on Twitter and via his blog Clouds, Bees and Blogs.
As usual, when reading those MQ reports, we tend to forget the obvious: being mentioned on a Gartner MQ is an achievement by itself: many companies simply don’t make it on any MQ.
CloudBees is categorized as a “Visionary,” along with software veterans such as Red Hat, IBM, SAP and Progress, but CloudBees gets credited with a much greater ability to execute than all of those vendors (and a greater Vision than Google). We think this is a testament to our commitment to deliver a high-quality service in the public cloud, and our focus on helping developers, business units and enterprises to be successful at creating business differentiation in the cloud.
“Magic Quadrant for Enterprise Application Platform as a Service,” January 7, 2014, by Yefim V. Natis, Massimo Pezzini, Mark Driver, David Mitchell Smith, Kimihiko Iijima, Ross Altman. This Magic Quadrant graphic was published by Gartner, Inc. as part of a larger research note and should be evaluated in the context of the entire report. The Gartner report is available here.
On the other hand, very few - if any - of the legacy vendors have gone through the mandatory steps of reorganizing their engineering, support, operations and sales organizations to deliver on a true “aaS”/service model. Most of the time, their public cloud offerings serve as a lead generation mechanism for their private cloud offerings, aimed at protecting their existing middleware revenues. It is not by accident that the top five vendors in the Gartner MQ are operating true services-oriented organizations: Salesforce, Microsoft Azure, Google, Engine Yard and CloudBees.
Last but not least, the MQ is still marked by the absence of key vendors in the middleware business (such as Oracle) and the hosting/IaaS (Rackspace, AT&T, Verizon, etc.) spaces. The next 12 months will be very interesting to watch as those vendors make their entry in that market.
*To quote Gartner, "A PaaS that is designed to enable runtime deployment, management and maintenance of cloud business application services is an application PaaS (aPaaS)."
We've just updated our Terms of Service (ToS).
The previous ToS dated from 2010-2011. Consequently, most of the changes focus on better describing our current platform offering and our business model. Both are much more complete than they were three years ago. We also took the opportunity to add language to help prevent several (thankfully, rare) cases of service abuse that we have observed from time to time.
Let us know if you have any questions or comments. You can comment directly on this blog, or send an email to infoATcloudbees dotcom.
Sacha Labourey is the former CTO of JBoss, Inc. He became co-general manager of middleware after the acquisition of JBoss by Red Hat. He ultimately left Red Hat in April 2009 and founded CloudBees in April 2010. Follow Sacha on Twitter.
Java community - here he is presenting at Devoxx 2013.Here at CloudBees, we have a lot of really talented developers. You may or may not have interacted with them, but they work hard behind the scenes to keep the CloudBees Platform as a Service (PaaS) up-to-date with all the latest and greatest technologies, gizmos and overall stuff that makes it easy for you to develop amazing software.
For our last Meet the Bees blog, we buzzed down to Austin, Texas, to meet Ryan Campbell. This week, we head to Europe to catch up with Nicolas De Loof in Rennes, France. Many CloudBees customers know Nicolas from his interactions with them, when they open a support ticket.
Nicolas has been a Java architect for 14 years, working for French IT services companies. Techno-addict and open source developer, he joined the Apache Maven team in 2007, where he focused on the Google Web Toolkit plugin. Having many contacts in the French Java community, in 2008 he launched a Java User Group in Rennes: the BreizhJUG. He has also spoken at many conferences about Maven and Software Factory, and actively supports the Java community. Finally, Nicolas just authored a book published by Packt Publishing about Cloud Development and Deployment with CloudBees. He previously co-authored a book about Apache Maven with Arnaud Héritier.
Follow Nicolas on Twitter and on his blog.
What is your role at CloudBees?Here is the Nicolas we know
at CloudBees!I've been an open source contributor for years as a distraction from my past boring daily work for consultancy companies. I've mostly been involved in Apache Maven: I created the GWT plugin and contributed to the first implementation of Archiva repository manager. I've been elected as a committer but never made significant commits, as most technical changes I suggested were rejected. :'(
I'm now a support engineer at CloudBees. My role is to reply to customer issues on the support portal, both for our cloud platform and Jenkins support subscriptions. I ask engineering about the issues on IRC and just paste the answer on the support ticket so it looks like I'm the clever guy here.
As CloudBees is a startup, roles aren't immutable, so I used to provide technical sales support in Europe and also do some evangelism. I was a speaker at JavaOne and Devoxx for example, getting a free conference pass and five days of fun work. I also contribute to our platform development, mostly on Jenkins and our DEV@cloud service.
In my spare time, I recently authored a book about developing and deploying in the cloud. Last but not least, I'm a Java User Group-leader for the Rennes, France JUG. I'm involved in the Java community, and as such enjoy (tele)working for CloudBees as I can organize the JUG on business-time. :P
What makes CloudBees different from other PaaS and cloud computing companies?I may be biased as a support engineer, but my feeling is we are different because of the meaning of "service" as the last letter in our PaaS acronym. We don't just offer virtualization and an API, but full support. We have many customers asking questions on support for cloud and Jenkins usage, but also build tools, frameworks and development best practices. This sometimes is borderline consultancy work, but it makes it interesting for me and for our customers that can get a great service. Most people confuse cloud with just infrastructure automation, but it's actually about service, and our service quality is great as far as I can tell from customer feedback.
What’s a typical day look like for you? What are CloudBees customers like?I drive my children to school in the morning, then I'm back at my home office within two minutes - getting an hour of what used to be commuting time converted into additional working hours is a great benefit of telework. I talk to our Pacific time zone team in the morning (see Mic's Meet the Bees interview), then have a few hours to talk with colleagues in Paris or Bruxelles before the US wakes up. (As a French guy, this time used to be dedicated to complaints and gossip. That’s what we French guys do.) This is my most active period as I can focus on development without any distraction – quite the opposite experience compared to the past when I've been working in a noisy open office space. At 5:00pm I bring my kids home from school and take an extra few hours to talk with the CloudBees US team, at some point later in the evening.
About the actual work, this can change every day. Sometimes I just have to give customers some assistance by explaining platform usage, sometimes I have to do a deep dive into Jenkins code to diagnose a memory or network issue, sometimes I can get spare time to develop Jenkins plugins, experiment with platform features or contribute to the engineering effort. Sometimes I watch TV all day long, but don’t tell my boss! (Editorial comment: Based on Nicolas's output, we can all but guarantee that he isn't watching TV all day long...except possibly reruns of Saved by the Bell. More on that later.)
What’s your PaaS prediction for 2014 and beyond?Major cloud services will suffer various attacks and outages. Some will use this as proof that the cloud is not ready for production. The same guys will suffer a server failure on Saturday and get admin to restore a one-month old backup on Monday morning, but won't announce it publicly on http://status.acme.com, like cloud services companies do (including CloudBees). More and more users will use cloud services anyway and we will see new startups offering innovative solutions based on them. In a few years, CloudBees will acquire Oracle and make Java ACTUALLY open source.
What are some of the most common mistakes to avoid while building an app? Over-engineering - especially in the Java ecosystem. Java always has made simple things complex. Not just Java EE, Spring also in some ways introduced complex patterns that few applications actually require. I've been a techy fashionista and created such monster applications. I'm now a big fan of the micro-service architecture we have at CloudBees. Because of my experience, I always wonder when I see customer Hello-World applications deployed on CloudBees with a dozen frameworks and hundreds of classes. My last application was a simple web UI with some backend REST services. As dependency injection mechanism for the dozen classes of this app I've used "new" keyword. For sure I can't dynamically reconfigure the application structure, but I never actually had to do this.
What is your best memory from working at CloudBees?The first meeting I had was on a weekend in Dublin, when I just started to work at CloudBees. As guys here have various English accents - from Kohsuke's Japanese style to Stephen's Irish one - every time we switched speakers I had to adjust my brain English-parser and would completely miss the first sentence. Hopefully I have improved my English a bit since that time, so now I can get a few words and let them think I understand the conversation.
If you could eat only one meal for the rest of your life, what would it be? "Galette-saucisse," what else? Googler Ludovic Champenois used to live in Brittany like me. In California, where he's living now, he hardly can get good quality buckwheat flour. So at the last Devoxx, when we met, I offered him three kilos of local, organic, high-quality flour. I'm not sure how he was able to get through border police with three kilos of "powder" in his luggage, but this gives you an idea of what we are ready to do for a good galette.
What is your favorite TV or movie character – and why?
Zack, from "Saved by the Bell" - yes, I'm 40 now - but this was my favorite TV show as a teenager and helped me a lot to keep cool when I graduated. I liked the style of this show, the way the character is part of the story but is also able to make a direct connection with the viewing audience. I've been inspired by such offbeat humour and use it today - a lot - for my own talks when I'm invited as a speaker.
For a sample of my offbeat humour - if you haven't already had enough from my previous comments in this blog - the picture below was taken during Devoxx, as the official "Born to be a Geek" theme was inspiring to me.
The most frequent question people ask is, "Who is behind the camera?" I will save that answer for a future blog post. :P
Nicolas working at Devoxx...flushing cache?