DevOps at NetApp: “CodeEasy” is the Name of the Game
The shift to DevOps—the blending of development and operations—represents a major change in how software is developed. No longer can companies afford scalability bottlenecks, provisioning delays, or lack of proper test and automation tools. NetApp jumped on board with DevOps early and created an internal environment named CodeEasy, which automates the process of provisioning development and QA workspaces for a 2,000-strong, geo-dispersed development community.
Tech OnTap recently sat down with Kumaraswamy Namburu, manager of build release engineering at NetApp, to discuss why NetApp aggressively embraced DevOps and the benefits that companies can achieve by making their own transitions.
TOT: Why did the NetApp engineering and operations teams decide to adopt a DevOps culture?
Namburu: At first, it was the time savings. Years ago, each of our 2,000 developers used to spend several hours creating sandboxes, doing builds and compiles. The processes they used were inconsistent, which threatened to slow our development cycles, introducing risk and uncertainty. We also realized that our methods at the time weren’t scalable—we had to make a change.
TOT: How has DevOps changed the day-to-day lives of developers and operations staff, and how did you drive adoption?
Namburu: Nothing is in the way of them doing their jobs! Developers are paid to write code—that is what they are best at. They should have self-service, and they should be shielded from any back-end complexity. Once developers saw the value, they came on board quickly. We hit 100% adoption, but it didn’t happen overnight.
TOT: How did the shift to DevOps impact your approach to IT infrastructure?
Namburu: We had to think differently and adopt a different mindset. We are using public cloud where it makes sense, and using NetApp Private Storage to maintain control of our data. To protect our intellectual property, we also built a DevOps private cloud environment. Instead of throwing massive amounts of resources at the problem, we found we could achieve our goals simply by managing our data more efficiently.
TOT: What tools are you using to introduce automation capabilities and save developer time in provisioning environments?
Namburu: We are benefitting from our own technology: clustered Data ONTAP, point-in-time Snapshot copies of file systems, FlexClones, junction paths, non-disruptive operations, and SnapMirror. These technologies integrate with Perforce Helix, the version management system, along with the NetApp home-grown software that we use to automate the entire workflow required to produce a release.
For example, by running one CodeEasy script, a developer can clone any environment and get a full development or QA sandbox with zero storage footprint. They can then replicate the environment to other development sites so that developers and QA teams across time zones can all visualize the code in the same way.
NetApp software, which has been helping developers for years, becomes especially critical when you move to DevOps because it addresses common pain points. Companies that aren’t using these technologies are wasting storage capacity and doing unnecessary work.
TOT: Which stage of the DevOps workflow saw the most improvement from applying NetApp technology?
Namburu: Continuous integration tests (CITs). We run multiple, continuous build every 10 minutes and CITs every 3 hours every day to test changes to application functionality. If a change breaks the build or test, we automatically identify the change that caused the break, automatically back it out, and provide an automated way for developers to reproduce the problem. Because we are using thin clones and snapshot copies for this process, we save on both compute cycles and storage—our DevOps private cloud is scalable for the long term.
TOT: What metrics should a company use for measuring success and ROI with DevOps?
Namburu: It depends on your pain points and what you are trying to achieve. In NetApp’s case, at the end of the day we are measurably improving both time-to-market and code quality. If we had kept doing things the old way, it is unlikely that we would have hit our aggressive development milestones—at least not in the same timeframe. We are also making the most efficient use of our resources, from systems to staff time.
TOT: Do you have any advice for companies just beginning to adopt DevOps?
NAMBURU: Focus on the mindset first—not the tools. Is your pain point SCM? Build? Testing? Performance? Supporting developers at multiple sites? Your pain points will largely dictate the tools you choose, but we’ve seen that just about any workflow can benefit from the rich set of APIs and data management services offered by NetApp storage systems.