When you need to build and scale services more quickly than your platform allows, what’s the solution? DemandBridge, a marketing software provider that sells brand management platforms to marketers, turned to Cloud Foundry to meet customers’ growing expectations for speed and customer experience in a cloud-based era.
DemandBridge previously operated its SaaS platform with a monolithic Java application on a large WebLogic application server. Moving to the cloud was a key element in their road map to prepare for growth, but just doing a lift-and-shift to a public cloud was not enough to meet their needs. “It was just a lot for us to keep up with, especially modifying our production application, which was getting bigger and bigger every time we did a release,” said Amer Mallah, Chief Technology Officer at DemandBridge.
The team had already been using Spring to take advantage of some of the latest best practices and begun researching cloud management technologies, but when they heard about Cloud Foundry, they were intrigued by promises that they could build applications faster — and scale them so easily.
Getting additional help for a four-person development team
While many companies using Cloud Foundry are in the Fortune 500, with teams spanning hundreds or thousands of developers, DemandBridge has only four developers on their Java team. In the beginning of their Cloud Foundry journey, the team tried setting up BOSH on a laptop and deploying CF local, but with each team member stretched thin by multiple duties, they found it too complex to learn and administrate at the speed at which they needed to operate. DemandBridge hired Stark & Wayne to set up an open source Cloud Foundry development environment for them.
In just six months, they were in production. “There’s no way we could have done it in that timeframe without them,” Mallah said. Stark & Wayne brought best practices and tools to facilitate the implementation of the DemandBridge environment. They knew how to apply patches and keep the environment up to date — things that could be time-sinking roadblocks for new users.
“From a developer’s perspective, we are at the same place as if we had installed Pivotal Cloud Foundry or one of the other prepackaged instances,” said Jared Placek, Chief Engineer at DemandBridge. “As a developer jumping into this, it’s been phenomenal. It’s such an easy thing to use, and we haven’t had a stability issue the entire year. We were dealing with stability issues constantly when we were doing our own administration on our own servers. This is a dream.”
Moving to microservices to speed up and scale
At first, DemandBridge used Cloud Foundry to route everything from the legacy applications to the Microsoft Azure cloud. But to improve performance and reliability, and to accelerate future development, their old platform needed to be dismantled and reconstructed into microservices.
By dividing it into functional units, they determined what could live on its own, and separated those out into microservices. They identified the communication points between the old platform and the services. “The whole nature of microservices, being standard JSON communication between applications, means developers can write a service in Python, and not only can it communicate with their app, it can communicate via JSON via http — and that gives us flexibility,” Placek said.
Because the code for each logical piece of the app is small, and the services are self-contained, they can introduce new technology and know it’s not going to bleed out into the rest of the system. Microservices allow them to test changes easily and release small amounts of code without disrupting the entire application.
Microservices architecture also enables scalability. For instance, if certain parts of the code need to be higher performing than others, or if the team wants to introduce new technology to parts of the app, they have the freedom to use the right technology for the right job. “We’re not stuck with the one code base and the one environment we chose for the old platform,” Placek said.
While Cloud Foundry doesn’t manage the creation of microservices, DemandBridge found great benefit to running microservices in a Cloud Foundry environment. “It’s ‘fire and forget’ — we deploy a microservice on Cloud Foundry and it takes care of its health and operations and communication with other services,” said Mallah.
Getting out of the infrastructure management business
While converting the old platform has been the highest priority, DemandBridge had other goals, like finding alternatives to deploying application servers that had been deployed as virtual machines on Microsoft Azure. “One of the biggest motivations for us in choosing Cloud Foundry or even Azure is that we want to get out of the infrastructure management business. We don’t want to keep worrying about RAM or networking or does that have enough disk or is that running out,” Placek explained. “We’re engineers at heart. We just want to build a better product.”
Delivering faster results
Being able to work with Spring Boot today and the latest version of Java, DemandBridge has the freedom to spin up new services when it makes sense. “While we could have achieved them with our old code base and with our monolith without Cloud Foundry, it would have taken twice as long,” Mallah said. “We couldn’t afford to take that time.”
Cloud Foundry has also accelerated the release cycle. “Every time we do a release, or put new code up there, it points out that this is only possible, at that speed and with that ease, because we’re using Cloud Foundry.”