Taming Complexity: On Studying the Application of Model-Driven Engineering to the Design, Development, and Operation of Microservice Architectures

Taming Complexity: On Studying the Application of
Model-Driven Engineering to the Design, Development, and
Operation of Microservice Architectures
Webinar of the Microservice Community’s Research Group
Florian Rademacher
florian.rademacher@fh-dortmund.de
October 20, 2021
IDiAL Institute, University of Applied Sciences and Arts Dortmund

Table of Contents
Introduction
Model-Driven Engineering
Research Statement
Investigation of Research Question 1
Selected Ongoing and Future Work
Stimulate DevOps Adoption by Small and Medium-Sized Organizations
Model-Based Microservice Architecture Reconstruction
Quality-Driven Microservice Architecture Engineering

Table of Contents
Introduction
Research Statement
Florian Rademacher Studying the Application of Model-Driven Engineering in Microservice Architecture Engineering 1

whoami
• Florian Rademacher
• PhD Student in Computer Science @ University of Kassel, and
University of Applied Sciences and Arts Dortmund (FH Dortmund)
• Research Associate @ IDiAL Institute of FH Dortmund
• Research Interests
• Distributed software architectures
• Model-Driven Engineering (MDE)
• Software Language Engineering
• PhD Thesis: “A Language Ecosystem for Modeling Microservice
Architecture” (submitted)
• Member of the Microservice Community’s Communication Group
• florian.rademacher@fh-dortmund.de
• frademacher@microservices.community
• MC Discord Server W, MC Mailing List W, 7/c_microservices

Our Research Group
• Smart Environments Engineering Laboratory (SEELAB) @ IDiAL Institute
• ~15 research associates (six PhD students) and scientific software developers
• Led by Prof. Dr. Sabine Sachweh
• Applied research projects in areas like. . .
. . . e-Health
. . . Internet of Things
. . . Smart City
. . . Smart Manufacturing
• Research focus on topics like. . .
. . . Adaptive User Interfaces
. . . Artificial Intelligence
. . . MDE
. . . Software Architecture

Table of Contents
Introduction
Research Statement

Model-Driven Engineering (MDE)
• Software Engineering paradigm that uses models throughout all or selected
phases of the Software Engineering process [10]
• In MDE, a model is usually a Software Engineering artifact that. . .
. . . abstracts from selected properties of an anticipated or existing software system
. . . can be created, maintained, and understood by humans
. . . is (semi-) automatically processible by computer programs
• Common Goal of MDE: Elevating models’ purposes from documentation artifacts
to first-class citizens in the Software Engineering process

• Major concepts of MDE [10]
• Modeling Languages: Prescribe the set of well-defined models (syntax and
semantics), and provide means to construct and maintain valid models (pragmatics)
• Model Transformations: Prescribe rule sets to derive one or more target artifacts
from one or more source models
• Example
• Modeling Language(s): UML [35]
• UML-Based Model:
Person
- firstname : String
- lastname : String
Student
- enrollmentNumber : String
- program : Program
• Model Transformation:
Person
- firstname : String
- lastname : String
Student
- enrollmentNumber : String
- program : Program
⇒
class Student extends Person {
private String enrollmentNumber;
...
}
class Person {
private String firstname;
...
}

• Expected benefits of MDE (sample) [10, 51, 9, 26]
• Complexity Reduction: Introduce supportive abstractions for selected properties of
a software system, and provide means to comprehend and manage these
abstractions
⇒ Allow stakeholders without technical background to actively participate in the
Software Engineering process
• Value Increase of Models: Introduce processing means for existing
(documentation) models to integrate them with additional phases of the Software
Engineering process
• Quality Increase: Automatically incorporate, e.g., patterns, bugfixes, or best
practices, into generated source code or analyze models for quality attribute
assessment

Table of Contents
Introduction
Research Statement

Research Statement: Motivation
• Microservice Architecture (MSA) engineering is inherently complex along different
dimensions [44]
• Typical Design Challenges
• “Correct” service identification and granularity determination
• Design techniques like Domain-Driven Design (DDD) [14] are frequently used in
MSA engineering [29, 15, 28] but also appear too complex and/or not rigorous
enough to practitioners [8]
• Typical Implementation Challenges
• Increased risk for technical debt, additional maintainability cost, and steeper learning
curves due to technology heterogeneity [48]
• Technology management is more complex given an increased set of potential
technology variation points [39]

Research Statement: Motivation
• Microservice Architecture (MSA) engineering is inherently complex along different
dimensions [44]
• Typical Operation Challenge
• Necessity of additional infrastructure components, e.g., container orchestration
platforms, service discoveries, and API gateways, that often leverage diverse
technologies with their own configuration requirements and profiles, and
lifecycles [3, 44]
• Typical Organizational Challenge
• MSA fosters DevOps and a collaborative team culture [31, 27], which both assume
automation and efficient knowledge sharing

Research Statement
Research Statement
To investigate the applicability of MDE means in the design, implementation, and
operation of microservice architectures to effectively cope with the inherent
complexity of MSA engineering.

Research Statement: Research Questions (RQs)
RQ 1: Modeling Languages
How do modeling languages for the application of MDE to MSA engineering need to
be constituted?
• Guide stakeholders in MSA design activities
• Allow the management and selective application of heterogeneous technology
information
• Harmonize infrastructure configuration
• Foster efficient knowledge sharing within and across MSA teams

Research Statement: Research Questions (RQs)
RQ 2: Model Processing
How can models, which were constructed with the modeling languages (cf. RQ 1), be
used besides architecture documentation?
• Foster automation within and across MSA teams, e.g., via the generation of
boilerplate code and consistent API specifications
• Allow metrics-based quality assessment
• Allow technical MSA stakeholders, e.g., service developers, without an MDE
background to implement custom model processors

Table of Contents
Introduction
Research Statement

Investigation of RQ 1: Modeling Languages
RQ 1: Modeling Languages
How do modeling languages for the application of MDE to MSA engineering need to
be constituted?
• Research approach:
1. Modeling concept identification through a survey of conceptual frameworks for
the engineering of Service-Based Software Architectures [6, 30, 50, 33, 36, 34]
(results: [37])
2. Concept refinement through an analysis of seven non-trivial open source
microservice architectures [28, 43]
3. Concept clustering based on the concerns [4] and viewpoints [22] of stakeholders
in MSA engineering (results: [39, 41])
4. Languages’ implementation using the Eclipse Modeling Framework [47]
5. Languages’ validation and empirical assessment of quality in use
(results: [42], [46] (preliminary))

Figure 1: Modeling languages and their supported model kinds

Figure 2: Modeling languages and their supported model kinds (including viewpoints)

Figure 3: Modeling languages and their supported model kinds (including stakeholders)

• Modeling Example: Platform for the Management of Charging Stations for Electric Vehicles [42]
1 context ChargingStationManagement {
2 structure ElectrifiedParkingSpace<entity, aggregate> {
3 string id<identifier>,
4 string name,
5 string plugType,
6 ChargingType chargingType<part>,
7 ParkingSpaceSize parkingSpaceSize<part>,
8 ...
9 }
10 enum ChargingType{ FAST, NORMAL }
11 structure ElectrifiedParkingSpaceCreated<valueObject, domainEvent> {
12 immutable string name,
13 ...
14 }
15 }
Y Domain
Listing 1: Excerpt of the microservice’s domain model

1 technology CQRS {
2 service aspects {
3 aspect CommandSide for microservices { string logicalService; }
4 aspect QuerySide for microservices { string logicalService; }
5 }
6 }
1 technology Kafka {
2 protocols {
3 async kafka data formats "binary" default with format "binary";
4 }
5 service aspects {
6 aspect Participant for operations {
7 selector(protocol = kafka);
8 string topic<mandatory>;
9 string consumerGroup;
10 }
11 }
12 }
Y Technology
Y Technology
Listings 2 and 3: Excerpts of technology models

1 ...
2 import datatypes from "domain.data" as Domain
3 import technology from "Kafka.technology" as Kafka
4 import technology from "Cqrs.technology" as CQRS
5 ...
6 @technology(Kafka)
7 @technology(CQRS)
8 @endpoints(Kafka::_protocols.kafka: "kafka-server1:9092";)
9 @CQRS::_aspects.CommandSide("ChargingStationManagement")
10 functional microservice de.fhdo.puls.ChargingStationManagementCommand {
11 ...
12 interface Commands {
13 ...
14 @Kafka::_aspects.Participant(topic="parkingSpaceCreatedEvents")
15 sendParkingSpaceCreatedEvent(async out event
16 : Domain::ChargingStationManagement
17 .ElectrifiedParkingSpaceCreated);
18 }
19 }
Y Service
Listing 4: Excerpt of the command side microservice’s service
model

1
import technology from "Kubernetes.technology" as Kubernetes
2
import microservices from "micro.services" as Services
3
import nodes from "infrastructure.operation" as Infrastructure
4
5
@technology(Kubernetes)
6
container ChargingStationManagementCommandContainer
7
deployment technology Kubernetes::_deployment.Kubernetes
8
with operation environment "openjdk:11-jdk-slim"
9
deploys Services::de.fhdo.puls.ChargingStationManagementCommand
10
depends on nodes
11
Infrastructure::IDM, Infrastructure::MessageBroker,
12
Infrastructure::MongoDB, Infrastructure::ServiceDiscovery
13
{
14
default values {
15
port=8071
16
...
17
}
18
}
Y Operation
Listing 5: Excerpt of the command side microservice’s operation
model

• Results concerning the languages’ applicability
• Higher effectiveness than UML-based modeling for MSA [46] (preliminary results)
• Top-down construction of new and reconstruction of existing microservice
architectures from heterogeneous domains, and with differing architecture patterns
and communication paradigms is possible [42, 38]

Table of Contents
Introduction
Research Statement

Investigation of RQ 2: Model Processing
RQ 2: Model Processing
How can models, which were constructed with the modeling languages (cf. RQ 1), be
used besides architecture documentation?
• Research approach:
1. Selection of initial, supportive model processing purposes for MSA
engineering: Code generation, quality assessment through static model analysis
2. Design and implementation of a model processing framework that allows model
processor implementation for identified purposes and through technical MSA
stakeholders without an MDE background
3. Validate framework applicability w.r.t. our modeling languages for code
generation taking MSA’s technology heterogeneity and distributed microservice
development into account
4. Validate framework applicability w.r.t. our modeling languages for static model
analysis based on MSA-related quality metrics suites [20, 2, 19, 13]

• Applying the framework for code generation: Available generators and plugins
• Java Base Generator with plugins for CQRS, DDD, Domain Events, Spring, and
Kafka
• Net ratio between manual model code and generated boilerplate code for the Charging
Station Management Microservice’s command side (cf. Slides 19–22): 4.49 (i.e., net
generation of 804 lines of service code from 179 lines of model code)
• Docker and Kubernetes
• MariaDB and MongoDB
• Eureka
• Keycloak (WIP)
• Zuul

• Applying the framework for quality assessment through static model analysis
• Survey of four metrics suites [20, 2, 19, 13], which are applicable to MSA
engineering [7]
• Implementation of a static model analyzer that supports 20 out of 26 metrics from
the suites
• Cohesion assessment based on, e.g., interface, message, and domain object similarity
• Complexity assessment based on, e.g., structural microservice characteristics
(capability scope, API composition, managed resources etc.), state management, and
interaction dependencies
• Size assessment based on, e.g., message size (heuristic for lower bound)

A Language Ecosystem for Modeling Microservice Architecture
LEMMA
We consider the combination of our modeling languages, model processing
framework, and model processors an ecosystem for model-driven MSA engineering
and call it LEMMA (“Language Ecosystem for Modeling Microservice Architecture”).

Table of Contents
Introduction
Research Statement

Applying LEMMA to Stimulate DevOps Adoption by SMOs
• Overview of results from a recent study of employing LEMMA (and thus MDE) for
MSA engineering in small and medium-sized organizations (SMOs)
Figure 4: Article published in Springer Nature Computer Science (Open Access W)

• Insights from a secondary analysis of interviews conducted for a previous
comparative multi-case study with five professional software architects
responsible for microservice architectures in SMOs [45]:
I.1 OpenAPI/Swagger is the most prominent approach to specify service APIs
(and the only one to document APIs)
I.2 The configuration and maintenance of deployment and operation infrastructure is too
complex for cross-functional teams and thus in the responsibility of dedicated
operation teams, which contradicts MSA’s ownership principle [32]
I.3 Besides one case, API specifications are not collected and provided using a
centralized system but exchanged upon explicit request, e.g., via email
I.4 SMOs consider the establishment of a common architectural understanding
important but lack human and time resources to tackle this challenge in an
appropriate manner

• Proposal of a LEMMA-based workflow to stimulate DevOps adoption by SMOs
based on the aforementioned insights:
• Teams derive LEMMA domain and service models from OpenAPI specifications via
an automated model transformation (I.1)
• Teams accompany the derived models with operation models in the harmonizing
syntax of LEMMA’s Operation Modeling Language, and generate
technology-specific deployment and operation configurations from the models (I.2)
• All team-specific models are collected centrally and model processors gather
information to foster a common architectural understanding (e.g., visualizations of
service APIs or dependencies; I.3 and I.4)

• Validation of the workflow and its implementation for a complete case study
architecture
• Future Work: Perform an in-depth evaluation with more case studies from SMOs

Table of Contents
Introduction
Research Statement

Applying LEMMA for Microservice Architecture Reconstruction
• Since MSA fosters team independence, microservice architectures are particularly
exposed to deviate from an anticipated architecture design over time [1]
⇒ Studying the application of (semi-) automated approaches to Software Architecture
Reconstruction (SAR) [4] is sensible in the context of MSA [11]
• LEMMA’s modeling languages seem expressive enough to reconstruct significant
structural information about microservice architectures [38]
• One of our current works aims to automate LEMMA-based SAR using static
analysis of microservice artifacts (API specifications, source code etc.)

Applying LEMMA for Microservice Architecture Reconstruction
• Future Work: Extend LEMMA with constructs/languages to express dynamic
information about microservice architectures (e.g., service-level behavior
specification [16] or architecture-level process specification)

Table of Contents
Introduction
Research Statement

Applying LEMMA for Quality-Driven MSA Engineering
• LEMMA’s static analyzer currently supports the assessment of
service/architecture cohesion, complexity, and size based on different metrics
• While cohesion, complexity, and size target the Maintainability quality
attribute [21], we believe the static analysis of LEMMA models to also contribute in
the assessment of Portability and Compatibility
• In addition, LEMMA’s integration with existing model-based approaches for
performance analysis [12, 5] could be sensible to assess the Performance
Efficiency of services/architectures

Applying LEMMA for Quality-Driven MSA Engineering
• Future Work:
• Extend LEMMA’s static analyzer with support for further metrics of other quality
attributes than Maintainability
• Provide LEMMA users with IDE support to assess quality at the time of model
construction
• Combine with code generation to retrieve a “quality-by-construction” approach for
MSA engineering

Resources
• Publications with further details about LEMMA:
• Initial motivation and language design: [41, 39]
• Using LEMMA in the domain-driven design of microservice architectures: [40]
• Methodology for LEMMA-based SAR of microservice architectures: [38]
• Complete list of publications: DBLP W
• LEMMA source code: ‡ GitHub W
• LEMMA documentation (WIP): https://seelabfhdo.github.io/lemma-docs W
• Model Processor Example: ‡ GitHub W
• Static Analyzer: ‡ Library W, ‡ Executable W
• florian.rademacher@fh-dortmund.de

Overview of Related Work
• Since LEMMA’s inception, several studies and solution proposals that also
investigate the adoption of MDE/architecture modeling in MSA engineering were
published:
• Domain Modeling: [25, 24, 23]
• Service Modeling: [18, 49, 23]
• Model-Based Architecture Reconstruction: [17, 1]

Literature
[1] Nuha Alshuqayran, Nour Ali, and Roger Evans. “Towards Micro Service
Architecture Recovery: An Empirical Study.” In:
2018 IEEE International Conference on Software Architecture (ICSA). IEEE,
2018, pp. 47–56.
[2] Dionysis Athanasopoulos et al. “Cohesion-Driven Decomposition of Service
Interfaces without Access to Source Code.” In:
IEEE Transactions on Services Computing 8.4 (2015). IEEE, pp. 550–562.

Literature
[3] Armin Balalaie, Abbas Heydarnoori, and Pooyan Jamshidi. “Migrating to
Cloud-Native Architectures Using Microservices: An Experience Report. kry.” In:
Advances in Service-Oriented and Cloud Computing. Ed. by Antonio Celesti and
Philipp Leitner. Cham: Springer, 2016, pp. 201–215.
[4] Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice.
Third. Addison-Wesley, 2013.
[5] Steffen Becker, Heiko Koziolek, and Ralf Reussner. “The Palladio component
model for model-driven performance prediction.” In:
Journal of Systems and Software 82.1 (2009). Elsevier, pp. 3–22.

Literature
[6] Gorka Benguria et al. “A Platform Independent Model for Service Oriented
Architectures.” In: Enterprise Interoperability. Ed. by Guy Doumeingts et al.
London: Springer, 2007, pp. 23–32.
[7] Justus Bogner. “On the evolvability assurance of microservices: metrics,
scenarios, and patterns.” PhD thesis. University of Stuttgart, 2020.
[8] Justus Bogner et al. “Microservices in Industry: Insights into Technologies,
Characteristics, and Software Quality.” In:
2019 IEEE International Conference on Software Architecture Companion (ICSA-C).
IEEE, Mar. 2019, pp. 187–195.
[9] Marco Brambilla, Jordi Cabot, and Manuel Wimmer.
Model-Driven Software Engineering in Practice. First. Morgan & Claypool, 2012.

Literature
[10] Benoit Combemale et al.
Engineering Modeling Languages: Turning Domain Knowledge into Tools. First.
CRC Press, 2017.
[11] Paolo Di Francesco, Ivano Malavolta, and Patricia Lago. “Research on
Architecting Microservices: Trends, Focus, and Potential for Industrial Adoption.”
In: 2017 IEEE International Conference on Software Architecture (ICSA). IEEE,
Apr. 2017, pp. 21–30.

Literature
[12] Thomas F. Düllmann and André van Hoorn. “Model-Driven Generation of
Microservice Architectures for Benchmarking Performance and Resilience
Engineering Approaches.” In:
Proceedings of the 8th ACM/SPEC on International Conference on Performance Engine
ICPE ’17 Companion. L’Aquila, Italy: ACM, 2017, pp. 171–172.
[13] Thomas Engel et al. “Evaluation of Microservice Architectures: A Metric and
Tool-Based Approach.” In: Information Systems in the Big Data Era. Ed. by
Jan Mendling and Haralambos Mouratidis. Cham: Springer, 2018, pp. 74–89.
[14] Eric Evans. Domain-Driven Design. First. Addison-Wesley, 2004.

Literature
[15] Martin Garriga. “Towards a Taxonomy of Microservices Architectures.” In:
Software Engineering and Formal Methods. Ed. by Antonio Cerone and
Marco Roveri. Cham: Springer, 2018, pp. 203–218.
[16] Saverio Giallorenzo et al. “Jolie and LEMMA: Model-Driven Engineering and
Programming Languages Meet on Microservices.” In:
Coordination Models and Languages. Ed. by Ferruccio Damiani and
Ornela Dardha. Cham: Springer, 2021, pp. 276–284.
[17] Giona Granchelli et al. “Towards Recovering the Software Architecture of
Microservice-Based Systems.” In:
2017 IEEE International Conference on Software Architecture Workshops (ICSAW).
IEEE, 2017, pp. 46–53.

Literature
[18] Sara Hassan, Nour Ali, and Rami Bahsoon. “Microservice Ambients: An
Architectural Meta-Modelling Approach for Microservice Granularity.” In:
2017, pp. 1–10.
[19] Florian Haupt et al. “A Framework for the Structural Analysis of REST APIs.” In:
2017 IEEE International Conference on Software Architecture (ICSA). Springer,
2017, pp. 55–58.

Literature
[20] Mamoun Hirzalla, Jane Cleland-Huang, and Ali Arsanjani. “A Metrics Suite for
Evaluating Flexibility and Complexity in Service Oriented Architectures.” In:
Service-Oriented Computing – ICSOC 2008 Workshops. Ed. by
George Feuerlicht and Winfried Lamersdorf. Berlin, Heidelberg: Springer, 2009,
pp. 41–52.
[21] ISO/IEC.
Systems and software engineering — Systems and software Quality Requirements and
Standard ISO/IEC 25010:2011(E). International Organization for
Standardization/International Electrotechnical Commission, 2011.

Literature
[22] ISO/IEC/IEEE. Systems and software engineering — Architecture description.
Standard ISO/IEC/IEEE 42010:2011(E). International Organization for
Standardization/International Electrotechnical Commission/Institute of Electrical
and Electronics Engineers, 2011.
[23] JHipster Domain Language (JDL). URL: https://www.jhipster.tech/jdl.
[24] Stefan Kapferer and Olaf Zimmermann. “Domain-Driven Service Design.” In:
Service-Oriented Computing. Ed. by Schahram Dustdar. Cham: Springer, 2020,
pp. 189–208.

Literature
[25] Stefan Kapferer and Olaf Zimmermann. “Domain-specific Language and Tools
for Strategic Domain-driven Design, Context Mapping and Bounded Context
Modeling.” In:
Proceedings of the 8th International Conference on Model-Driven Engineering and Soft
INSTICC. SciTePress, 2020, pp. 299–306.
[26] Steven Kelly and Juha-Pekka Tolvanen.
Domain-specific modeling: Enabling Full Code Generation. First. Wiley, 2008.

Literature
[27] Welder Pinheiro Luz, Gustavo Pinto, and Rodrigo Bonifácio. “Building a
Collaborative
Culture: A Grounded Theory of Well Succeeded DevOps Adoption in Practice.” In:
Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software En
ESEM ’18. Oulu, Finland: ACM, 2018, 6:1–6:10.
[28] Gastón Márquez, Mónica M. Villegas, and Hernán Astudillo. “A Pattern
Language for Scalable Microservices-based Systems.” In:
Proceedings of the 12th European Conference on Software Architecture: Companion P
ECSA ’18. Madrid, Spain: ACM, 2018, 24:1–24:7.

Literature
[29] Genc Mazlami, Jürgen Cito, and Philipp Leitner. “Extraction of Microservices
from Monolithic Software Architectures.” In:
2017 IEEE International Conference on Web Services (ICWS). IEEE, June
2017, pp. 524–531.
[30] Methodologies Corporation.
Service-oriented modeling framework (SOMF) Version 2.1. 2011.
[31] Irakli Nadareishvili et al.
Microservice Architecture: Aligning Principles, Practices, and Culture. First.
O’Reilly, 2016.
[32] Sam Newman. Building Microservices: Designing Fine-Grained Systems. First.
O’Reilly, 2015.

Literature
[33] OASIS.
Reference Architecture Foundation for Service Oriented Architecture Version 1.0.
Standard OASIS Committee Specification 01. Organization for the Advancement
of Structured Information Standards, 2012.
[34] OASIS.
Topology and Orchestration Specification for Cloud Applications Version 1.0.
Standard. Organization for the Advancement of Structured Information
Standards, 2013.
[35] OMG. OMG Unified Modeling Language (OMG UML) Version 2.5.1. Standard
formal/17-12-05. Object Management Group, 2017.

Literature
[36] OMG.
Service oriented architecture Modeling Language (SoaML) Specification Version 1.0.1.
Standard. Object Management Group, 2012.
[37] Florian Rademacher. “An Overview of Modeling Concepts for Service-Based
Software Architectures.” In: Software Engineering Publications. Kasseler Online
Bibliothek, Repository und Archiv (KOBRA), 2020.
[38] Florian Rademacher, Sabine Sachweh, and Albert Zündorf. “A Modeling Method
for Systematic Architecture Reconstruction of Microservice-Based Software
Systems.” In: Enterprise, Business-Process and Information Systems Modeling.
Ed. by Selmin Nurcan et al. Springer, 2020, pp. 311–326.

Literature
[39] Florian Rademacher, Sabine Sachweh, and Albert Zündorf. “Aspect-Oriented
Modeling of Technology Heterogeneity in Microservice Architecture.” In:
2019, pp. 21–30.
[40] Florian Rademacher, Sabine Sachweh, and Albert Zündorf. “Deriving
Microservice Code from Underspecified Domain Models Using DevOps-Enabled
Modeling Languages and Model Transformations.” In:
2020 46th Euromicro Conference on Software Engineering and Advanced Applications
IEEE, 2020, pp. 229–236.

Literature
[41] Florian Rademacher et al. “Graphical and Textual Model-Driven Microservice
Development.” In: Microservices: Science and Engineering. Ed. by
Antonio Bucchiarone et al. Springer, 2020, pp. 147–179.
[42] Florian Rademacher
et al. “Towards Holistic Modeling of Microservice Architectures Using LEMMA.” In:
Companion Proceedings of the 15th European Conference on Software Architecture 20
CEUR-WS, 2021, pp. 1–10.
[43] Mohammad Imranur Rahman, Sebastiano Panichella, and Davide Taibi. “A
Curated Dataset of Microservices-Based Systems.” In:
Joint Proceedings of the Inforte Summer School on Software Maintenance and Evolutio
CEUR-WS, 2019, pp. 1–9.

Literature
[44] Jacopo Soldani, Damian Andrew Tamburri, and Willem-Jan Van Den Heuvel.
“The pains and gains of microservices: A Systematic grey literature review.” In:
Journal of Systems and Software 146 (2018). Elsevier, pp. 215–232.
[45] Jonas Sorgalla, Sabine Sachweh, and Albert Zündorf. “Exploring the
Microservice Development Process in Small and Medium-Sized Organizations.”
In: Product-Focused Software Process Improvement. Ed. by Maurizio Morisio,
Marco Torchiano, and Andreas Jedlitschka. Cham: Springer, 2020, pp. 453–460.
[46] Jonas Sorgalla et al. “Model-driven Development of Microservice Architecture:
An Experiment on the Quality in Use of a UML- and a DSL-based Approach.” In:
Software Engineering Publications. Kasseler Online Bibliothek, Repository und
Archiv (KOBRA), 2020.

Literature
[47] Dave Steinberg et al. EMF: Eclipse Modeling Framework. Second.
Addison-Wesley, 2008.
[48] Davide Taibi and Valentina Lenarduzzi. “On the Definition of Microservice Bad
Smells.” In: IEEE Software 35.3 (May 2018). IEEE, pp. 56–62.
[49] Branko Terzić et al. “Development and evaluation of MicroBuilder: a
Model-Driven tool for the specification of REST Microservice Software
Architectures.” In: Enterprise Information Systems 12.8-9 (2018). Taylor &
Francis, pp. 1034–1057. eprint:
https://doi.org/10.1080/17517575.2018.1460766.
[50] The Open Group. SOA Reference Architecture. C119. 2011.

Literature
[51] Jon Whittle, John Hutchinson, and Mark Rouncefield. “The State of Practice in
Model-Driven Engineering.” In: IEEE Software 31.3 (May 2014). IEEE,
pp. 79–85.

Taming Complexity: On Studying the Application of Model-Driven Engineering to the Design, Development, and Operation of Microservice Architectures

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Taming Complexity: On Studying the Application of Model-Driven Engineering to the Design, Development, and Operation of Microservice Architectures

Similar to Taming Complexity: On Studying the Application of Model-Driven Engineering to the Design, Development, and Operation of Microservice Architectures (20)

Recently uploaded

Recently uploaded (20)

Taming Complexity: On Studying the Application of Model-Driven Engineering to the Design, Development, and Operation of Microservice Architectures