Zipcar is an American car-sharing company and a subsidiary of the Avis Budget Group that provides monthly and annual automobile memberships with reservations billed by the minute, hour or day. Founded in 2000, Zipcar was one of the very first IoT companies. Today, Zipcar serves one million customers across 10 countries.
Zipcar uses software to manage reservations, memberships, logistics, vehicle-tracking and maintenance programs. “We’re a software company that runs cars,” said Andy Rosequist, Director, IT Operations, Zipcar, at a recent Cloud Foundry Summit.
Doing It the Zipcar Way
The innovative brand began using Cloud Foundry in 2015 and credits Cloud Foundry Application Runtime and Cloud Foundry BOSH with having helped them standardize across all its data centers. But Zipcar’s story is a bit different than other brands.
“We like to do things our own way,” Rosequist said. They do not use the full Cloud Foundry architecture, but have customized components to ensure business runs the way they want it to.
“We really loved Concourse, BOSH, Diego and Garden, but we didn’t like the cloud controller, so we rewrote our own. We’re hyper-opinionated at Zipcar — our deployment orchestrator is built around Docker so we can take all of our services at the same time, let our engineers work on a few of them and then orchestrate them across multiple deployments,” Rosequist said.
Zipcar is currently running:
- 6,000 containers
- 12 BOSH directors
- 80+ services
- 25+ production environments
- Multiple clouds
They run three different products and have built everything on Concourse with standardized Slack channels for engineers.
“It’s very important to us that developers own the code from beginning to end, and that they ship code every day, throughout the day, when they’re ready,” Rosequist pointed out. Distributed teams choose their development language, runtimes and frameworks, which results in varied host configurations.
One of the big questions Zipcar had to tackle was: How do we minimize human error while still being able to fully understand our environments and safely delegate ownership to individual teams?
They looked for solutions that provided transparent communication, lightweight change management, easy and verifiable cascading changes, and managed configurations. In the end, they chose Concourse, as it hit all the checkmarks.
“It’s our goal to enable developers to work with large constellations of microservices at the same time,” Rosequist said. “In addition to all the pieces we love about Cloud Foundry, we also built our own software development kit (SDK) that exposes some of Diego directly into the application.”
By using the proprietary SDK, Zipcar developers can write code and integrate it into the microservices mesh within minutes.
“We want developers to see the business value right away.”
But to do this, Zipcar had to build a lot of work in Concourse to make sure everything fit well.
“We abandoned a few of the factors in the 12-factor model to make sure we could work the way we wanted to,” Rosequist added.
Driving Cultural Change
“It’s wonderful to be able to deploy stuff when you want to, but you have to transform your team,” said Holly Moody, Senior Manager, Software Engineering, Zipcar. “Change is never easy. We started and built a few champions who believed in it. Our Zipcar team had a painful legacy architecture, so there was motivation to transform into something better.”
They also modified a continuous delivery maturity model and use it as a matrix-checklist to track various stages of development, production, data management, culture, service management and disaster recovery. The model helped them know which pieces they need in place for a microservices environment.
Today, Zipcar’s 100+ developers check off items as they go.
“This has helped ensure that our developers can push code out into production and that we are not missing any of the pieces of the puzzle,” Moody explained.
“Testing is very important–both developer testing and also user journey testing — which maps a user’s entire journey through a system. We run user journey tests in production so that we can validate primary money-making paths. It validates that the production architecture is running for your users and finds problems before users do,” Moody said. Concourse orchestrates the testing.
Using Multi-Cloud to Stay Nimble
As part of a larger corporation, Zipcar is determined to continue to operate like a start-up. Using a multi-cloud strategy has helped them do that.
“We’ve always been an agile corporation and wanted to stay that way. Avis Budget bought us in 2013 and so we’ve been able to model for them how we can do this using multiple clouds,” Rosequist explained.
Using BOSH, Zipcar can move among clouds when needed. There was a point at which they were running in three different VMWare environments and needed to move one — Rosequist reported they were able to move an entire production environment into AWS without any trouble.
As for being nimble, they also like to burn everything down, rebuild and redeploy it. Starting over and starting fresh is important to Zipcar’s ability to keep pace with innovation.
“Zipcar uses components of the Cloud Foundry architecture to make things work the way we want them to. We’re different than many companies in that we like to do things our own way, and Cloud Foundry enables us to do that,” Rosequist said.
View Zipcar’s presentations from the CF April 2018 Boston Summit:
Conversation with Holly Moody, Sr. Manager, Software Engineering & Andy Rosequist, Zipcar, Inc.
Strategies For Managing Container Secrets At Scale – Matt Surabian, Zipcar
Concourse All of the Things at All Times – Jason Immerman, Zipcar & Derek Van Assche, HS2 Solutions
