Rafter Inc, formerly known as Bookrenter.com is the first online textbook rental service. The company started with a group of college graduates and has transformed to a large company in the last six years. Here we have insights from Chris Williams, Co-founder of Rafter Inc on how his company is putting DevOps at work. Williams manages the DevOps department and oversees infrastructure automation, deployment and release processes, and platform availability.

As Rafter Inc. started flourishing with growing engineering and product teams, more number of applications hosted on hardware, and developers wanting to use new types of application frameworks, programming languages, databases, there came a need of develop DevOps practices. With increasing complexity of everyday operations and need of developing automation, monitoring, and release processes, Williams experimented with OpsCode Chef and the concept of infrastructure as code. Chef works by writing the instructions for which packages should be installed in Chef server, nodes and Chef workstation order.

“We initially spent several months writing all of the recipes for automating each piece of our existing infrastructure. Once we were finished and could rebuild all of our servers from these automated recipes, it was an incredible weight lifted off of our shoulders. All of our servers were now setup consistently and we finally had a place where anyone on the team could look and see exactly how a piece of infrastructure was setup and configured. Equally important, it also gave us the ability to quickly spin up additional resources with relative ease.”

As number of requests related to DevOps started increasing, the company decided to make DevOps another team in its engineering organization that allowed dedicating engineers that could solve infrastructure problems full time. So what was the benefit?
They were able to do on-demand provisioning. Engineers, who could not easily demo to the business people what they were working on, could now spin up a preconfigured server running their full stack on EC2.

“One of the big wins from this system is that we simply reuse the exact same Chef recipes that we already use to build our production servers. This allows us to flush out many potential issues before they ever land in production. Our Engineering and QA teams can also feel more confident they are testing their new features on servers that are setup identically and run the same versions as our production servers.”

Having an automated infrastructure allowed Rafter to cope with Datacenter Failover in minutes. Besides, they were able to perform shared deployment on their tool Capistrano that managed their deployment. As of now, Rafter team spends 50% of its time on support and alerts, and 50% on project work. And DevOps acts as the coordinator for alerts, performing the initial investigation and finding the right team that can best resolve the issue.

“As our company has grown, DevOps has found a place in between our engineering product teams and operations team. I think of it as a three-layer cake. At the bottom layer is our operations team which is responsible for acquiring and setting up the physical hardware, then in the middle is our DevOps team which is responsible for providing a platform to use these hardware resources, and then the top layer is our engineering product teams which uses the DevOps platform to deploy, monitor, and host their applications.”

These DevOps articles are part of a series published by InfoQ about the process and paradigm of DevOps. While the pulled quotes point out the meat of the information, you can always go directly to the source to get more details “DevOps @ Rafter.”