 Get the show on the road, okay Welcome to our session today. We're delighted to have you here. Thanks for coming We're going to talk about DevOps and before we get too far into this. I want to introduce our My co-speaker many of you know me. I'm sure Carl Grant. I'm the associate dean So when my superstars is right here and if you've got this Issue of library journal last month with the movers and shakers you'll see a very familiar face right there So this is one of the 50 people selected from over 300 people around the country and so I'm really thrilled for her and so Congratulations to I love coming here and introducing a new mover and shaker. So I've had the joy of doing that three times out of the last four years So we were doing pretty well and mentoring young people and bringing them along in our organization and I'm really proud of that So we're going to talk today about a Number of topics. This is your first take away list to get to in the session one beginning one at the end First we want to tell you a little bit about what DevOps consist of and The basics of its usage and then we're going to talk to you about how we've applied it to library museum exhibitions Which I think we will have some pretty good examples there for you to look at and see the Advantage of using this kind of technique and then we'll try and take some Q&A and then as I've worn twilight You're going to see a blur because my flight boards at 12 o'clock I'm going to be tracking out of here twilight will answer questions All right So what is DevOps a lot of people really don't know what that means they hear the term I've heard it several times in sessions throughout this conference But I'm not sure everybody knows what it means and then what it's really talking about is the way you do your operations Reliably and trying to make sure that they're reproducible and programmable Because if you can do that then you can write a program to do it for you and that's what you really want So if you're creating nodes in a hosting facility, we're all spinning up You know modules and stacks in Amazon web services or a lot of us are and that's a totally Automatable process and so you know rather than you know creating a new stack and paying for it on a continuing basis You can go in there spin it up run the task run it with automated testing Utilities take it down shut off the billing and you're you're ready to go and so it becomes a very Efficient way of doing that kind of work and so we're we're increasingly doing that So I like the line at the bottom there if you're not writing software to manage these processes You're not surviving. You're just building this quagmire of overhead that you're going to end up getting caught in and that's something You can't do so infrastructure has to become code and infrastructure is not just software. It's hardware The new system and has you know won't be powering down a machine They replace or replacing a failing drive reboot all that usual routines They'll write software to detect a misbehaving EC2 instance destroyed bad instance spent up a new one and configure it all no interruption in service So that's where you want to head Obviously and the implication here is that operations really becomes part of development This is where the DevOps name comes from because you're merging those two pieces together And so the name DevOps comes from that intent What there's a number of books that I'm listing them here on the left I hope you're capturing these you'll get it from sides if not But this one is actually a fictional work written about DevOps story and it's a fascinating book and it's filled with It's filled with characters. You will recognize When I read it I kind of put people's names next to the various characters in the book because I knew exactly who they were talking about in our Including myself. I found myself in there Twilight I asked her to do the same thing We're going to compare notes when she gets done with reading the book But it points out in this book There's really four types of work that you're doing in your IT department today And once your business projects, these are new things that you're you're planning to do And new projects you're creating. There's internal projects overhead maintenance Those kind of things changes, you know tweaks to the software that your users are asking for and then there's unplanned work Which is where you kind of get slammed a lot of times with things You don't know that's coming at you But you know the provost office calls or the president's office calls or Dean's office calls and says I need you to do this Okay, well, that's unplanned work and it's really kind of a big hit on your workflows So we all deal with that and the reality is we know that we have a small number of resources people machines and processes that dictate the output of our IT flows and and development workflows and Managing the that is really important because that becomes your constraint and that's where you have to really focus on Implementing DevOps because it becomes your critical path for doing any kind of work Whatever is the fastest you can push work through the constraint That's the fastest you can do work and that becomes a real challenge to deal with so the way you manage the constraint Identify it we've done that in our operation and you know There's a couple of people and if you read the Phoenix project You'll find that person in that book well identified You'll recognize them when you read it that everything has to funnel through in order to be touched because they can fix anything They're like the all-purpose do-it-all they know everything but because they're doing it all manually They actually become a very critical bottleneck in your process And so this is you know the work they're doing is work You want to automate and try and get it off their desk so they can be focused in places where they can add real value So basically what they're saying there is don't waste their time make sure you're not wasting their time Subordinate that they constraint to make sure that all the work Arrives at the maximum rate they can handle if they're operating at the top efficiency in order to push it through and that'll be The flow that your system can maintain your ability to take on new projects So on and so forth so if you do this if you put in these kind of Processes then it enables faster release of new features happier users and increased employee productivity And that's what we've tried to do in our shop now. We don't have this fully implemented I'm not going to tell you it's all there in fact We're going to show you in it one example where we couldn't do that We're going to show you one example where we did and the difference it makes so I think that would be pretty compelling for you to see I Also like this this explanation the Phoenix project, which is there are three ways things go through our departments, right and And the way you want to get it done is small batch sizes continuous builds integration Testing and never making sure I'm making sure you never pass defects along in the system It's only you want to keep everybody focused on what's the organizational goals? What are we trying to get done? The second way is a constant flow of fast feedback across all steps and a shared goals in a plan So if you're getting all your team focused and the merged development operations together These are the kind of things you want to be working on and then there's this idea of creating a culture of experimentation It's okay to take risk. You know that you're going to have some failure There's no penalty on that as long as you learn from them and move forward and repetition and practice our prerequisite for this To be mastered and it does happen as you as you allow for that So at that point I'm going to turn it over to while and let her tell you what what she's done with it So I want to start by telling you a little bit about how we came to merge DevOps with our exhibit websites Our flagship project for our exhibits program was called Galileo's world and it contained over 300 items from his lifetime and We realized very quickly that we had a real opportunity To not just build a companion site to this exhibit But to build an experience for users And when I say we I really mean an incredible group of colleagues a very dedicated and inspiring curator And so it took a lot of people to be able to do this But what it did is it really shaped the way we Approach exhibits so we knew we had this rich resource of material and What we wanted the user to experience was to be able to flip through a first edition Galileo work Page by page and then to zoom in to see the handwriting in the margin And this this again is shaped how we approached exhibits to come And our first priority with our exhibit sites is to build engaging user experiences We want users to interact with the material and ultimately we want to drive them to our physical space to see these things in person And so our exhibit websites really focus on having a one-to-one Representation if it's an exhibit item that's on physical display. We want it to be represented on the website as an individual item We want to have contextual rich taxonomies that link all these items together so that it's easier to browse and explore these exhibits We want to have rich resources for them open educational resources Supplemental resources so that this is not just a brochure wear site. It's an experience. They can come to and really learn about the topic Open educational resources which I mentioned But really We saw this as an opportunity it was going to be a big investment of time and we wanted to make sure that we could capitalize on this in the Future that we could reuse code and architecture and that we could build on this as each new exhibit site came up And so the innovative piece was not just creating an innovative website It was rethinking our approach to building websites all together so The first before we get into this the first thing I want to mention is that the DevOps is not a role that a single person Or a unit does in your organization It's a culture that you embrace and it's not a tool that you purchase to do DevOps with It's a methodology that you apply to the tools that you already have and I say this because we Apply it to web design in some really interesting and practical ways and what this lets us do is be we gain a lot of benefits from this We are scalable so for my team. It doesn't matter if we have one exhibit item or a thousand It lets us be efficient. We can upload hundreds of pages of content in minutes It lets us be programmatic, so we try to automate our workflows wherever we can and One of my favorite parts is it's reusable which means the next time you approach an exhibit site You can push some of the site development down to your non-technical staff members Or maybe just other members on your team that are not your developers to set up these sites because these Pieces are reusable and that leads us to our our most exciting benefit, which is innovation So I went to the Sun setting Presentation yesterday. I don't know how many other people went to that but I found it fascinating I was excited to see that because they really highlighted how slack time Creative time helps your developers be innovative and that's what we are really trying to focus on by applying this methodology to exhibits So I have three practical applications for you Content this for me is the unsung hero and it often is very overlooked But it's where you can save hours and hours of time when you're developing your site Our back-end processes. I have an example for you where we were able to automate our digitization process again hours and hours of Loading objects manually into your repository and then finally our infrastructure Now we're not like Carl said completely to our vision We just presented him with a new DevOps strategic vision for this year And it includes many of the things we've already done and just enhancing them with these additional things like automated development environments Code deploy. I'm really thinking intentionally about our software developer lifecycle testing monitoring and alerting So I want to start with our first practical example, which is content Again, it's I feel like one of the most powerful areas and one of the most overlooked when we're applying these DevOps methodologies It starts with structured content. That's also called content modeling or content types there's an entire profession around content strategy that we were able to pull from and basically it just means grouping content into a Logical group and then breaking it down into its distinct and individual parts I use events here because it's the most Accessible example I have but we all know that there are certain ways to break down events events need a name a description a start time and end time a location and so Once you have your structured content You can use a content gathering tool and it doesn't have to be fancy We use Google spreadsheets because they're collaborative. They're easy to use and The the columns become your data points and the rows become your individual pieces of content So what this allows you to do is your curator your subject expert or your content specialist Whatever whoever plays that role in your organization can go out and start working with your subject experts to gather this content At the same time that your developer your database admin your site builder is structuring your database to match these fields and Then at the very same time your graphic designer front-end developer is creating a template based on these fields All of this stuff can happen concurrently at the same time throughout the planning process and then a month a week Before your site is ready to launch You do a very simple content import and it goes from the spreadsheet to the database and onto the website And that's how we were able to Populate Galileo's world with content so quickly and I'll show you some more statistics on that a little bit later So these are some reusable content types that we have built Our import spreadsheets are already developed because we've already agreed on a lot of these fields So they can be spun up very quickly by somebody who is not a content specialist or a database administrator Used to start collecting content for an exhibit and Every time we do a new site we can add to this Toolkit now this is my second practical example for you. It's the way we were able to automate the Loading of our digital content into our repository So the blue arrows here are human processes the green arrows are Automated programmatic processes that we were able to build and What we walk through here is an exhibit item is selected to be put in the physical exhibit It moves on to digitization where then it is enriched with metadata In our instance it goes to a local server where there is a directory using the bag it protocol I don't know if anyone's familiar from that It's really used by Library of Congress and it really it's just a way to bundle Disparate things like files and metadata and images together and transfer them along So we transfer them from our local storage to Amazon web services using this protocol And it ends up into a local infrastructure that we have built called our data catalog And this allows our front-end to switch out if we ever need to move our repository It's going to stay in that data Catalog we use a celery worker protocol To automate our tasks. So this is where the information goes from the data catalog into our island or a repository And then eventually on to our library website. Now you see that arrow right there is blue Because we had some technology switch out and so the next time we revisit this process We will go and make sure that is automated, but what this does is it allows our Teams to really not care if your exhibit has one item or a hundred items As long as we give it enough time for those items to work through the workflow It also reduces human error as Carl was saying that's one of the real benefits of the DevOps methodology and automating is With 373 items in our exhibit There's a lot of human error when you're trying to upload things to a system and then finally our Infrastructure and this is something that we are still working on building But I think the point here is that if you want to be able to be innovative and to really push the boundaries every time You come up with a very exciting exhibit You need to be able to reduce the amount of time that your developers spend on the fundamentals So you want their code deployment to be lightning fast. They're testing to be automated You want them building things that they hand off to others to maintain or to set up the next time DevOps methodology combines that development process with the operation side of the house in this cohesive Continuous feedback loop and I think this diagram really illustrates the fluidity of that process So we have some Tools just to give you an example of what we mean when we say DevOps and I'm not going to go into these In much detail because I feel like maybe that's a whole other talk But just to show you that all of these are extremely important Investments in your infrastructure to help reach these goals. So deep health check monitoring Rapid code production the continuous integration platforms These are some of the tools that you're going to want to be thinking about if you're going to move more and more into the DevOps methodology and I think the point too is that This will not be accomplished by a single tool set Really, it's a suite of tools that a DevOps engineer who understands both the operations side of the house So your sys admin skills and who understands development Can piece together a tool set that is right for you and your organization in your workflow So that's the more traditional model of DevOps applied to our infrastructure Yeah, this is a combination of open source and paid third-party paid vendors and This is part of our presentation that we did to Carl this year. So he could really understand where we were trying to get to So now I want to compare two exhibits one exhibit where we did use the DevOps methodology And how long it took and the investment of resources and one exhibit where we were not able to So like I mentioned earlier Galileo's world Was designed to celebrate the hundred and twenty-fifth anniversary of oh you so it had some very big goals It includes 20 exhibits at seven locations across three campuses It has over 300 volumes from Galileo's lifetime Including works that contain his handwriting and signatures These materials were digitized Given rich exhibit related metadata They were embedded into the website using the internet archives book viewer So that you could flip page by page and each exhibit item was given a rich Narrative about why it was important to the exhibit like I said We had a very inspiring curator who was able to pull all of this content together for us The themes included every facet of scientific advancement and it featured materials like rare books But it also had scientific instrument replicas it had student projects and We even and digital resources and there was even a 16-foot replica of the Leaning Tower of Pisa Built for the lobby of our library It's very impressive It was supported by a lot of programs so there were lectures stargazing parties presidential dream courses documentaries The list just goes on a symposium It was a very rich exhibit and I tell you this because I just want you to get a sense of the Colossalness of the exhibit that they were planning Because really we had a really big challenge to create a website that was going to do it justice The website ended up being 640 total pages 20 of those were galleries. We had some sections 373 was our final exhibit item count 93 supplemental resources it was supported by four taxonomies with 84 terms Anywhere from chronological period to subject to region And just so we get a sense of an individual item page It was supported with 20 content fields that include citation information location. Where was it in the seven? location three campuses Subjects exhibit made a data and then of course the full text viewer where you could flip through the pages So again, just a really colossal robust site the Exhibit I'm going to compare it to is our poetics of invention exhibit which came after Galileo's world The big concept for the poetics of invention was to explore an idea as it was taken through the invention life cycle We specifically used the invention of an OU professor who is not just a scholar But also an innovator and an entrepreneur He created an invention that was a mobile app that makes English more accessible to the 350 million Chinese learners and he did this by merging the world's two most spoken languages at the level of their phonetic DNA through the use of Pollution tables poetry and the development of a new alphabet alphabet. So it was a very rich Content exhibit, but it was also a very small Focused exhibit designed to serve as an interim while we worked on our next big project So while the concept was very rich and bold. This was only on the main exhibit of our libraries main library location it was a single exhibit on one campus and The total pages for the site a hundred and thirty five pages So that's a fraction of Galileo's world. It was one exhibit with eight rooms 40 sections It had 25 exhibit items. Not if you remember the other one had 373 and one resource even and zero taxonomies Even the content that we displayed per item was was just this again This is an interim exhibit So it was a couple of images and a couple of description fields So a much smaller exhibit website This is the fun part Now we're going to compare what it took to build both of these sites one using our DevOps methodology and one not so Galileo's world started in December of 2014 and The physical exhibit opened in August of 2015 so an eight month time span and we finished the website on time August of 2015 It took about an hour of content importing and that was because we had more than one content import spreadsheet And we had some cleanup to do and we wanted to check through some things site building about 800 hours now I know that seems like a long time that spread out over eight months and We did a splash a small splash site To stand in place of the exhibit site so that marketing could start many months earlier. This includes planning meetings 60 hours of theming 20 hours of content input that would be things that were not included in the content import like special customized pages Poetics of invention on the other hand started in May of 2017 the physical exhibit launched in September of 2017 But there were items still being done on the website in December of that same year So that's eight months for poetics of invention. So the same time even though the site was a fourth of the size We were not able to use a content imports, which I'll explain why in my next slide So we were not able to use content imports site planning and building took about 200 hours theming took about a hundred hours and Content input is where we really took a hit and that was 400 hours of content input Whereas with Galileo's world, we were able to create pages in an hour Poetics, and I cringe when I say this every single page was made by hand So why couldn't DevOps help the poetics of invention exhibit site? Well first of all we got our content in Photoshop files that were designed for murals and large panels So the content had to be extracted both English and Chinese the images had to be extracted they were Optimized for print graphics. So then we had to scale them down and this had to happen for every page we built Content was not finalized until almost right before the exhibit opened Some content was actually not provided to us until after the physical exhibit opened Content was not structured for the web meaning murals are very horizontal a web page is usually vertical So it's you have to rethink your design in order to translate those into a web page Digitization did not go through an automated workflow, and that is because there wasn't any items to really digitize We didn't get the content in early enough boutique photography was done after the items were in the display cases And we were not able to reuse much code or content types. There just wasn't the overlap I think events might have been the only thing we reused So ultimately there was no automation. There was no scalability. There was no efficiency It was a very eye-opening to collect these statistics for this presentation I knew this obviously it took eight months But it wasn't until I started to really analyze it that I really understood the full weight of the example So let me just interject a real quick part of what happened here is we had another large exhibit plan that we have been working on and We finally came to a point where we said this isn't this isn't going to hit our balls It's not achieving anything we wanted to achieve So we yanked that one out and then we were down to a few months to put in an entirely new exhibit because we knew We had to follow Galileo's world with something so that was why we kind of turned to trial and said You know do what you can here's what we got to work with And so she should take more credit for working a minor miracle and still getting the website up and running for us Yes, it was yeah, it was a little bit of a shifting around in our exhibits calendar. Yes So the reason DevOps made Galileo's world so successful is that again? We were able to eliminate hundreds of hours of content entry and again. I just want to emphasize our curator It worked tirelessly getting this content into the spreadsheet Automatic loading of digital items Reusable content types again. These are things we've already talked about These are just some of the the ones that were very impactful for us and Then most importantly teams were able to build separate pieces and in the end bring it together So For me the takeaway is that You really have to start your planning and you have to think about this in a holistic way through your organization And you can't push these methodologies just down to your tech teams it has to be something you embrace together and That when you apply these methodologies and you save your development team times that is when they can be truly innovative That's when they can take on a project like an interactive map or an interactive timeline or an automated workflow For digitization and so that we want to protect that time from them and not have them spending their time Doing routine fundamental tasks I'm going to actually hand it off to Carl to do the final conclusion All right, so the last things we hope you'll take away that's while I just said plan before you build By all means don't learn from our mistake You got to have that time if you don't you got a real problem Merge your DevOps teams together that is a takeaway here Those teams need to become one and they need to work in a continuous flow as you saw in the diagram And when that happens they can all be working very much in parallel and achieving good things Use tools again a lot of times I find developers all want to you know They want to tweak it and do it themselves They need to use these tools and so that takes some pushing and a bit of shoving to make that happen But you can make it happen and while it's done a very good job with that Look for those constraint processes because that really does affect the entire flow and production capability of your Organization so when you find that constraint look at what can be automated that that is flowing through that constraint person and Try and get it automated so you can optimize their time Do things programmatically we use the restructure code as well as content And your systems and all of that has to be integrated together I love I mean we used to spin up virtual machines all over the place and we'd leave them running for months Paying for them and then we finally had some them open our eyes to DevOps being able to go in spin it up take it down turn it off and Save a lot of money Which is great and built for scalability, which is you know what twilight has done with Galileo's world We will be able to reuse in future exhibits, and that's exactly what we've done We've shown it can scale to a very large scale And we can develop more automated testing tools to put in front of that We haven't done all of that yet, but that's all work that we're moving on So I think we would say we are very much fans of DevOps twilight and her Leader in the DevOps area is Pointed out to me that we really shouldn't be calling any area DevOps because it is just a methodology And it really applies to more than just the hardware and the software as she's showing here We're using it on content So the same benefits can be derived in a number of different areas if you think about it the methodology works And if we apply it in more spots then we can get more out of it So it's not not really shouldn't be tied to an IT group necessarily This is a methodology that I think has far wider applicability than we're thinking about All right, so we got time for some questions as well if you have