\chapter{Future Work}
        % Content Here %
        % To monitor the system's health and to view the latest overall system architecture, a user interface is also to be developed for which the UI layout will be developed using a Wireframe. Further to ensure efficient and scalable operation, fully-fledged workflow automation will be implemented using Apache Airflow. Additionally, a system for regularly backing up PostgreSQL databases to a backup container that would take over in case the primary container fails must be developed to ensure PostgreSQL containers are resilient to unanticipated container failures. Also, CI/CD to automate code build and deployment will be made available to every team.
        
        \begin{enumerate}
            \item Workflow Automation 
                \begin{enumerate}
                    % \item \underline{Containerizing the registry}: We will separate the registry from the DAG, which has currently been set up as a `PostgresOperator', to a separate Python script that fetches the data from the database and can be containerized
                    % \item \underline{Populating the Registry and Knowledge Graph with all the available goals and services}: We will be populating the Registry and Knowledge Graph with all the services that are supported by the various teams and also create workflows and goals out of them.
                    % \item \underline{Containerizing Airflow}: Currently, we have Airflow running as a local deployment. We will move this over to CS Cloud.
                    % \item \underline{Help Other Teams with Services Containerization}: We will cooperate with other teams to help containerize their services, and update the workflow tables with the metadata. Currently, we are working with team 4 to set up a sample service serving a goal.
                    % \item  \underline{Put Everything on CS Cloud}: We plan to incorporate the Airflow component within the VT CS Cloud cluster which can be accessed through Rancher. 
                    \item  \underline{Support Future Services Automation}: Currently, we only integrated indexing, object detection, segmentation, summarization, classification, clean \& parse, and saving objects into the workflow. But services such as topic modeling, or any other coming services could be automated and tested in the future.
                    \item  \underline{Reasoner Optimization}: Currently, we only automated the basic functionality for each service. However, future optimization will be considered such as persisting intermediate data. For example, if two workflows overlap in some steps, the succeeding workflow can directly read the intermediate output produced by the former workflow, instead of executing the workflow end-to-end. See also Section 6.1.10.
                    \item  \underline{System Performance Analysis}: We recommend to run some experiments to consider the trade-off between system performance along with the decoupled services. For example, from a software engineering and DevOps perspective, we ensure each service/container image is simple enough to perform only one task. However, in some cases executing several consecutive services/containers will drag down the efficiency, compared to executing only one monolithic service. Thus, we need to consider merging some insignificant/lightweight services, for better response time.
                    \item \underline{Efficiency}: Google's use of commercial hardware \cite{commercial_hardware_google} to run distributed databases is an industry method to lower costs while also performing on par with multi-core processors. Therefore, this should also be a goal, i.e., to have the capability of processing multiple ETDs without using expensive hardware. This means, workflows should be able to run in parallel but be limited so as to not crash individual nodes. This can be easily achieved with the help of a Queue such as with Apache Kafka or RabbitMQ. Queues need to be durable so that in the event of an outage, the messages in the queue are not lost.  Workflows are queued and a Master uses heuristics to determine if a particular workflow can be run or not depending on various factors such as No. of Workflows in progress, Current Available Capacity of System, whether the Workflow has special requirements, etc. Services can also be modified to run processes in batches, thus eliminating pod spin up time for each ETD or ETD chapter. We suggest, in order to process 500,000 ETDs in a reasonable amount of time, a combination of the above should be used with the aim of using all of the current nodes. While we do not expect 'reasonable amount of time' to be on the order of hours, a couple of days would be reasonable.
                    
                \end{enumerate}
            \item Using Virtuoso
                Team 1's Virtuoso can also be extended to contain a graph of all ETDs and their digital objects. This database can thus contain the entire network of ETDs.
            \item CI/CD
                \begin{enumerate}
                    \item \underline{Unifying Workflow Registry PostgreSQL container with the main one}: As the final step in the project, we need to unify all our Data Models, SQL scripts, and databases into one main PostgreSQL instance as we do not want multiple containers running PostgreSQL.
                    \item \underline{Unit Testing}: To prevent developer errors from being pushed to the Cloud, Software Testing is important. Various tools are available that help with automated testing. These tools can also be integrated into a CI/CD pipeline, thus enabling a complete development life-cycle. For improved testing, the concept of Code Coverage should also be introduced, thus lowering software bugs. For UI based testing, tools such as selenium and Browserstack are popular. For server testing, PyTest for Python can help.
                    For JavaScript, Supertest and Jest are popular.
                    
                \end{enumerate}
            \item User Interfaces
                \begin{enumerate}
                    % \item \underline{Workflow Management Page}: We have created a landing page for managing their automated workflows, goals, and services. We need to integrate the UI style and the website itself more closely to the pre-existing, central front-end website and deploy it to allow other teams to input details about their containerized services. The Reasoner/Workflow/Service mapping table will allow users to select from metadata tables and able to insert rows for mapping. Eventually, also use this page to show the results of the system.
                    \item \underline{A System Health Monitoring Dashboard}: 
                    %\emph{As a stretch goal}, we plan
                    Another suggestion is
                    to have a monitoring system for easy viewing and analysis of the various containers, their health, and activity, along with tracking the logs of the various API calls made between the system parts.
                \end{enumerate}
            \item Migrations and Public Cloud Usage
                \begin{enumerate}
                    \item \underline{Migrations}: What if this system needs to be migrated to another Kubernetes instance? Thankfully, the use of Docker has simplified migrations as we no longer have to worry about dependencies or architectures (except arm/arm64). 
                    To add to the ease of migration, each Deployment in Kubernetes has its own yml file which can be run to spin up an identical Deployment on any Kubernetes instance. The only major hurdle is Ceph and Camelot. Our current setup is very tightly coupled with Ceph and Camelot.
                    %(both are Filesystem. 
                    Camelot contains all 500,000 ETDs and Ceph contains Team 1's PostgreSQL data and Team 2's Elasticsearch data.
                    %) and hence are the main bottlenecks. 
                    \item \underline{Public Cloud Usage}: Migrating this system to a public cloud like Amazon Web Services, Microsoft Azure, or Google Cloud has a fair number of advantages. Firstly, there would be access to better compute and storage. 
                    %For example, Multi GPUs nodes for workflows which needs multiple GPUs, Multi Core Nodes for workflows that require immense computing power, High Memory Nodes for memory intensive workflows are just some of the configurations available. 
                    Some of the configurations available include:
                    Multi GPUs nodes for workflows which needs multiple GPUs, Multi Core Nodes for workflows that require immense computing power, and High Memory Nodes for memory intensive workflows.
                    See for example, Amazon EC2 Instance Types(\url{https://aws.amazon.com/ec2/instance-types/}). 
                    For Deep Learning services that utilize TensorFlow, Google provides TPUs (Tensor Processing Units).
                    This involves Machine Learning based Hardware Accelerator Application-Specific Integrated Circuit (ASIC) technology, which provides much better performance than GPUs for specific AI workflows. 
                \end{enumerate}
        \end{enumerate}
	    % Content Here %
	% \chapter{References}
	
	
	% This is the standard bibtex file. Do not include the .bib extension in <bib_file_name>.
	% Uncomment the following lines to include your bibliography: 
	%\bibliography{<bib_file_name>}
	%\bibliographystyle{plainnat}   

	% This formats the chapter name to appendix to properly define the headers:
% 	\appendix

% 	% Add your appendices here. You must leave the appendices enclosed in the appendices environment for the table of contents to be correct.
% 	\begin{appendices}
% 		\chapter{First Appendix} \label{app:appendix_one}
% 			\section{Section one} \label{ase:app_one_sect_1}
% 				\lipsum[1-3]
% 			\section{Section two} \label{ase:app_one_sect_2}
% 				\lipsum[1-3]
% 		\chapter{Second Appendix} \label{app:appendix_two}
% 			\lipsum[2]
% 	\end{appendices}
\bibliography{reference}

\bibliographystyle{plainurl}