MockFog 2.0: Automated Execution of Fog Application Experiments in the Cloud

Hasenburg, Jonathan; Grambow, Martin; Bermbach, David

doi:10.1109/tcc.2021.3074988

Cited by 19 publications

(10 citation statements)

References 52 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Since the test intention is to verify the behaviour of one individual unit, mocking can facilitate fault localization. Interactions that are difficult to set up within a test can be replaced with mocks [15]. Furthermore, a test can be made more reliable by using mocks to replace external, potentially unreliable or non-deterministic, components [5], [6].…”

Section: Mock Objectsmentioning

confidence: 99%

See 1 more Smart Citation

Mimicking Production Behavior with Generated Mocks

Tiwari¹,

Monperrus²,

Baudry³

2022

Preprint

View full text Add to dashboard Cite

Mocking in the context of automated software tests allows testing program units in isolation. Designing realistic interactions between a unit and its environment, and understanding the expected impact of these interactions on the behavior of the unit, are two key challenges that software testers face when developing tests with mocks. In this paper, we propose to monitor an application in production to generate tests that mimic realistic execution scenarios through mocks. Our approach operates in three phases. First, we instrument a set of target methods for which we want to generate tests, as well as the methods that they invoke, which we refer to mockable method calls. Second, in production, we collect data about the context in which target methods are invoked, as well as the parameters and the returned value for each mockable method call. Third, offline, we analyze the production data to generate test cases with realistic inputs and mock interactions. The approach is automated and implemented in an open-source tool called RICK. We evaluate our approach with three real-world, open-source Java applications. RICK monitors the invocation of 128 methods in production across the three applications and captures their behavior. Next, RICK analyzes the production observations in order to generate test cases that include rich initial states and test inputs, mocks and stubs that recreate actual interactions between the method and its environment, as well as mock-based oracles. All the test cases are executable, and 52.4% of them successfully mimic the complete execution context of the target methods observed in production. We interview 5 developers from the industry who confirm the relevance of using production observations to design mocks and stubs.

show abstract

Section: Mock Objectsmentioning

confidence: 99%

“…Bragg et al [60] use the test suite of Sketch programs to generate mocks in order to modularize program synthesis. Mocks have also been generated in the context of cloud computing [61], such as for the emulation of infrastructure by MockFog [15].…”

Section: Mock Generationmentioning

confidence: 99%

Mimicking Production Behavior with Generated Mocks

Tiwari¹,

Monperrus²,

Baudry³

2022

Preprint

View full text Add to dashboard Cite

show abstract

“…On the other hand, it also increases the effects of "noisy neighbors", that is, breaking the isolation of function containers. 20 An approach to restrict CPU cores or even cycles is also feasible using Docker, 36,37 but would reverse that trade-off. As discussed in C1 (Section 4.1), the auction-based approach suffers from the problem that requests will not arrive in batches unless the system is completely overloaded.…”

Section: Executing Function Callsmentioning

confidence: 99%

“…On the other hand, it also increases the effects of “noisy neighbors”, that is, breaking the isolation of function containers 20 . An approach to restrict CPU cores or even cycles is also feasible using Docker, 36,37 but would reverse that trade‐off.…”

Section: Evaluation: Prototype and Experimentsmentioning

confidence: 99%

“…Please note that we used a relatively large edge node since OpenWhisk, the basis of AuctionWhisk, does not work well on smaller nodes. 10 Since we did not have access to a real fog infrastructure, we injected artificial latency based on netEm ‡ ‡ similar to the approach used in MockFog 37,38 -see Figure 10 for an overview. Between the edge node and the intermediary node we set an average latency of 20 ms, the latency between the intermediary node and cloud node, we set to 40 ms, while our benchmarking client had a latency of 25 ms to the edge node (these numbers include both real and artificial delays).…”

Section: Experiments Setupmentioning

confidence: 99%

See 1 more Smart Citation

AuctionWhisk: Using an auction‐inspired approach for function placement in serverless fog platforms

et al. 2021

Self Cite

View full text Add to dashboard Cite

The Function-as-a-Service (FaaS) paradigm has a lot of potential as a computing model for fog environments comprising both cloud and edge nodes, as compute requests can be scheduled across the entire fog continuum in a fine-grained manner. When the request rate exceeds capacity limits at the resource-constrained edge, some functions need to be offloaded toward the cloud. In this article, we present an auction-inspired approach in which application developers bid on resources while fog nodes decide locally which functions to execute and which to offload in order to maximize revenue. Unlike many current approaches to function placement in the fog, our approach can work in an online and decentralized manner. We also present our proof-of-concept prototype AuctionWhisk that illustrates how such an approach can be implemented in a real FaaS platform. Through a number of simulation runs and system experiments, we show that revenue for overloaded nodes can be maximized without dropping function requests.

show abstract

Software‐in‐the‐loop simulation for developing and testing carbon‐aware applications

Wiesner,

Steinke,

Nickel

et al. 2023

Softw Pract Exp

View full text Add to dashboard Cite

The growing electricity demand of IT infrastructure has raised significant concerns about its carbon footprint. To mitigate the associated emissions of computing systems, current efforts therefore increasingly focus on aligning the power usage of software with the availability of clean energy. To operate, such carbon‐aware applications require visibility and control over relevant metrics and configurations of the energy system. However, research and development of novel energy system abstraction layers and interfaces remain difficult due to the scarcity of available testing environments: Real testbeds are expensive to build and maintain, while existing simulation testbeds are unable to interact with real computing systems. To provide a widely applicable approach for developing and testing carbon‐aware software, we propose a method for integrating real applications into a simulated energy system through software‐in‐the‐loop simulation. The integration offers an API for accessing the energy system, while continuously modeling the computing system's power demand within the simulation. Our system allows for the integration of physical as well as virtual compute nodes, and can help accelerate research on carbon‐aware computing systems in the future.

show abstract

MockFog 2.0: Automated Execution of Fog Application Experiments in the Cloud

Cited by 19 publications

References 52 publications

Mimicking Production Behavior with Generated Mocks

Mimicking Production Behavior with Generated Mocks

AuctionWhisk: Using an auction‐inspired approach for function placement in serverless fog platforms

Software‐in‐the‐loop simulation for developing and testing carbon‐aware applications

Contact Info

Product

Resources

About