I recently had the opportunity to attend my first DevOps4Lib Summit graciously hosted by the folks at Princeton University. The summit is a relatively small and informal two-day user meeting with an unconference feel that focuses more on the technical infrastructure and operations sides of library technologies. It originally formed as part of the Code4Lib community, and now has either one or two in-person summits per year. As a member of an institution that’s just starting to grow and standardize its DevOps practices, the meeting provided a valuable opportunity to meet face-to-face with other professionals working through the same infrastructure issues and learn from their experiences.
For those unfamiliar, DevOps is the practice of combining development practices with tech operations in an attempt to create a seamless workflow from development to launching and updating systems. DevOps is a critical next step in the D-Team’s approach to working with systems and I really wanted to learn as much about it before it became a problem (or more of a problem). I went into the summit knowing little, and came out knowing a little more, but I saw a lot of parallels to themes we think a lot about already in archives: sustainability, continuity, maintenance, and collaboration.
The first session of the conference attempted to define what DevOps meant to the attendees and get everyone on the same page. The conclusion we came to is that DevOps is less a list of tasks that people did, and more about caring about what you’re delivering to a wider community. DevOps cares about how something works, how to keep it working, what the maintenance cost of it is, and how to use technology to reduce reliance on a single person or workflow. The ultimate goal of DevOps is to set up technological infrastructure in a way that helps others consistently succeed.
I immediately saw a lot of synergy between the defined DevOps goals and one of the D-Team’s guiding value of engaging and empowering users working with technology. Good DevOps wants to make IT infrastructure as easy to maintain as possible, mostly automated, and works closely with key stakeholders to understand potential issues and enhancements. Everyone at the summit was trying to create the best workflows for the developers they worked with while also trying to ensure the best end-user systems experience as possible.
The group identified some of the core tasks in this attempt as: documenting processes so you can share the load, approaching to how to set up the infrastructure to help developers consistently succeed, identifying and eliminating bottlenecks in a process, and removing single points of failure. Different institutions used different technologies in the pursuit of these goals, but the focus remained on helping others work with library systems by making the process as easy as possible. The opening session reinforced that if we’re committed to engaging and empowering our users’ to work with technology in sustainable and reproducible ways, we need to get better about growing our DevOps skills.
After setting the stage, the next two days of sessions gave me strategies and tools to bring back and explore at the RAC. We’re a relatively small institution compared to a lot of other libraries and archives concerned with DevOps, so not every solution will be the best fit for us, but a few immediately stood out. With our upcoming move to AWS, an eventual implementation of Ansible for IT automation seems like an easy target. Additionally, a few institutions at the summit are using internal service level agreements to help define incident responses and the responsibilities therein; documentation is an easy way to help clarify roles and responsibilities for all involved. We also could improve the way we handle our system logging because right now we’re not doing much or anything with log rotation or analysis to really show us where are systems are running into issues. And finally, some containerization tools like Kubernetes could really help us streamline our deployment processes rather than the rather ad hoc approach we have now.
Ultimately, I think the RAC has incredible potential for incremental growth into DevOps best practices. I’d recommend the DevOps4Lib summit to anyone thinking about DevOps, even newcomers that aren’t doing much DevOps currently. It can be difficult to think abstractly about what you should be doing when you don’t have a ton of prior experience, and the summit was helpful in providing an intimate environment for thinking and talking through issues, not to mention all of the cool tools and systems you’ll learn about. It has becoming increasingly clear to me that the underlying concepts of DevOps parallel those of libraries and archives. We have a long road ahead to get to our version of “best practice,” but I have confidence we’ll be able to get there by collaborating with others at the RAC and in the greater community. I look forward to returning to DevOps4Lib next year!