# Cost-Profiling Microservice Applications Using an APM Stack
## 5 Discussion  
Based on the findings of the previous sections, we can now answer the research questions defined in Section 2:  
1. With respect to the question _\"What APM metrics can be used for cost-profiling purposes?\"_, we look at how provisioning resources for the deployment of a service contributes to the price of the underlying infrastructure. Allocated CPU and memory appear to be the highest contributors to this cost and, by extension, to the application cost. In this work, we calculated utilization as an equally weighted sum of both these metrics, but in the future, we can use differential weighting to reflect, e.g., memory-intensive services. \begin{table}
\begin{tabular}{l l l} \hline \hline  & **Requirement** & **Status** \\ \hline FR\({}_{1}\) & Storage of logs, metrics, and traces & Full; data retention rate is fixed but mutable. \\ FR\({}_{2}\) & ISO-270001 compliant & Full; alerts do need additional logic to be handled if the free version of Elastic is used. \\ FR\({}_{3}\) & Metrics visualization & Full; through the use of Kibana. \\ \hline NFR\({}_{1}\) & Dynamic data ingestion & Full; enabled by the adoption of the Elastic stack. \\ NFR\({}_{2}\) & Cloud-provider agnostic & Full; no assumptions made about the provider. \\ NFR\({}_{3}\) & Complete observability environment & Full; integrated into the Elastic observability environment. \\ NFR\({}_{4}\) & Scaling with demand & Partial: enabled in principle by building on the Elastic Stack but not tested. \\ NFR\({}_{5}\) & Fault-tolerant and highly available & (as above) \\ NFR\({}_{6}\) & Open-source solution & Full \\ \hline TR\({}_{1}\) & Integrated context view & \\ TR\({}_{2}\) & Single source of truth & Full; enabled by the adoption of the Elastic Stack. \\ TR\({}_{3}\) & Focus on usability & \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Status of the elicited requirements for the case as summarized in Table 2.  
In order to answer _\"How can the cost of microservice deployments be calculated at different levels of granularity based on these metrics?\"_, we transformed the raw metrics as collected through the APM agents into monetary cost per metric. Using this per-metric cost instead of the one provided by the cloud service provider's billing information both provides more fine-grained information and allows us to customize the interval of observation without losing too much definition. 3. Finally, we showed that for the question _\"To what extent can this information be used to reduce the cost footprint of microservice applications?\"_, it is possible to make application deployment configuration changes based on insights gained through our cost-profiling tool. It is also possible to indirectly identify architectural changes to be performed. At the same time, the shortcomings of our proposal are also clear. First, using our CPT solution requires going over a significant learning curve. Assigning one or more developers to this task and potentially adopting the Elastic Stack as an observability solution that goes beyond cost profiling so as to foster familiarity with this environment would help in this direction. Second, as with all APM solutions, the amount of data generated can very quickly be overwhelming, resulting in the cost profiler incurring its own burden in terms of operational expenses. Even with the compression of the metrics through aggregation, for example, we very quickly ended up requiring dozens of gigabytes in storage for a few days' worth of data. Removing/archiving data older than a week was a pragmatic decision taken towards keeping the situation under control, but if a larger application was under observation, then we might have reduced this down further to the span of days. We also had the advantage of being able to deploy the monitoring cluster for the data platform in the same availability zone as the target one.