Modern Software as a Service (SaaS) platforms, such as the Microsoft Power Platform, simplify maintenance efforts through abstraction of underlying layers such as managing server infrastructure or OS-level configurations. Nevertheless, they still allow custom code extensions to extend and customize the application behavior. Yet, this implies restricted control and limited insights with respect to performance.Often, built-in performance reportings do not provide enough detail for efficient problem root cause analysis. Open standards, such as OpenTelemetry, make it easier to implement a more advanced aligned tracing ecosystem. Yet, while monitoring on traditional, non-cloud systems has been thoroughly studied, collecting telemetry data on SaaS systems faces many more complex challenges such as sandboxing, e.g., limited API access, or collecting end-to-end traces through multiple distributed entry points. Besides platform experience, deep technical knowledge about serialization, transmission, and caching costs is essential to understand the process and assess the performance overhead introduced by collecting telemetry data.In this work, we discuss common challenges regarding SaaS observability and the performance impact that telemetry data collection introduces. For this, we modify Intermediate Language (IL) code, i.e., already compiled code, on the Microsoft Power Platform to collect telemetry data for each method execution. A key finding is that a significant and often unreported portion of performance overhead originates from the SaaS platform itself, a crucial distinction from the overhead introduced by telemetry collection. Finally, we propose a concept for adaptive telemetry collection based on execution plan prediction, which aims to balance observability detail with performance overhead by estimating monitoring costs.
Cloud-native deployments are typically ad-hoc and fragmented, leading to repeated misconfigurations and increased security risk. A challenge that arises often in modern deployment processes is the use of diverse heterogeneous technologies, such as Infrastructure-as-Code frameworks and cloud-specific tools. This causes a technological lock-in, making migration, adoption of alternative solutions, and supporting multi-cloud environments difficult. Another issue that further complicates current deployment processes is the collaboration of multiple actors during the process, such as developers, cloud architects, and business decision-makers whose roles are not well defined.To address these challenges, we advocate for a constraint-based approach of deployment. We emphasize security and compliance where constraints are declarative and treated as first-class inputs. This process would enable the specification of high-level constraints (e.g. security, cost, legal, etc.) and technical requirements in a unified and structured manner. This makes deployments portable across environments and cloud providers, auditable, and resilient to evolution. By introducing clear role separation and constraints validation, our approach promotes accountability while reducing the cognitive load on individual deployment actors.We propose a framework that enables actors involved in the deployment to specify constraints at various stages (architecture level, implementation level, etc.). These constraints are evaluated and verified by a constraint solver, and results into a set of feasible deployment options. Deployment scripts are generated from one of the feasible deployments in order to deploy the application. It is worth stressing that our intention is not to replace existing deployment workflows, but rather to provide a complementary approach.
Serverless computing simplifies application deployment by removing the need for infrastructure management, with REST APIs being the common interface. Data persistence is essential for serverless applications because serverless functions are stateless and short-lived. To retain information across function executions, relational databases are commonly used to persist data, to ensure continuity, scalability, and reliable management. However, REST can lead to inefficiencies such as data over-fetching and under-fetching, which impact performance. GraphQL is a data query and manipulation language that supports client queries that specify what data is to be retrieved or modified. GraphQL resolvers fetch and transform data as specified by client queries.This paper compares the performance and scalability of GraphQL APIs as a database interface middleware in contrast to REST APIs implemented using serverless functions. We compare a GraphQL API implemented using the managed GraphQL AWS AppSync service, an unmanaged GraphQL API hosted using Apollo Server, and a traditional REST API implemented via the Amazon API Gateway and AWS Lambda. We compare these alternatives using clients implemented with serverless AWS Lambda functions, and also a local machine, an Amazon virtual machine (VM), and a Google VM. Our data APIs accessed a managed Amazon Aurora PostgreSQL cluster populated with the U.S. Centers for Medicare & Medicaid Services (CMS) Open Payments dataset. Our GraphQL implementations show content-dependent performance compared to REST, with Apollo Server demonstrating 25-67% faster average round-trip times vs. REST for most operations, but worse scalability than REST with very high concurrent workloads. Our findings provide practical guidance for developers selecting serverless architectures for GraphQL and REST APIs based on specific application requirements, network conditions, and expected request volumes.
CPILS is a sustainable education system consisting of a private cloud core and peripherals for the interaction with users and the environment. It is aimed at upskilling students on societally relevant topics as well as technology to overcome uncertainties and achieve autarky. Currently, two instances of CPILS are deployed in universities as immersive learning spaces for mixed-discipline students. In this paper, we present the adaptive software design and technology decisions behind CPILS and demonstrate the resulting implementation.
This study investigates whether cloud provider solutions offer cost advantages over private cloud infrastructures in large-scale government settings. Focusing on the case of Greek Governmental Cloud (GCloud), we conduct a comprehensive cost comparison across three deployment models: the existing on-premise infrastructure, an IaaS cloud provider solution and a PaaS cloud provider solution. The cost analysis considers a five-year operational time window and uses real procurement data and updated discount policies. We take into consideration that the organization already has data center infrastructure and explores the migration options to cloud provider solutions. The cost analysis findings show that although provider solution can match or slightly undercut on-premise costs under specific conditions where agility is important, there is no financial advantage regarding standard operation needs. This real-world case study of the Greek Government Cloud highlights that cloud migration decisions for large organizations, with existing IT infrastructures, should be taken after thorough cost evaluation, accurate workload analysis, and a deep understanding of dynamic pricing models. Moreover, this study offers practical recommendations to decision-makers that navigate complex infrastructure choices. While infrastructure choices involve factors such as performance, security, and operational flexibility, this study intentionally focuses solely on the cost, aiming to provide a clear and quantifiable economic comparison. In general, this study aims to open a discussion about whether Cloud solutions are a panacea, especially in government settings.
