Cloudbook's IT infrastructure was typical of a tech startup -- running the LAMP stack and developing its marketing storytelling software in a low-cost hosted environment for about $5 per month. But shortly after the company launched its product in 2012, it signed customers around the world and had to rethink its hosted IT environment. One of its primary objectives? Avoiding cloud computing vendor lock-in.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Vince Vasquez, CEO of the San Carlos, Calif.-based company, was at Sun Microsystems for many years. In addition to working with Solaris on-demand and Sun Cloud, Vasquez experienced how a large IT company like Sun treats its customers according to size. Larger customers receive more personalized attention -- it makes good business sense. So when Cloudbook entered the scene in 2012, Vasquez knew his little startup wouldn't get the kind of personalized support it wanted from big cloud players like Amazon.
Cloudbook software gives enterprise sales teams a way to sell their products through storytelling software that creates videos and books detailing the elements of a product to be sold.
"If I'm Netflix, that's one thing," he said, referring to one of Amazon Web Services' largest clients. "But if I'm a small customer, I didn't expect that I would get much help."
Stay local and avoid lock-in
Vasquez doesn't count that as a knock on Amazon: It's one of Cloudbook's four cloud providers, along with HP, Datapipe and Layered Tech. His point was only that he didn't want cloud computing vendor lock-in. He didn't want to be beholden to one cloud provider's APIs, and he wanted access to cloud services close to wherever his customers might be.
Vasquez isn't alone in his concerns. TechTarget's fall 2013 Cloud Pulse survey of 825 IT professionals found that 20% think portability, interoperability and migrating to a new provider are challenges with the cloud computing model.
With Cloudbook's early customers spread out all over the globe, including the U.K., Malaysia and India, the company had to reassess whether its hosting environment was up to the challenge. "We have a customer out of Nigeria," Vazquez said. "At first they said that they liked our service but they weren't sure if we could handle their business. For us to serve Nigeria, we weren't sure the latency would be able to handle that. We were only in one small data center at the time."
Having Cloudbook's IT infrastructure hosted in multiple data centers across the world was a positive to that end, but it too presented hurdles. Cloudbook had to determine a way to automatically transition a customer's information to the nearest cloud if one of its hosted data centers went down.
One possible answer was AWS Availability Zones, which provide replication and service across multiple Amazon data centers. But Vasquez didn't want to devote staff to learning and managing Availability Zones -- at risk of cloud computing vendor lock-in -- instead of putting IT resources toward Cloudbook's business model.
"I'd rather use my development resources in getting closer to what solves our customers' problems," he said.
Cloudbook has no database administrators on staff, and Vasquez didn't want to hire one simply to manage and replicate MySQL -- the "M" in the LAMP stack -- across multiple data centers.
Point, click, deploy
So Vasquez turned to MySQL database as a service (DBaaS) provider GenieDB, whose product by the same name has a user interface for the customer to point, click and deploy MySQL instances with various cloud-service providers across the globe. It tracks system use by database instances and has automated services for disaster recovery and backup.
Vasquez said that GenieDB results in a 30-second maximum window of downtime for Cloudbook's customers. If a Cloudbook customer tries to log in at the exact time its local cloud goes down, it will get service from the closest cloud in 30 seconds.
"The other part is that I didn't need any database resources," Vasquez said. "I didn't have to go to NoSQL or another database built for replication."
Mark Fontecchio may be reached at firstname.lastname@example.org or on Twitter @markfontecchio.