Oparaca Prototype: Cloud-Only Baseline

• Oparaca Prototype is a cloud-only baseline system for distributed application management, serving as a control for evaluating SLA-driven frameworks like EdgeWeaver.
• It focuses on centralized resource allocation and service-level enforcement to benchmark improvements in automation and developer productivity.
• Empirical studies reveal that compared to advanced edge–cloud systems, the Oparaca Prototype may show slower task completion and larger code footprints.

@@@@1@@@@ is the reference implementation of the OaaS-IoT paradigm, which extends the Object-as-a-Service (OaaS) model to the edge–cloud continuum. EdgeWeaver systematically unifies compute, state, and workflow abstractions for distributed application development, facilitating declarative specification and automated enforcement of service-level agreements (SLAs) such as throughput, availability, consistency, and geo-placement. Empirical studies demonstrate EdgeWeaver’s advantages in automation, maintainability, and developer productivity, including 31% faster task completion and a 44.5% reduction in code footprint compared to function-as-a-service (FaaS) approaches. The system is architected to abstract infrastructure complexity and streamline deployment and operation of edge-cloud-native applications (Lertpongrujikorn, 27 Dec 2025).

1. OaaS-IoT Model and Declarative Abstraction

EdgeWeaver implements the OaaS-IoT abstraction, in which developers encode application logic as classes (objects) combining serverless methods and stateful attributes. Structured state is represented by document or in-memory databases; unstructured blobs are managed via object storage. Each class definition supports declarative SLAs: throughput (rps), availability (% uptime), consistency (strong, bounded staleness, read-your-write), locality (edge, cloud, or any), budget, and jurisdiction. EdgeWeaver parses these specifications, infers the required resource allocation, and autonomously orchestrates deployment and execution.

Key empirical findings indicate practitioners heavily prioritize automation and maintainability, with infrastructure complexity identified as the dominant cost to developer productivity (Lertpongrujikorn, 27 Dec 2025). EdgeWeaver’s object+SLA approach yields 31% faster human study task completion and achieves code size and configuration reductions of 44.5% and 10×, respectively, compared to FaaS baselines.

2. System Architecture and Runtime Components

EdgeWeaver comprises a layered architecture spanning cloud and edge infrastructure (Figure 1). Central orchestration is provided by a Package Manager (PM), which coordinates deployment across EdgeWeaver Agents instantiated per datacenter. Agents include four components:

• Class Runtime Manager (CRM)
• Class Runtime (CR)
• Monitoring System (MS)
• Messaging Infrastructure (MI)

Device Agents may reside on IoT nodes. The CR is architected with three principal modules (Figure 2):

• Logic Engine: Executes serverless function implementations, typically as Knative containers.
• Storage System: Integrates document/in-memory databases for structured state and object stores (e.g., via presigned URLs) for blobs.
• Object Data Grid Manager (ODGM): Enforces data routing, consistency (Raft, anti-entropy), cross-site RPC, and event delivery.

This design supports SLA-driven orchestration, enabling dynamic resource adaptation under faults and network partitions without developer intervention.

3. SLA-Driven Resource Scheduling and Orchestration

EdgeWeaver deploys several algorithmic techniques to satisfy non-functional constraints specified via SLAs.

Availability Replication

Given an availability requirement $A$ and per-node stability $P$, the minimum number of replicas $N$ is selected to solve:

$A = 1 - (1 - P)^N$

EdgeWeaver uses this relationship to select datacenters with maximal stability and deploys the calculated $N$ CR instances accordingly.

Throughput Enforcement

For throughput $R$ (requests/sec), the system provisions sufficient container instances so that each invocation can be initiated every $1/R$ seconds. Container-level throughput is predicted to guide horizontal scaling using “Real-time Serverless” approaches [Nguyen & Chien ’19].

Locality and Consistency Placement

Locality constraints dictate co-location of method container and primary state, driven by consistent hashing for object IDs. Consistency options include strong (Raft), bounded staleness (anti-entropy with Merkle trees), and read-your-write (RYW) policies.

Multi-Objective Scheduling

At deployment, EdgeWeaver solves for:

$$\min \sum_i \text{Cost}_i(x_i) + \alpha \sum_i \text{Latency}(x_i)$$

subject to $Throughput_i(x_i) \geq R_i$, $Availability_i(x_i) \geq A_i$, and $Placement_i(x_i) \in AllowedDC_i$, where $x_i$ parametrize resource allocation and $\alpha$ balances cost against latency.

4. SLA Specification and Runtime Management

Declarative constraints are encoded using YAML, e.g.:

classes: - name: VideoAnalytics sla: throughput: 1000 # rps availability: 99.99 # % consistency: strong locality: edge

At runtime (Figure 3), the PM assigns CRs per datacenter, CRM enforces replication, CR applies consistency protocols, and Logic Engine manages container pre-warming. The MS continuously monitors metrics, triggering scaling or re-placement as needed for SLA compliance.

The following table summarizes supported SLA fields:

SLA Parameter	Type/Options	Function
throughput	Integer (rps)	Guaranteed function calls/sec
availability	Real (%)	% required uptime
consistency	strong, bounded_staleness, RYW	Data consistency protocol
locality	edge, cloud, any	Placement constraint
budget	Cost credit	Deployment cost limit
jurisdiction	Datacenter set	Allowed physical locations

5. Empirical Performance Evaluation

Experiments were conducted with edge clusters (8 nodes ×8 vCPU; 33 ms RTT) and cloud clusters (3 nodes ×16 vCPU), using Minio (S3) and ArangoDB for storage. Baselines included Knative defaults, Knative+RTS, and Oparaca (cloud-only).

• EdgeWeaver matches declared throughput up to 4,000 rps; Knative variants fail under high load.
• SLA locality enforcement reduces end-to-end latency up to 4×; “warm” containers eliminate cold-start overhead, achieving latency within 7% of optimal.
• Replication supports 99.9%–99.999% availability under fault injection (MTBF=180s), using only 2–9× replicas—50× fewer than AWS defaults.
• Scalability is linear up to 256 vCPUs (cloud-only; 70× speedup), proportional across 8 edge sites, and limited by network in mixed configurations.
• Inventory case study: EdgeWeaver required 363 LoC and 39 config lines, versus 666 LoC and 417 config lines for FaaS—a reduction of 44.5% and 10×, respectively.

Statistical analysis used repeated measures (5×), error bars for SD (±5 ms latency, ±2% throughput), and paired t-tests (developer task completion p<0.01).

6. Developer Productivity and Experience

Human subject study (N=39) measured completion and quiz accuracy: 31% faster programming (22.4 min EdgeWeaver, 32.4 min FaaS; p<0.005) and higher accuracy (84.6% EdgeWeaver, 81.5% FaaS; >90% for experienced users). Code size was consistently reduced by 44.5% for identical logic, and config artifacts declined by a factor of ten. Qualitative responses indicated 92% preference for the object abstraction as “more intuitive” and 88% preference for declarative SLAs versus manual resource tuning.

7. API Usage Patterns and Workflow Examples

EdgeWeaver’s API exposes the following primitives:

API Call	Signature	Description
CLASS.create()	→ ID	Instantiate object/class
CLASS.get(ID)	→ obj	Retrieve object by ID
commit(obj, attr)		Commit modification to attribute
refresh(obj, attr)		Refresh attribute from storage
trigger(func, src, event)		Event-driven invocation

An example for a real-time video processing workflow (Figure 4):

YAML definition snippet:

classes: - name: VideoProcessor sla: throughput: 30 # fps locality: edge attributes: - name: inputBlob type: Blob methods: - name: extractFrames trigger: OnCreate(inputBlob) - name: detectObject sla: locality: cloud consistency: strong

Pseudocode:

videoId = VideoProcessor.create() VideoProcessor.inputBlob(videoId) = s3.upload("camera1.mp4") VideoProcessor.extractFrames.triggerOn(videoId) // Cross-tier placement and SLA management handled by EdgeWeaver

A plausible implication is that this object-centric, SLA-driven workflow model can substantially lower complexity barriers for distributed application developers, especially in edge–cloud-IoT environments where traditional function runtime and resource orchestration remain fragmented and low-level (Lertpongrujikorn, 27 Dec 2025).