project proposal

chapters/devopsProjectProposal.tex

@@ -1,19 +1,111 @@
 \chapter{Project Proposal}
 \ChapterLabel{ProjectProposal}
-\index{GitHub Actions}\index{Jenkins}
+\index{Inviscid}\index{Prometheus}\index{VictoriaMetrics}\index{observability}
 
-\section{Proposed Tool: GitHub Actions}
-We propose researching GitHub Actions and comparing it with Jenkins, which
-will be introduced in class. GitHub Actions interests us because our group
-already uses GitHub to maintain source code and documentation. We want to
-understand how repository workflows can automate the build, testing, and
-deployment of our Dockerized website to AWS.
+\section{Inviscid: Simple Monitoring for Small Web Services}
+Inviscid is a proposed customer-facing startup that helps small businesses
+monitor the health and performance of their web applications. Customers would
+use a dashboard to view availability, response times, request volume, and
+error rates. The service would pair these measurements with plain-language
+status summaries, such as ``Your website is responding slowly,'' to help
+customers recognize problems without requiring extensive monitoring expertise.
 
-Our comparison will consider setup effort, workflow configuration, and
-visibility into build and deployment results. A future demonstration could
-provide a manually triggered workflow that builds and deploys the application.
-For this proposal, no installation or implementation of the comparison tool
-is claimed. The current proof of concept is the manually deployed EC2 website.
+The semester prototype will focus on one demonstration customer application,
+building on our existing Node.js website. The broader startup concept is a
+future direction; customer account management and support for multiple
+customers are outside the initial prototype. Our current proof of concept is
+the Dockerized Color Buttons website deployed on AWS, documented in
+\ChapterRef{CloudDockerDeployment}. Monitoring and deployment automation are
+proposed work rather than completed features.
 
-% Draft selection based on the earlier discussion: both authors should confirm
-% GitHub Actions versus Jenkins before submitting this chapter.
+\subsection{Sample Customer Task}
+A customer opens the Inviscid dashboard to check their website's health.
+During a controlled demonstration, we will generate normal traffic and then
+introduce slow responses or failed requests in the sample application. The
+dashboard should display the resulting changes in response times and error
+rates, accompanied by a short status summary explaining the problem.
+
+\section{Proposed Development and Operations Tools}
+GitHub will provide source control and collaboration, and AWS will provide
+the deployment environment. Table~\ref{Table:InviscidTools} lists the planned
+stack. Entries marked undecided are candidates, not commitments; the team
+may revise them as implementation requirements become clearer.
+
+\begin{tabularx}{\linewidth}{L{3.2cm}Y}
+\caption{Tentative Inviscid Tool Selection\label{Table:InviscidTools}}\\
+\toprule \textbf{Purpose} & \textbf{Tool and status}\\ \midrule
+\endfirsthead
+\toprule \textbf{Purpose} & \textbf{Tool and status}\\ \midrule
+\endhead \bottomrule \endlastfoot
+Source control & GitHub; selected.\\
+Application & Node.js and Express; proposed, building on the existing website.\\
+Container packaging & Docker; selected.\\
+Deployment & AWS EC2; selected for the prototype.\\
+Metrics backend & Prometheus and single-node VictoriaMetrics; selected for comparison, final backend undecided.\\
+Dashboard & Grafana or a simple custom dashboard; undecided.\\
+Automated testing & Node.js's built-in test runner and a traffic-generation script; undecided.\\
+Deployment automation & GitHub Actions for a manually triggered build, test, and deployment workflow; undecided.\\
+Customer/settings database & Amazon DynamoDB, if persistent customer configuration is needed; undecided. Metrics will be stored in the selected metrics backend.\\
+Security checks & GitHub Dependabot and automated dependency checks; undecided.\\
+\end{tabularx}
+
+Our longer-term goal is a deployment pipeline that can be initiated with one
+button press. The proposal does not claim that this pipeline is implemented.
+
+\section{Research Question and Planned Comparison}
+\begin{quote}
+How do Prometheus and VictoriaMetrics compare as metrics backends for
+Inviscid's prototype in terms of configuration effort, dashboard integration,
+query response time, and CPU, memory, and storage usage?
+\end{quote}
+
+We selected these tools because both can collect and query application metrics,
+and VictoriaMetrics can scrape Prometheus-compatible endpoints. This allows
+us to reuse the instrumented application while investigating different
+backend implementations. Prometheus includes metric scraping, PromQL queries,
+and alert-rule evaluation. VictoriaMetrics provides metric collection and
+storage with MetricsQL queries; alert-rule evaluation uses a separate component
+such as \texttt{vmalert}. Supported configuration options and query behavior
+will be checked rather than assumed identical.
+
+We plan to compare Prometheus with single-node VictoriaMetrics using the same
+application, metrics, traffic workload, collection interval, retention period,
+and equivalent AWS resources. Configuration effort will be documented through
+setup steps and difficulties; dashboard integration through the work required
+to display equivalent measurements. Repeated equivalent queries and controlled
+traffic will support measurements of query response time and CPU, memory,
+and storage usage. Results will apply to the tested prototype and workload;
+we will not assume that either tool is faster or more resource-efficient.
+
+\section{Preliminary SWOT Analysis}
+Table~\ref{Table:InviscidSWOT} evaluates each tool independently in the context
+of Inviscid. Strengths and weaknesses describe tool characteristics;
+opportunities and threats describe possible circumstances affecting its use.
+These are preliminary assessments, not measured experimental results.
+
+\begingroup
+\small
+\begin{tabularx}{\linewidth}{L{2.0cm}YY}
+\caption{Preliminary SWOT for Inviscid's Metrics Backends\label{Table:InviscidSWOT}}\\
+\toprule \textbf{Category} & \textbf{Prometheus} & \textbf{VictoriaMetrics}\\ \midrule
+\endfirsthead
+\multicolumn{3}{l}{\small\itshape Preliminary SWOT (continued)}\\
+\toprule \textbf{Category} & \textbf{Prometheus} & \textbf{VictoriaMetrics}\\ \midrule
+\endhead \bottomrule \endlastfoot
+Strengths & Established open-source ecosystem; built-in metric collection and alert-rule evaluation; expressive PromQL query language. & Simple single-node deployment; built-in metric collection and storage; flexible MetricsQL query language and multiple supported ingestion formats.\\
+Weaknesses & Local storage is neither clustered nor replicated; operating at larger scales requires additional architecture. & Alert-rule evaluation requires a separate component; the single-node deployment depends on one server for availability.\\
+Opportunities & Inviscid could extend monitoring to containers and infrastructure through its existing exporter ecosystem. & Inviscid could accept metrics from different customer environments through its supported ingestion formats.\\
+Threats & Rapid growth in customer metrics could exceed available resources and increase operating costs. & Customers requiring uninterrupted monitoring could necessitate a cluster deployment, increasing infrastructure and maintenance costs.\\
+\end{tabularx}
+\endgroup
+
+\section{Technical Sources}
+The technical characteristics above are based on the following official
+documentation, consulted October 6, 2026. Opportunities and threats are the
+team's project-specific assessments. Specific tool versions will be recorded
+when the comparison is implemented.
+\begin{itemize}
+\item \href{https://prometheus.io/docs/introduction/overview/}{Prometheus overview}: collection, queries, exporters, and alerting components.
+\item \href{https://prometheus.io/docs/prometheus/latest/storage/}{Prometheus storage}: local storage limitations and remote storage interfaces.
+\item \href{https://docs.victoriametrics.com/victoriametrics/}{VictoriaMetrics documentation}: single-node deployment, scraping, ingestion, MetricsQL, and supporting components.
+\end{itemize}