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.
31
datasets available to search
ShareScore release 0.9.0
Dataset results
31 results for “Microservice Architecture”
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>
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>
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>
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>
Towards a method for monitoring the coupling evolution of microservice-based architectures
<p>Backup video for the presentation of the paper "Towards a method for monitoring the coupling evolution of microservice-based architectures", published in SBCARS - CBSoft 2020</p>
Replication Package for: Theodolite: Scalability Benchmarking of Distributed Stream Processing Engines in Microservice Architectures
<p>This repository contains a replication package and experimental results for our study <em>Theodolite: Scalability Benchmarking of Distributed Stream Processing Engines in Microservice Architectures</em>.</p> <p>The following description can also be found in the README.md file.</p> <p><strong>Repeating Benchmark Execution</strong></p> <p><em><strong>The following introduction describes how to repeat our scalability experiments. If you plan to conduct your own studies, we suggest to use the latest version of <a href="https://github.com/cau-se/theodolite">Theodolite</a> with significantly enhanced usability.</strong></em></p> <p>The Apache Kafka Streams scalability experiments of our study were executed with <a href="https://github.com/cau-se/theodolite/tree/v0.1.2">Theodolite v0.1.2</a>. To repeat our Kafka Streams experiments:</p> <ol> <li>Clone and install <a href="https://github.com/cau-se/theodolite/tree/v0.1.2">Theodolite v0.1.2</a> according to the official documentation located in <code>execution</code>.</li> <li>Copy the file <code>repeat-kstream.sh</code> into Theodolite's <code>execution</code> directory.</li> <li>Run the repetition file with <code>./repeat-kstream.sh</code> from within the <code>execution</code> directory.</li> </ol> <p>Our Apache Flink benchmark implementations are currently migrated to the latest version of Theodolite. <a href="https://github.com/cau-se/theodolite/tree/apache-flink">Theodolite's <code>apache-flink</code> Branch</a> provides the basis for our Flink scalability experiments. To repeat them:</p> <ol> <li>Clone <a href="https://github.com/cau-se/theodolite/tree/apache-flink">Theodolite's <code>apache-flink</code> Branch</a> and install Theodolite according to the official documentation located in <code>execution</code> (should be identical to the installation for Kafka Streams (see above)).</li> <li>Copy the files <code>repeat-flink-without-checkpointing.sh</code> and <code>repeat-flink-with-checkpointing.sh</code> into Theodolite's <code>execution</code> directory.</li> <li>Switch to the <code>execution</code> directory.</li> <li>Run the first repetition file with <code>./repeat-flink-with-checkpointing.sh</code>.</li> <li>Disable checkpointing by reconfiguring the Kubernetes resources <code>jobmanager-job.yaml</code> and <code>taskmanager-job-deployment.yaml</code> for each benchmark (<code>uc{1,2,3,4}-application</code>) by setting the environment variable <code>CHECKPOINTING</code> to <code>"false"</code>.</li> <li>Run the second repetition file with <code>./repeat-flink-without-checkpointing.sh</code>.</li> </ol> <p><em>Please note that the naming of our benchmarks recently changed. While our publication already uses the new naming, the corresponding Theodolite versions are is still using the old one. Specifically, this means that UC1 in the publication is UC1 in Theodolite, UC2 in the publication is UC3 in Theodolite, UC3 in the publication is UC4 in Theodolite, and UC4 in the publication is UC2 in Theodolite.</em></p> <p><strong>Raw Measurements</strong></p> <p>The results of above benchmark execution can be found in the <code>measurements</code> directory. These are CSV files, containing the measured lag trend over time for a certain subexperiment. Theodolite creates a bunch of additional files, which serve for debugging and preliminary interpretation. As these files are not required for replication, we do not included them in this package.</p> <p>The CSV files are named according to the schema <code>exp{id}_{uc}_{load}_{inst}_totallag.csv</code>, where <code>{id}</code> represents the experiment ID, assigned by Theodolite, <code>{uc}</code> the benchmark name, <code>{load}</code> the generated load, and <code>{inst}</code> the number of evaluated instances.</p> <p>The CSV table <code>experiments.csv</code> provides an overview about the configurations used in each experiment.</p> <p><strong>Reproducing Scalability Analysis</strong></p> <p><em><strong>The following introduction describes how to repeat our scalability analysis, either with our measurements or with your own. If you plan to conduct your own studies, we suggest to use the latest version of <a href="https://github.com/cau-se/theodolite">Theodolite</a> with significantly enhanced usability.</strong></em></p> <p>Analyzing the Theodolite's measurements is done using two Jupyter notebooks. In general, these notebooks should be runnable by any Jupyter server. Python 3.7 or 3.8 is required (e.g., in a virtual environment) as well as some Python libraries, which can be installed via: <code>pip install -r requirements.txt</code>. See the <a href="https://github.com/cau-se/theodolite/tree/master/analysis">Theodolite documentation</a> for additional installation guidance.</p> <p><strong>Obtaining a Scalability Graph as a CSV File</strong></p> <p>The <code>scalability-graph.ipynb</code> notebook combines the measurements (i.e., the <code>totallag.csv</code> files) of one experiment. It produces a CSV file, which provides a mapping of load intensities to minimum required resources for that load (i.e., the scalability graph). The CSV files are named according to the schema <code>exp{id}_min-suitable-instances.csv</code>, where <code>{id}</code> represents the experiment ID. Additional guidance is provided in the notebook.</p> <p><strong>Resulting Scalability Graph CSV Files</strong></p> <p>The <code>results</code> directory provides the scalability graphs for all our executed experiments.</p> <p><strong>Visualization of the Scalability Graph</strong></p> <p>The <code>scalability-graph-plotter.ipynb</code> notebook creates PDF plots of a scalability graph and allows to combine multiple scalability graphs in one plot. It can be adjusted to match the desired visualization.</p> <p><strong>Acknowledgments</strong></p> <p>This research is funded by the German Federal Ministry of Education and Research (BMBF) under grant no. 01IS17084 and is part of the <a href="https://www.industrial-devops.org">Titan project</a>.</p>
Data from paper: Semi-automatic Feedback for Improving Architecture Conformance to Microservice Patterns and Practices
<p>All the data of the study <strong><em>Semi-automatic Feedback for Improving Architecture Conformance to Microservice Patterns and Practices. The file contains all the scripts and models of this study</em></strong></p>
Overview of the dependency taxonomy, dependencies from the literature, tools, and benchmarks relationships in Microservice Architecture.
<p>This figure is part of the publication titled "Multivocal Study in Microservice Dependencies".</p>
Automated Performance Regression Detection in Microservice Architectures - Raw Measurements
<p>These measurements contain a ZIP folder in which influxdb dumps of the several load testing runs of the corresponding bachelor's thesis "Automated Performance Regression Detection in Microservice Architectures" can be found. The dumps are named by date. The two dumps which are additionally named, contain the data sets which were used for the final evaluation.</p>
Improving Comprehensibility of Event-Driven Microservice Architectures by Graph-Based Visualizations
<p>These are the anonymized protocols from our initial interviews and the raw data from the evaluation.</p>
An Empirical Study on Challenges of Event Management in Microservice Architectures
<p>Data set of the submitted manuscript "An Empirical Study on Challenges of Event Management in Microservice Architectures"</p>
Software Architecture Reconstruction for Microservice Systems Using GraalVM Native Image
<p>This Dataset contains the System Architecture Reconstruction for Train-Ticket microservice benchmark.</p> <p>It includes: Manual Analysis, GraalVM Analysis, and Source code Analysis.</p> <p>It's described in a paper with title: Software Architecture Reconstruction for Microservice Systems Using GraalVM Native Image</p> <p> </p>
Extracting the Architecture of Microservices: An Approach for Explainability and Traceability
<p>Dataset and replication package</p>
Performance Anomaly Detection in Microservice Architectures under Continuous Change
<p>Supplementary material for the master's thesis<br> <strong>"Performance Anomaly Detection in Microservice Architectures under Continuous Change"</strong><br> of<br> <strong>Thomas F. Düllmann</strong></p> <p><br> The folder for the supplemental material is structured as follows:.</p> <ul> <li><strong>abstract-de.txt</strong> (abstract in german)</li> <li><strong>abstract-en.txt</strong> (abstract in english)</li> <li><strong>01-MicroserviceMetamodel</strong> (Eclipse project containing the Ecore meta model and the Xtend generation template)</li> <li><strong>02-AnomalyDetectionImplementation</strong> (Eclipse project containing the implementation of the customized RanCorr approach and the EAR approach) <ul> <li><strong>EARExperimentSetup</strong> (the Evaluation Setup that is run based on the input data from the experiment and the EAR implementation)</li> <li><strong>Kieker</strong> (Kieker and the customized RanCorr approach)</li> </ul> </li> <li><strong>03-ExperimentTools</strong> (supplementary microservices and scripts that were used for the experiment setup. The generated services need to be placed next to these files and have to have the folder prefix "gen-") <ul> <li><strong>jmeter</strong> (the microservice that is used for generating load)</li> <li><strong>jmsserver</strong> (the microservice that runs ActiveMQ to bundle the monitoring logs from the services)</li> <li><strong>monitoringserver</strong> (the microservice that collects the monitoring data from the jmsserver microservice and stores them)</li> <li><strong>registry</strong> (the microservice that is responsible for managing the delays that should be injected)</li> <li><strong>copyResults.sh</strong> (simple bash script that masks the scp command to copy the monitoring data from the monitoringserver to the local file system) </li> <li><strong>deployPackage.sh</strong> (bash script that uploads the docker images to defined remote systems via ssh and initiates the start of the microservices on a Kubernetes cluster using the said docker images)</li> <li><strong>dockerinit.sh</strong> (bash script that goes into the microservice folders to compile and package them and create the corresponding Docker images (useful if running minikube for example))</li> <li><strong>kubeinit.sh</strong> (bash script that starts the microservices on a Kubernetes cluster that is associated with the kubectl Kubernetes tool)</li> <li><strong>kubeclean.sh</strong> (bash script that removes the microservices from a Kubernetes cluster that is associated with the kubectl Kubernetes tool) </li> </ul> </li> <li><strong>04-EvaluationData</strong> <ul> <li><strong>RawData </strong> (the raw data that was extracted from the experiment environment) <ul> <li>kieker-monitoring-data (the Kieker monitoring data obtained from the experiment setup)</li> <li><strong>anomalies.log</strong> (the log data that shows the injected real anomalies)</li> <li><strong>events.log</strong> (log file that contains the timesstamps, the scope and the type of event injections)</li> <li><strong>registry.log</strong> (registry microservice log showing the injections of real and change anomalies)</li> </ul> </li> <li><strong>Results</strong> (results for the evaluation with different thresholds) <ul> <li><strong>*folders*</strong> (contain the results of the anomaly detection using the threshold represented by the folder name)</li> <li><strong>results.csv</strong> (the calulated results in terms of TP/FN/FP/FN for every approach with every threshold)</li> <li><strong>results-calculated.csv</strong> (further metrics that were calculated based on the TP/FN/FP/FN values)</li> </ul> </li> </ul> </li> <li><strong>05-EvaluationServices</strong> (the folders containing the microservices that were used for the evaluation)</li> </ul> <p> </p>
ARCHI4MOM: Using Tracing Information to Extract the Architecture of Microservice-based Systems from Message-oriented Middleware
<p>The data published here are relevant for ESCA_2022 publication. </p>
Anomalies in Microservice Architecture (train-ticket) based on version configurations
<p>The work contains ten datasets containing monitoring data (logs, Jaeger Traces and Prometheus KPI data). The datasets contain monitoring data from train-ticket, a benchmark system for microservices. The dataset includes a short description with explanations of identified anomalies.</p> <p>The structure of the folder is as follows:</p> <p><strong><changed-microservice>_<third-party-library>_<version>_<date-when-data-was-collected></strong></p> <p>Each folder stores the respective data:</p> <ol> <li>Logs: <ul> <li>original log file: LOGS_<change-microservice>_<third-party-library>_<Version>.txt</li> <li>parsed log files required for Loglizer (anomaly detection technique): <ul> <li>LOGS_<change-microservice>_<third-party-library>_<Version>.txt_structured.csv</li> <li>LOGS_<change-microservice>_<third-party-library>_<Version>.txt_templates.csv</li> </ul> </li> </ul> </li> <li>KPI Data: Monitoring_<change-microservice>_<third-party-library>_<Version></li> <li>Traces: Traces_<change-microservice>_<third-party-library>_<Version></li> </ol> <p> </p> <p> </p> <p> </p>
Additional Material for Beyond SonarQube: A Case Study on Technical Debt in a Large-Scale Industrial Microservice Architecture
<p>This upload contains the replication package for the study "Beyond SonarQube: A Case Study on Technical Debt in a Large-Scale Industrial Microservice Architecture" submitted for review on the ECSA 2024 Industry Track.<br><br>It contains the following:<br>Focus group-plan.pdf - The plan for the focus group discussion created by the authors.<br>Focus group slides.pdf - The slides used during the focus group discussion.<br>SonarQube measurement results.xlsx - Detailed results of the SonarQube analysis for each microservice in the researched system.</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.