 Hello. In this video, we will share our experience with serverless techniques and describe our next-generation digital library platform built on the AWS Cloud. My name is Bill Ingram. I'm Assistant Dean and Director of IT for University Libraries at Virginia Tech. I will be joined in this presentation by Yinlin Chin, Digital Library Architect. After a brief introduction, Yinlin will discuss the technical details of the new digital library platform. We will begin by describing the challenges and technical barriers of building digital library applications. Next, we will present an overview of the Virginia Tech digital library platform and the 12-factor methodology for building software as a service applications. We will describe the process of transitioning from a monolithic digital library architecture into a set of serverless microservices, and we will conclude with lessons learned in next steps. Online access to digital research and educational materials have become increasingly important, and the ongoing impact of COVID-19 has reinforced and accelerated the library's investments and digital resources. Before transitioning to the serverless architecture, the library maintained multiple repository and digital library applications. But the cost of maintaining multiple full-stack applications was becoming overwhelming. Each system has its particular quirks, and it's been difficult to find developers and systems administrators with deep knowledge of these niche systems. Our new system architecture alleviates many of these challenges. And with that, I'm going to turn it over to Yen-Lin to describe the new digital library platform in detail. Thanks, Bill. So digital library performance contains a lot of services, and for each service, it's composed of microservice and management service. So in here, each service focus on one job and do one job well. And our website built on top of each service and to support different needs. So this is a very, very complicated code performance. So how do we build this? We use the 12-factor methodologies. 12-factor provides 12 best parties to enable us to build scalable, maintainable, call-based service. And this methodology being adopted by many companies, such as Amazon, Google, Microsoft. So we apply these best parties to implement our service. So it will require a huge amount of time. But actually, we don't need to build everything by ourselves because we use the code. So many things in here already provide by the code providers. So we use these services. We build on top of these services in order to make our service more scalable in the code. So in the library settings, we alter about five people. So we build our service on top of the AWS service, which is incremented by thousands of engineers. They create these ecosystems. And they do it very well. And they handle many of these we don't want to do. Like they set out all hardware, they handle all the securities, they handle all the networking infrastructures. We just use that. We don't need to build everything by ourselves. We build our service on top of these services. So we can provide a stronger call service as before if we build it local. Also, we follow this principle to build our server-based applications. So we automate every microservice and it's triggered by eBat automatically. Also, every single service have their single purpose and do it very well. And we only use the resources we need. Also, because we build on top of many services provided by the code providers. So we have a more powerful front-end, direct internet with backend service. So we can provide rich and powerful front-end and increase our user experience on top of this. Also, we use dog tools, monitor tools provided by the code providers, which can monitor our applications behavior to help us more understand our applications and then we can trigger all the issues and make our application more better. In the past, we use the three layers of the textures. So everything is in one state. You make a change, you need to deploy the whole entire applications. For the small site, it could be okay. But when our business becomes more complicated, this three-layer architecture is not enough for us to build our library service. So we transfer from the three-layer architecture into the server-based architecture. So after we transfer to the server-based architecture, we are not only provided one user interface, we provide multiple front-end, multiple user interface and also API interface. And under the user interface, there are a lot of microservices that communicate with back-end management service. And the user service do one job and do that job very well. So we can create a different combination of the service pipeline to serve a different kind of the business logic and to support multiple combinations of business needs. And then not only the service we use in the business logic, we can choose purpose-built database. So each database is good at one thing. For example, traditional relational database, we use this to do the transitional data. And we can use the key-value database or we can use document database. And we can also use electric search. So based on a different business need, we can pick and choose and combine different services, communicate with different microservices and provide the service we want to the user. So and then before a site might be just using one stack of software on the built-in. So now we only need to focus on to make our digital library profile stronger, can serve continue adding new features, new functionality into these profiles. And the total one body can support multiple sites and each site can have their own user base, own purpose and provide their service to the user. We still use our multiple development environment. So each site will have a dev site, a test site, and a production site. We still implement our code features and come into the code source control servers such as GitHub. And the difference is that after we commit our code, we let AWS to deploy our code for us. We no longer need to deploy the server, deploy the code by ourselves. We use AWS, we set up a pipeline so they can deploy this for us. Which servers are advertised? Also, in the past, a site at least needs three servers, three environment. So three sites, you need at least nine, 10 sites, you need 30 at least. And also sometimes one test server is not enough. You maybe need multiple test sites. Also, you maybe need multiple dev sites. We have this issue in the past. To handle like, if we want five test sites, five test sites, this is already 10. And handle three different websites. So these are all 20 different servers. So matriarchal servers, it's a lot of work because each site is just a server or either containers. You still have to handle networking, hardware, storage. They require a lot of time to handle that. It's complicated. After we switch to AWS, all the deployment is by AWS. We just tell, okay, we have new features. Give us a server to show our new features. And that's it. We no longer need to figure how to deploy them. How to figure out the details and how the name was saved. We just buy one click, automatically deploy. And then we can have unlimited test site, unlimited test site. And the entire process is fully automatic. So once our code comes into a source code servers like GitHub, you trigger by AWS and AWS create a server, build our code, test our code, deploy it, and verify. Finally, we simply create a link they provide and we can see our new features. Our test, we can test it and to decide if we want to merge into our productions. As of the time we need, take this for example, one build takes like 18 minutes. In the past, 18 minutes, not enough to create a server. So because we can have unlimited test sites, unlimited test sites. So right now we can do like this. So we can have one change, one single pull request can have one site. So this functionality we cannot do in the past using the single local server. So take this for example, we can have four pull requests and four test sites at the same time using AWS. So it's totally different compared to before. And the which increase our productivity of the software development very quickly. So in the past, we allocated a resource. So no matter how the traffic is heavy or is light, we always require a resource. And you can see the blue color in here just wait because we already got a fixed resource. But after we switch to the Microsoft, my subreddit editors, we can more control the resource we use. So we still, this is still a learning process because all the Microsoft it can be tuned and we need to do some tests, but we can more control and more confidence to control this resource we use in the cloud. And when we use more, more efficient under the source, we pay less. This is how local service, you pay less, you only pay your use. So as long as we can use the related resource we need, we pay less for our usage. Also, after we deploy our website into the AWS, the performance is increased because we utilize the H computing of AWS. So our sites not only like support in Virginia, everywhere around the global can have a similar response time of our website. Also, besides compare the performance of website, there are many things we cannot do in the past, but we can do it now on AWS. This is an example. In the past, we need to acquire local server or we'll create multiple server in the AWS in order to process a large amount of the image. After we deploy our code into a serverless intelligence, so in here we use the same code base, use the same programs. The difference is that we package our program into a microservice and trigger the backend AWS service. So AWS will create multiple batch jobs. Inside each batch job is a darker container to run one set of image. Once we set it up, we no longer need to consider how much server we need, we just let that to decide by AWS. We define how much does it need for each jobs and let AWS to handle all the service creation over the container or the state. We let AWS to do that for us. So in the past, we need to spend months to handle the image that I said we have. After we transfer into a serverless intelligence, we just finish in two days and then we can finish more collections and also in two days. Also in the past, once we have a server, we need to install the software, we need to install the libraries in order to deploy our code. But when we use AWS, this managed service is already there for us to use. What we need to do is to kill AWS, how to deploy our service in AWS. So just like we programming our microservice into a Lambda function, for example, we also program programming our entire infrastructure as a code. After we finish this template, deploy a huge set of code service just by one create of the buttons and we can have multiple environment like these contain many different kinds of AWS service and very quickly. Also, each service provided by AWS, they provide a monitor to us. So it helps us to understand our applications behavior, performance, issues, almost real-time. So we can continue to improve our applications and make our application even better and more easily. We don't need to build these one-to-two by ourselves, we just receive it. So this saves us a lot of time, so we can focus more on the create a new service, find more optimal way to make our application more better. Also, the cost model is totally different. In the past, we need to find budget and to estimate the server we need to use, but usually we just acquire more than we need. And also, after server is purchased, we need to human to install or config the server, handle the network, acquire the port, IP address, a lot of things. But now our consideration is, what service can we choose in order to support our business needs? How to create a server is not our concern. And our concern is how can we use these services more efficiently so we can pay less. And also, in the past, the service needs to be always raw, right? So even a service is idle, you still, the server is on, it's continue running as always. But compared to Culp, if the server is idle, then we don't need that server and then we don't want to pay anything and we don't need to pay anything because the server is idle. When there's new requests come in, the server just bring it up and handle the request. And all the parsing is automatically. So probably, so today, we have demonstrated many serverless architectures. We also published all these, all our works in the GitHub is open sourced. So feel free to check it out and see our digital library performance. So in here, I would like to turn it to Bios, so he will talk about conclusion and our future work. Thank you. Thanks, Yilan. To summarize, you could think of serverless services like Lego bricks. We snapped the bricks together to build digital library services. The developers are able to write less code and development time is much quicker. The applications they build are more resilient, secure and scalable and cost efficient than the traditional server-based environment. Another benefit of this technology is the AWS community, which is large and vibrant. There is an abundance of documentation and educational resources. We're looking ahead to building new features and enhancement to our digital library platform. We're exploring AI, machine learning and deep learning services, as well as text and data mining. Finally, we're looking for collaboration opportunities with teams from other institutions who are developing applications in the AWS ecosystem. We're happy to share code and ideas, so please do get in touch. Well, thank you for your time. Here's a link to our GitHub repositories where you can find all of our code. And thanks again.