CloudBees: Bullish on PaaSFebruary 29, 2012
by Christine Burns
As early as 2008, Bullhorn Inc., a fast growing Boston-based provider of front-office staffing and recruiting management software, was considering the cloud to help streamline development and distribution of its Software as a Service (SaaS) products to over 2,500 customers and 25,000 users in 35 countries.
But Bullhorn’s early embrace of Platform as a Service (PaaS) had more to do with long-standing relationships than with new-fangled cloud technologies.
Tech argument: IaaS vs. Saas vs. PaaS
10 most powerful PaaS companies
Bullhorn was already heavily invested in Java-based application development and didn’t see the cost benefit of migrating away from that language in favor of scripting languages like Ruby, Python and PHP which are more commonly used in the development brand new cloud-based applications. But the company was growing by 40% to 50% year over year and the development team understood it needed to find a way to build more scalable applications.
The Bullhorn engineers were also in tight with the founders of Stax Networks, one of the very first cloud-based Java application platforms running on top of Amazon’s EC2 Infrastructure as a Service (IaaS). So when the well-funded start-up CloudBees, acquired Stax Networks in December 2010 as the means to accelerate the general availability of its RUN@cloud application runtime PaaS environment, Bullhorn was good to go.
And it went, fast.
In the last year, Bullhorn has implemented more than 60 customized applications on RUN@cloud. According to Matthew Fischer, vice president of Bullhorn’s services team, the company is working on implementing an additional 40 applications on the CloudBees’ PaaS.
RUN@cloud is the runtime side of the CloudBees’ PaaS story. It provides traditional application server functionality to the cloud, comprising load balancing, scalability and high availability services for web, Java and Spring applications. CloudBees customers can choose to have as their underlying IaaS any number of public cloud providers.
Applications running on RUN@cloud can be built using traditional Java EE development tools or using CloudBees’ second PaaS offering called DEV@cloud. DEV@cloud is a cloud-based development, build and test environment.
Fischer says deploying Bullhorn’s existing applications on RUN@cloud has resulted in an 80% reduction in the time his teams - both the internal core development team and the professional services team which builds customized extensions to the Bullhorn product line for customers—spend on resolving underlying cloud infrastructure problems like load balancing, system monitoring and technical integration issues.
“You obviously have to fully understand how the [Cloudbees] platform is operating as the developers of applications running on top of it, but you don’t have to be the ones tending to all of the DevOps details of scaling it as the company grows,” Fischer says.
A world of PaaS-ibilities
Tips for a successful PaaS rollout
One issue the team had with making the leap into PaaS was that some developers were hesitant to give up absolute control over the runtime environment in case of there were some type of outage. “But over time we’ve proven that PaaS is more reliable because the provider has operations folks that can do that better than we can,” Fischer says. “You’ve just got to be able to clearly articulate the benefits.”
Fischer’s teams collectively clock upwards of 30,000 engineering hours annually. So being able to turn the bulk of those hours back into time spent improving the core product or working with customers on innovative extensions tailored to their needs already justifies the CloudBees metered usage fees, Fischer says.
“We now focus on our core competency of building innovative code that helps us better address our customers’ requirements,” Fischer says. “The recent success of Bullhorn is tightly tied to the evolution of this PaaS.”
Crucial to the company’s rapid cloud deployment success is how it has deployed the Bullhorn SDK on RUN@Cloud, which in some cases is deployed in a multi-tenant configuration and other times deployed on dedicated machines should the customer set those types of requirements.
These open Bullhorn SDKs are Java-based applications that contain a robust services layer comprising components such as Spring MVC, XML configuration tools and a set of Web services that interact with BullHorn’s APIs to facilitate communication between the core application and the custom extensions and Web services that Bullhorn engineers or its customers have built.
The Bullhorn SDK also handles data access components and interfaces back to databases in the CloudBees’ PaaS and enables integration with systems residing within customers’ environments.
Taking the next step
Bullhorn has to date focused its efforts on getting existing Java applications up and running on RUN@cloud while still building new applications within its own custom development environment.
“Our priority was to make sure the applications we had in production got the benefit of being in the cloud first,” Fischer says.
But Fischer says his team now is actively prototyping new applications using DEV@cloud. The prospect is enticing for logistical reasons—Bullhorn has recently expanded its engineering team and has members of that team working from sites around the world. “Access [to development resources] from anywhere is emerging as an issue we need to address,” Fischer says.
Fischer also likes the way DEV@cloud has addressed continuous development cycles. Central to the CloudBees offering is the open source Hudson-based continuous integration scheme - now called Jenkins since Oracle claimed trademark issues with the name—which enables continuous quality control as developers write code and submit the changes to the repository. Each change is tested for quality and integration issues.
“We’ve never had a continuous integration mechanism in place, but we certainly want it going forward because of all the potential code problems it can alleviate,” Fischer says.
Finally, it’s important that developers pay close attention to how their PaaS providers are establishing any third-party ecosystem around their platform, Fischer says. “Who a PaaS vendor partners with today may have a direct effect on which tools you have at your disposal tomorrow to build your next generation product.”