Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
109
datasets available to search
ShareScore release 0.9.0
Dataset results
109 results for “Microservices”
Benchmarking on Microservices Configurations and the Impact on the Performance in Cloud Native Environments
<p><strong>The peer reviewed publication for this dataset has been published in LCN 2022, 47th Annual IEEE Conference on Local Computer Networks. Please cite this paper when referring to the dataset: https://www.eurecom.fr/publication/6971.</strong></p> <p>Cloud-native and containerization have changed the way to develop and deploy applications. Cloud-native rethinks the application architecture by embracing a microservice approach, where each microservice is packaged into containers to run in a centralized or an edge cloud. When deploying the container running the micro-service, the tenant has to specify the needed computing resources to run their workload in terms of the amount of CPU and memory limit. However, it is not straightforward for a tenant to know in advance the computing amount that allows running the microservice optimally. This will have an impact not only on the service performances but also on the infrastructure provider, particularly if the resource overprovisioning approach is used. To overcome this issue, we conduct an experimental study aiming to detect if a tenant's configuration allows running its service optimally. We run several experiments on a cloud-native platform, using different types of applications under different resource configurations. The obtained results are presented in the accepted IEEE LCN paper (https://www.eurecom.fr/publication/6971) and are shared in this dataset.</p> <p>The datasets are collected for 3 types of applications: Web servers written in python and Golang, RabbitMQ data broker and the OpenAirInterface 5G Core network function AMF (Access and Mobility Management Function).</p> <p><br> </p> <p><strong>Web Servers:</strong></p> <p><strong>files: </strong>golang-web-server-performance.csv, python-web-server-performance.csv</p> <p>We used Golang and Python-based web servers for the test. Each request to the web server returns a video of a size 43 MB. For testing we used ApacheBench, a command-line program used for benchmarking HTTP web servers. ApacheBench allows parallel requests from multiple clients. For each web server instance we send a number of requests ranging from 100 to 1000 and a concurrency level between 1 and 100, representing the number of parallel clients performing the requests.</p> <p>The information available in the dataset are as follows:</p> <p><strong>time:</strong> timestamp of collection of metrics.</p> <p><strong>ram_limit:</strong> the memory allocated to the container in megabytes.</p> <p><strong>cpu_limit:</strong> the CPU allocated to the container.</p> <p><strong>ram_usage:</strong> the amount of memory used by the container at the time of the metrics collection in byte.</p> <p><strong>cpu_usage:</strong> the amount of CPU used by the container at the time of the metrics collection.</p> <p><strong>n:</strong> the number of requests sent to the container.</p> <p><strong>c:</strong> the concurrency level in the requests.</p> <p><strong>lat50:</strong> the least response time for the best 50% requests in microseconds.</p> <p><strong>lat66:</strong> the least response time for the best 66% requests in microseconds.</p> <p><strong>lat75:</strong> the least response time for the best 75% requests in microseconds.</p> <p><strong>lat80:</strong> the least response time for the best 80% requests in microseconds.</p> <p><strong>lat90:</strong> the least response time for the best 90% requests in microseconds.</p> <p><strong>lat95:</strong> the least response time for the best 95% requests in microseconds.</p> <p><strong>lat98:</strong> the least response time for the best 98% requests in microseconds.</p> <p><strong>lat99:</strong> the least response time for the best 99% requests in microseconds.</p> <p><strong>lat100:</strong> the least response time in microseconds.</p> <p> </p> <p><strong>5G Core network’s AMF:</strong></p> <p><strong>file: </strong>amf-performance.csv</p> <p>For testing we use my5G-RANTester, a tool for emulating control and data planes of the UE and gNB (5G base station). The number of simultaneous registration requests that are sent to each instance of the AMF varies between 10 and 400.</p> <p>The information available in the dataset are as follows:</p> <p><strong>time:</strong> timestamp of collection of metrics.</p> <p><strong>ram_limit:</strong> the memory allocated to the container in megabytes.</p> <p><strong>cpu_limit:</strong> the CPU allocated to the container.</p> <p><strong>ram_usage:</strong> the amount of memory used by the container at the time of the metrics collection in byte.</p> <p><strong>cpu_usage:</strong> the amount of CPU used by the container at the time of the metrics collection.</p> <p><strong>n:</strong> the number of parallel registration requests sent to the AMF.</p> <p><strong>mean:</strong> the mean registration time for all the registration requests in microseconds.</p> <p><strong>lat50:</strong> the median registration time for registration requests in microseconds.</p> <p><strong>lat75: </strong>the least registration time for the best 75% registration requests in microseconds.</p> <p><strong>lat80:</strong> the least registration time for the best 80% registration requests in microseconds.</p> <p><strong>lat90:</strong> the least registration time for the best 90% registration requests in microseconds.</p> <p><strong>lat95:</strong> the least registration time for the best 95% registration requests in microseconds.</p> <p><strong>lat98:</strong> the least registration time for the best 98% registration requests in microseconds.</p> <p><strong>lat99:</strong> the least registration time for the best 99% registration requests in microseconds.</p> <p><strong>lat100:</strong> the least registration time in microseconds.</p> <p> </p> <p><strong>RabbitMQ data broker:</strong></p> <p><strong>file: </strong>rabbitmq-performance.csv</p> <p>For testing we used RabbitMQ PerfTest which is a throughput testing tool that simulates basic workloads and provides the throughput and the time that a message takes to be consumed by a consumer. For each deployed RabbitMQ server we used a number of producers and consumers that ranges from 50 to 500. Each producer sends messages to the broker with a rate of 100 messages per second for a period of time of 90 seconds.</p> <p>The information available in the dataset are as follows:</p> <p><strong>time:</strong> timestamp of collection of metrics.</p> <p><strong>ram_limit:</strong> the memory allocated to the container in megabytes.</p> <p><strong>cpu_limit:</strong> the CPU allocated to the container.</p> <p><strong>ram_usage:</strong> the amount of memory used by the container at the time of the metrics collection in byte.</p> <p><strong>cpu_usage:</strong> the amount of CPU used by the container at the time of the metrics collection.</p> <p><strong>n:</strong> the number of producers sending messages to the RabbitMQ server.</p> <p><strong>Min:</strong> the minimum consumption time for the producer messages.</p> <p><strong>lat50:</strong> the median consumption time for the producer messages.</p> <p><strong>lat75:</strong> the least consumption time for the best 75% messages in microseconds.</p> <p><strong>lat95:</strong> the least consumption time for the best 95% messages in microseconds.</p> <p><strong>lat99:</strong> the least consumption time for the best 99% messages in microseconds.</p>
Architectural Languages for the Microservices Architecture: A systematic mapping study [Data set]
<p>This repository contains all artifacts related to the study: Architectural Languages for the Microservices Architecture: A systematic mapping study.</p>
Software developers are users of the Heureka microservice platform
<p>This data set contains the qualitative analysis of the "software developers are users" study, conducted to investigate the fitting of the Heureka microservice platform (http://doc.soteto.net) to support software developers in participating the change of socio-technical evolutionary-teal organizations.</p> <p>The study is part of the SOTETO project (http://soteto.net) and its results will be published and contextualized by the dissertation thesis of Johann Sell.</p>
A trace of microservice time, call rate, and number of replicas
<p>This is part of the runtime traces of the Alibaba Cloud clusters, which record rows of different microservice times, call rates, and number replicas over a 30-second interval.<br><br>In this dataset, starting from zero, the fifth and sixth columns show the microservice time and call rates (with the microservice ID in column 2 and the container ID in column 3).<br>Moreover, column 4 contains the number of replicas from the microservice, denoted in column 2.</p> <p>Alibaba's original microservice trace has 24 parts, from which we extracted ten and filtered based on message queue and similarity in microservice and container IDs.<br><br>Please consider that the first two columns are timestamps.</p>
Replication package for Decomposition of Monolithic Applications into Microservices Architectures: A Systematic Review
<p><strong>Replication Package</strong></p> <p><strong>Title:</strong></p> <p>Replication package for Decomposition of Monolithic Applications into Microservices Architectures: A Systematic Review.</p> <p><strong>Authors:</strong></p> <p>Yalemisew Abgaz, Andrew McCarren, Peter Elger, David Solan, Neil Lapuz, Marin Bivol, Glenn Jackson, Murat Yilmaz, Jim Buckley, and Paul Clarke</p> <p><strong>Year</strong></p> <p>This replication package was initially generated in 2022 and following feedback from reviewers, it is revised in 2023.</p> <p>This package contains two files and three folders that provide additional insight for researchers who wish to replicate our work or who would like to expand the review in the future.</p> <p><strong>Files</strong></p> <ul> <li>The file contains a detailed description of the literature search outlining the steps and the results obtained.</li> <li>Readme.md: A readme file (this file).</li> </ul> <p><strong>Folders</strong></p> <ul> <li>A folder containing the search results and the refinement steps. It contains four files listing studies included in the refinement process (Refinement_Step_1 to Refinement_Step_4) and a master file combining all the steps in one file. The master file contains detailed information about how the refinement steps are executed and all the intermediate results following each refinement step. Users may explore by expanding the filters in Refinement Step 2 (J), Refinement Step 3 (M) and Refinement Step 4 § columns in the master sheet. Readers can also directly go to the sheets that contain the selected studies in any of the refinement stages. A description of each file is also included in the Literature_Search_Strategy.pdf file.</li> <li>This folder contains the list of studies included in the snowballing process, including the last two refinement steps (Refinement_Step_5 and Refinement_Step_6). The snowballing master sheet contains studies extracted using the snowballing process and the data cleaning and filtering criteria used. The different sheets also contain the selected studies at each stage of the snowballing process.</li> </ul> <ul> <li>This folder contains the data extracted from the selected literature by employing the Systematic Review and Ground Theory. The two files included in this folder contain the data extraction template and the data extracted from the 35 selected studies including some intermediate notes.</li> </ul> <p>If you have further questions regarding the survey, feel free to contact us via e-mail. <a href="mailto:Yalemisewm.abgaz@dcu.ie">Yalemisewm.abgaz@dcu.ie</a>.</p> <p> </p>
Domain-Driven Design for Microservices Architecture Systems Development: A Systematic Mapping Study
<p>This repository contains all artifacts related to the study: Domain-Driven Design for Microservices Architecture Systems Development: A<br> Systematic Mapping Study</p>
TrainTicket microservice testbench extracted information for our work: Evaluating ChatGPT's Proficiency in Understanding and Answering Microservice Architecture Queries Using Source Code Insights
<p>It contains the CSV file output of our tool implemented in the paper: "Evaluating ChatGPT’s Proficiency in Understanding and Answering Microservice Architecture Queries Using Source Code Insights." applied to the TrainTicket microservice testbench. The information in this CSV was used for In-Context-Learning for ChatGPT.</p>
From a Monolithic Big Data System to a Microservices Event-Driven Architecture
<p>[Context] Data-intensive systems, a.k.a. big data systems (BDS), are software systems that handle a large volume of data in the presence of performance quality attributes, such as scalability and availability. Before the advent of big data management systems (e.g. Cassandra) and frameworks (e.g. Spark), organizations had to cope with large data volumes with custom-tailored solutions. In particular, a decade ago, Tecgraf/PUC-Rio developed a system to monitor truck fleet in real-time and proactively detect events from the positioning data received. Over the years, the system evolved into a complex and large obsolescent code base involving a hard maintenance process. [Goal] We report our experience on replacing a legacy BDS with a microservice-based event-driven system. [Method] We applied action research, investigating the reasons that motivate the adoption of a microservice-based event-driven architecture, intervening to define the new architecture, and documenting the challenges and lessons learned. [Results] We perceived that the resulting architecture enabled easier maintenance and fault-isolation. However, the myriad of technologies and the complex data flow were perceived as drawbacks. Based on the challenges faced, we highlight opportunities to improve the design of big data reactive systems. [Conclusions] We believe that our experience provides helpful takeaways for practitioners modernizing systems with data-intensive requirements.</p>
Data for: Drivers and Barriers for Microservice Adoption in the German Software Industry
<p>Microservices are an architectural style for software which currently receives a lot of attention in both industry and academia. Several companies employ microservice architectures with great success, and there is a wealth of blog posts praising their advantages. Especially so-called Internet-scale systems use them to satisfy their enormous scalability requirements and to rapidly deliver new features to their users.<br> However, microservices are not only popular with large, Internet-scale systems. Many traditional companies are also considering whether microservices are a viable option for their applications. However, these companies may have other motivations to employ microservices, and see other barriers which may prevent them from adopting microservices. Furthermore, these drivers and barriers may differ among industry sectors.<br> This dataset contains the questions and results of a survey on drivers and barriers for microservice adoption among professionals in the German software industry. In addition to overall drivers and barriers, we particularly focused on the use of microservices to modernize existing software, with special emphasis on implications for runtime performance and transactionality.</p>
Dataset and Analysis Scripts for Survey "Understanding Security Tactics in Microservice APIs using Annotated Software Architecture Decomposition Models -- A Controlled Experiment"
<pre>Dataset, R-Scripts and questionnaire templates for our survey <em>Understanding Security Tactics in Microservice APIs using Annotated Software Architecture Decomposition Models -- A Controlled Experiment.</em></pre>
End-To-End (Selenium and Gatling) Test Coverage in Microservices
<p>It contains an analysis to TrainTicket benchmark, selenium test suites, and Gatling tests. It lists the endpoints and their intersections with each others. It is generated for the approach that calculates three levels of coverage (microservice coverage, test suite coverage, and overall coverage).</p> <p>Checkout more details and explanations in the paper titled: On End-To-End Test Coverage in Microservices.</p>
Dataset used by the paper MADE: Learning to Detect and Explain Chaos in Microservice Architectures
<p>Dataset used by the paper MADE: Learning to Detect and Explain Chaos in Microservice Architectures</p> <p>Include the raw dataset of 10 chaos</p>
Dataset for "Designing Microservice Systems Using Patterns: An Empirical Study on Quality Trade-Offs"
<p>This package provides all published resources used and produced in the context of the research study leading to the article <em>"Designing Microservice Systems Using Patterns: An Empirical Study on Quality Trade-Offs"</em>, presented in ICSA 2022's technical track.</p>
Microservice Security Metrics: Dataset
<p>This is the dataset provided for replicability for the article "Microservice Security Metrics for Secure Communication, Identity Management, and Observability". It provides the code needed to replicate the study in the article, as well as the model data set of 10 system models and 20 variants of those models.</p> <p> </p> <p>The abstract of the article is:</p> <p> </p> <p>Microservice architectures are increasingly being used to develop application systems. Despite many guidelines and best practices being published, architecting microservice systems for security is challenging. Reasons are the size and complexity of microservice systems, their polyglot nature, and the demand for the continuous evolution of these systems. In this context, to manually validate that security architecture tactics are employed as intended throughout the system is a time-consuming and error-prone task. In this article, we present an approach to avoid such manual validation before each continuous evolution step in a microservice system, which we demonstrate using three widely used categories of security tactics: secure communication, identity management, and observability. Our approach is based on a review of existing security guidelines, the gray literature, and the scientific literature, from which we derived Architectural Design Decisions (ADDs) with the found security tactics as decision options. In our approach, we propose novel detectors to detect these decision options automatically and formally defined metrics to measure the conformance of a system to the different options of the ADDs. We apply the approach on a case study data set of 10 open source microservice systems, plus another 20 variants of these systems, for which we manually inspected the source code for security tactics. We demonstrate and assess the validity and appropriateness of our metrics by performing an assessment of their conformance to the ADDs in our systems' dataset through statistical methods.</p>
Survey Protocol - A Metrics suite for End-to-End Microservice Test Coverage
<p>These survey is performed and reported in a paper titled "A Metrics suite for End-to-End Microservice Test Coverage".</p>
Domain-Driven Design in Microservices-Based Systems Development: A Systematic Literature Review and Thematic Analysis [Dataset]
<p>This repository contains all artifacts related to the study: Domain-Driven Design in Microservices-Based Systems Development: A Systematic Literature Review and Thematic Analysis</p>
Dataset Artifact for paper "Root Cause Analysis for Microservice System based on Causal Inference: How Far Are We?"
<p>Artifacts for the paper titled <strong><em>Root Cause Analysis for Microservice System based on Causal Inference: How Far Are We?</em></strong>.</p> <p>This artifact repository contains 9 compressed folders, as follows: </p> <table> <tbody> <tr> <td><strong>ID</strong></td> <td><strong>File Name</strong></td> <td><strong>Description</strong></td> </tr> <tr> <td>1</td> <td>syn_circa.zip</td> <td>CIRCA10, and CIRCA50 datasets for Causal Discovery</td> </tr> <tr> <td>2</td> <td>syn_rcd.zip</td> <td>RCD10, and RCD50 datasets for Causal Discovery</td> </tr> <tr> <td>3</td> <td>syn_causil.zip</td> <td>CausIL10, and CausIL50 datasets for Causal Discovery</td> </tr> <tr> <td>4</td> <td>rca_circa.zip</td> <td>CIRCA10, and CIRCA50 datasets for RCA</td> </tr> <tr> <td>5</td> <td>rca_rcd.zip</td> <td>RCD10, and RCD50 datasets for RCA</td> </tr> <tr> <td>6</td> <td>online-boutique.zip</td> <td>Online Boutique dataset for RCA</td> </tr> <tr> <td>7</td> <td>sock-shop-1.zip</td> <td>Sock Shop 1 dataset for RCA</td> </tr> <tr> <td>8</td> <td>sock-shop-2.zip</td> <td>Sock Shop 2 dataset for RCA</td> </tr> <tr> <td>9</td> <td>train-ticket.zip</td> <td>Train Ticket dataset for RCA</td> </tr> </tbody> </table> <p>Each zip file contains the generated/collected data from the corresponding data generator or microservice benchmark systems (e.g., online-boutique.zip contains metrics data collected from the Online Boutique system). </p> <p><strong>Details about the generation of our datasets</strong></p> <p><em>1. Synthetic datasets</em></p> <p>We use three different synthetic data generators from three previous RCA studies [15, 25, 28] to create the synthetic datasets: CIRCA, RCD, and CausIL data generators. Their mechanisms are as follows:<br><br>1. CIRCA datagenerator [28] generates a random causal directed acyclic graph (DAG) based on a given number of nodes and edges. <span>From this DAG, time series data for each node is generated using a </span><span>vector auto-regression (VAR) model. A fault is injected into a node </span><span>by altering the noise term in the VAR model for two timestamps. <br></span><span><br>2. RCD data generator [25] uses the pyAgrum package [3] to generate </span><span>a random DAG based on a given number of nodes, subsequently </span><span>generating discrete time series data for each node, with values ranging from 0 to 5. A fault is introduced into a node by changing its </span><span>conditional probability distribution.<br><br>3. CausIL data generator [15] generates causal graphs and time series data that simulate </span><span>the behavior of microservice systems. It first constructs a DAG of </span><span>services and metrics based on domain knowledge, then generates </span><span>metric data for each node of the DAG using regressors trained on </span><span>real metrics data. Unlike the CIRCA and RCD data generators, the </span><span>CausIL data generator does not have the capability to inject faults.<br><br></span>To create our synthetic datasets, we first generate 10 DAGs whose nodes range from 10 to 50 for each of the synthetic data generators. Next, we generate fault-free datasets using these DAGs with different seedings, resulting in 100 cases for the CIRCA and RCD generators and 10 cases for the CausIL generator. We then create faulty datasets by introducing ten faults into each DAG and generating the corresponding faulty data, yielding 100 cases for the CIRCA and RCD data generators. The fault-free datasets (e.g. `syn_rcd`, `syn_circa`) are used to evaluate causal discovery methods, while the faulty datasets (e.g. `rca_rcd`, `rca_circa`) are used to assess RCA methods. </p> <p><em>2. Data collected from benchmark microservice systems </em></p> <p>We deploy three popular benchmark microservice systems: Sock Shop [6], Online Boutique [4], and Train Ticket [8], on a four-node Kubernetes cluster hosted by AWS. Next, we use the Istio service mesh [2] with Prometheus [5] and cAdvisor [1] to monitor and collect resource-level and service-level metrics of all services, as in previous works [ 25 , 39, 59 ]. To generate traffic, we use the load generators provided by these systems and customise them to explore all services with 100 to 200 users concurrently. We then introduce five common faults (CPU hog, memory leak, disk IO stress, network delay, and packet loss) into five different services within each system. Finally, we collect metrics data before and after the fault injection operation. An overview of our setup is presented in the Figure below.</p> <p></p> <p><strong>Code</strong></p> <p>The code to reproduce the experimental results in the paper is available at <a href="https://github.com/phamquiluan/RCAEval">https://github.com/phamquiluan/RCAEval</a>.</p> <p><strong>References</strong></p> <p>As in our paper.</p>
Questionnaire Data Management in Microservices
<p>Questionnaire used in the work "Data Management in Microservices: State of the Practice, Challenges, and Research Directions"</p>
Microservice Security: A Systematic Literature Review, dataset
<p>This is the Bibliographic Dataset on Microservices and Security of the paper: Microservice Security: A Systematic Literature Review</p>
Comparing 2D and Augmented Reality Visualizations for Microservice System Understandability: Protocol And Dataset
<p>Comparing 2D and Augmented Reality Visualizations for Microservice System Understandability: Dataset.</p> <p>This dataset includes:</p> <ol> <li>The tools executable files and JSON representations.</li> <li>The tools screenshots.</li> <li>The participants classification data.</li> <li>Questionnaire Form.</li> <li>Training Materials.</li> <li>Testing Tasks.</li> </ol> <p> </p> <p><strong>Our Paper is at ICPC conference with title</strong>: Comparing 2D and Augmented Reality Visualizations for Microservice System Understandability: A Controlled Experiment</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.