\chapter{Project Proposal}
\ChapterLabel{ProjectProposal}
\index{Inviscid}\index{Prometheus}\index{VictoriaMetrics}\index{observability}

\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.

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.

\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.2cm}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}