Log In Sign Up

On Collaborative Model-driven Development of Microservices

Microservice Architecture (MSA) denotes an emerging architectural style for distributed and service-based systems whereby each microservice is highly cohesive and implements a single business capability. A microservice system consists of multiple, loosely coupled microservices. It provides complex capabilities through services interacting in choreographies. A single dedicated team, typically practicing DevOps, is responsible for each microservice, i.e., it "owns" the service. However, while systems relying on MSA have several architectural advantages especially for cloud applications, their realization is characterized by an increased accidental complexity due to redundant handcrafting of implementation, e.g., to make each service standalone runnable. A promising way to cope with such complexity is the usage of Model-driven Development (MDD) whereby models are used as first-class entities in the software development process. Although there are already first steps taken on how MDD could be applied by a single team to implement its microservices, the question of how MDD can be adapted to MSA's development distribution across multiple teams remains an issue. In this paper we envision the application of Collaborative Model-driven Software Engineering (CMDSE) to MDD of MSA by surveying relevant characteristics of CMDSE and identifying challenges for its application to MSA. The present paper takes a first step towards enabling holistic MDD of MSA across microservice teams.


page 1

page 2

page 3

page 4


X-Driven Methodologies for SOA System Development – A Survey

This study aims to evaluate four service-oriented architecture (SOA) sys...

DeepTriage: Automated Transfer Assistance for Incidents in Cloud Services

As cloud services are growing and generating high revenues, the cost of ...

Design and Implementation of a Remote Care Application Based on Microservice Architecture

Microservice Architecture (MSA) is an architectural style for service-ba...

Motivations, Benefits, and Issues for Adopting Micro-Frontends: A Multivocal Literature Review

[Context] Micro-Frontends are increasing in popularity, being adopted by...

1 Introduction and Background

Microservice Architecture (MSA) denotes an emerging architectural style for distributed and service-based systems [9]. As such, MSA relies on the service concept as the fundamental architectural building block for a system’s architecture. Each microservice is highly cohesive and represents a single business capability. Technically, a microservice is realized as an independent process that can be managed, i.e., designed, developed, deployed, and operated, autonomously. To realize complex business capabilities, multiple of these services can collaborate in service choreographies through interfaces [16]. Hereby, the service interaction is generally stateless and uses protocols like HTTP or AMQP111 [15]. Furthermore, each microservice is organizationally aligned to exactly one service team which usually practices DevOps [11]. Resulting applications relying on MSA are, among other characteristics, vertical as well as horizontal scalable, flexibly extensible and have short release cycles which makes them especially suitable for cloud applications like Spotify or Netflix [15].

However, the advantages of MSA in terms of increased scalability, resilience and technology heterogeneity [15] come at the cost of an increased accidental complexity regarding the overall system development [16]. One reason for this increased complexity is that microservice architectures, compared to monolithic applications, are distributed by nature [8]. Resulting from this distribution, the realization of multiple services involves extensive and redundant handcrafting of implementation, e.g., to make each service independently runnable, or to provide and consume the necessary interfaces for complex operations [24].

An approach to cope with the accidental complexity of complex, distributed software systems such as MSA is Model-driven Development (MDD) [8]. MDD denotes the usage of models as first-class entities in the software development process. Applied to MSA, developers would use a modeling language to design services and use a Model-to-Code (M2C) transformation to (semi-)automatically derive service code [18]. In such a model-centric development scenario, modeling does not completely replace programming. Instead, the usage of models aims to ease accidental complexity by helping to avoid redundant programming, but does not replace the manual realization of essential complexity, e.g., programming service-specific, business-related behavior [20].

Although there are first approaches, e.g., [7] or [21], which address such an MDD for MSA (MSA-MDD), they currently only enable the generation of a microservice landscape from a centralized architectural perspective. Hence, we argue that a holistic approach to MSA-MDD needs to take MSAs organizational characteristics into account. That is, like the code-centric development process, a model-centric development process of MSA would need to consider Conway’s Law in the context of MSA [15] and support a collaborative development spread across multiple teams [22].

In this paper, we present our vision of a collaborative modeling approach for MSA. For this purpose, we rely on methods and techniques from the research area of Collaborative Model-driven Software Engineering (CMDSE) [6]. It defines approaches where multiple stakeholders use a set of shared models to collaborate.

The remainder of this paper is organized as follows. In Section 2 we elaborate on the collaborative aspects of microservice development and deduce challenges for a corresponding holistic MSA-MDD approach. Building on this, in Section 3 we describe our vision of a collaborative MSA-MDD approach by applying concepts from the area of CMDSE. Finally, Section 4 concludes the paper and Section 5 describes future work.

2 Challenges for Collaborative Model-driven Microservice Development

In this section we identify and discuss major challenges for collaborative modeling in the context of MSA to enable holistic MSA-MDD. CMDSE is itself part of the broader research area of Collaborative Software Engineering (CoSE) [13], which investigates means for enhancing collaboration, communication and coordination (3C) among software engineers and project stakeholders. In the context of CoSE, the organizational structure of microservices can be separated into two hierarchical scopes of collaboration. In the team-internal scope, team members collaborate to manage one or more services. In the team-external scope, teams themselves collaborate with each other, e.g., by using an interface of another team’s service for their service’s realization. Furthermore, the act of assembling the overall system through autonomous services in its own right represents a form of team-external collaboration.

A holistic MSA-MDD may then be enabled by applying CMDSE to both team scopes. Based on 3C, full-fledged CMDSE approaches comprise the three main complementary dimensions model management, collaboration means, and communication means [10]. Each of the following subsections identifies and discusses challenges for collaborative MSA-MDD by analyzing the team-internal scope (cf. Subsection 2.1) and the team-external scope (cf. Subsection 2.2) with respect to these three dimensions of CMDSE.

2.1 Team-internal Model-driven Microservice Development

A team, which is responsible for one or more microservices, follows a share-nothing philosophy to foster agility and autonomy [9]. Therefore, each team is independent from other teams and services in their choices related to services’ implementation regarding, e.g., programming languages, databases or employed tools. For example, this autonomy enables a single team to adopt an MDD approach for their services even if other teams do not use MDD [18].

However, in practice the team’s technology stack and development process model is often influenced by an organization’s culture [14], e.g., if the usage of GitLab222 for managing the software lifecycle has proven successful in existing teams, a new team is highly likely to adopt GitLab, too. In certain cases, choices can be predetermined by the overall organization in order to maintain compatibility, e.g., with an existing deployment pipeline [1].

At this level, the possible application of MSA-MDD only differentiates itself from a traditional model-driven development process through the different roles within the team [2]. To utilize collaboration across team members, existing solutions, e.g., emfCollab333 or the Eclipse Dawn Project444 can be applied. Such solutions already realize means for the CMDSE dimensions model management and collaboration [10]. Depending on the tool, separate communication means like an instant messenger could be added to the collaboration tool stack. However, while these tools provide good means for collaboration, they still need an underlying modeling language for the microservice domain [17]. This motivates the first challenge for a collaborative MSA-MDD approach:

(C1) Support for Role-specific Team Tasks

For a model-centric development, this modeling language needs to support the different tasks and roles inside a DevOps-based MSA development team, i.e., the complete management process of a microservice.

2.2 Team-external Model-driven Microservice Development

While the team-internal collaborative modeling scope can be covered leveraging existing CMDSE approaches (cf. Subsection 2.1), especially for the application of collaborative MSA-MDD with regards to the team-external scope MSA-specific challenges arise which we discuss in the following.

With the distribution and loose coupling of functionality and service teams, MSA might not exhibit a central architecture viewpoint or entity, e.g., a team of dedicated software architects, for the overall microservice landscape. However, we expect that such a viewpoint or entity can be of great benefit in the context of MSA. First, it may be aware of the overall team structure and foster communication [17]. Second, it may document and comprehend the overall static structure and service interactions of a microservice architecture. Models are predestined to represent such structures and interaction relations [4]. Therefore, the second challenge for a collaborative MSA-MDD approach arise:

(C2) System Model Assembly Across Autonomous Microservices

How can such a holistic and model-based overview of an MSA be assembled from the involved services and interactions in a loosely coupled way, i.e., without contradicting MSA’s paradigm of autonomous services.

Another aspect regarding the team-external scope results from Conway’s Law. Due to the loose coupling of microservices, the responsible teams also collaborate more loosely preserving their autonomy [14]. Although there are mechanics to provide knowledge exchange across teams, e.g., Spotify joins persons with a similar skill set from different teams to horizontal organization structures called guilds [12], knowledge exchanges generally happen on a non-technical and informal level [23]. However, next to provided interfaces of other teams’ services, teams may also access the source code of microservices, e.g., through company-wide available code repositories or verbal requests [14]. This agile opportunities also need consideration in a collaborative MSA-MDD approach:

(C3) Collaboration Means for Teams

Like source-code, the models of a team need to be accessible and usable for other teams, e.g., to copy domain concepts [17] or retrieve interface descriptions, without contradicting the loose coupling characteristic of services and teams.

3 A Collaborative Modeling Approach for Model-driven Microservice Development

Starting from the identified challenges and their discussion in Section 2, we derived a conceptual model for the prospective application of CMDSE to MSA. It is depicted in Figure 1 as a UML class diagram enriched by indirect use relations.

Figure 1: Conceptual Model of Collaborative MSA-MDD

The overall microservice System is composed of many Microservices. For each of these services, a single Team which consists of multiple Team Members is considered responsible. For a model-centric development, our approach comprises a dedicated Microservice Model. Next to its services, each team is thus also responsible the defining models [17]. For the model-centric development inside a team, we suggest the usage of a separate model repository for each microservice model as means of management and a web- or eclipse-based workbench which works with a local model version repository.

With regard to the role-specific development tasks (cf. C1 in Subsection 2.1), we propose the usage of such a model repository in combination with a set of integrable domain-specific modeling languages (DSMLs), which each addresses a specialized viewpoint for microservice development [19]. The common metamodel of the DSMLs defines three viewpoints. First, the Data Viewpoint holds concepts to specify a microservice’s information model. Second, the Service Viewpoint provides means to model interfaces and dependencies to other teams’ services. Third, the Operation Viewpoint enables team members to model the information for deployment and operation of a service.

To compose an overall System Model (C2), our conceptual model involves a central Model Registry and an additional step in the continuous delivery pipeline, when a team releases a microservice. In this step, a copy of the corresponding service model is sent to the central model registry every time a microservice gets released. Thus, the registry is able to assemble the system model by weaving the microservice models according to their interface dependencies with other services. To ensure a successful composition of the system model, each microservice model is tested at each release for its integrability. A model which integration test fails, e.g., because an external service refers to a data object that is no longer published through the service’s interface, is therefore marked as a conflict and has to be revised by the respective team.

As a result, our presented approach is able to provide teams with the ability to consult other teams’ models through the assembled system model (C3). For realization, we envision the extension of the team-internal modeling workbench with the ability to access the system model and import other microservice models as dependencies inside the teams own model. While dependency information gets pushed to the model repository in the next release, the system model can also be consulted regarding change impact and conflict analysis [3], and perform appropriate measures, e.g., automatically protection of deprecated microservice releases because of other services’ dependencies.

4 Conclusion

The usage of MDD for designing MSA is a promising way to cope with MSA’s inherent accidental complexity. While there already exist approaches for MSA-MDD which support the development from a central architectural point of view, MSA’s organizational characteristic of aligning services to teams is currently underrepresented.

Hence, we identified three major challenges for the realization of a holistic MSA-MDD across microservice teams by examining team-internal and team-external collaboration processes in microservice development (cf. Section 2).

As a result, we presented our vision of a collaborative MSA-MDD approach which foresees individual microservice models as model fragments of the overall system (cf. Section 3). Leveraging a model registry, such models get automatically woven to a system model which in the following can be used to provide team collaboration means, e.g., partial imports or dependencies of other microservice models across teams.

5 Future Work

For future work we are going to evaluate existing CDMSE approaches like Mondo555 or Eclipse Dawn666 for their applicability towards team-internal collaboration and extendability concerning our envisioned approach. In the following we plan to adapt our central modeling approach described in [19] to support a distributed modeling and implement a prototype for the model registry mechanism.

Beyond the realization of a model-centric development process at design time, we would like to further investigate the possibilities of runtime models [8] in the MSA software life cycle. Another interesting research direction we would like to further investigate comprises the usage of microservices as containers for language components in the context of globalizing modeling languages [5].


  • [1] Balalaie, A., Heydarnoori, A., Jamshidi, P.: Microservices architecture enables devops: Migration to a cloud-native architecture. IEEE Software 33(3), 42–52 (May 2016)
  • [2] Brambilla, M., Cabot, J., Wimmer, M.: Model-driven software engineering in practice. Synthesis Lectures on Software Engineering 1(1), 1–182 (sep 2012)
  • [3] Briand, L.C., Labiche, Y., O’Sullivan, L.: Impact analysis and change management of uml models. In: Int. Conf. on Software Maintenance, 2003. ICSM 2003. Proceedings. pp. 256–265 (Sept 2003)
  • [4] Combemale, B., France, R., Jézéquel, J., Rumpe, B., Steel, J., Vojtisek, D.: Engineering modeling languages. Chapman Hall/CRC innovations in software engineering and software development, Taylor Francis, CRC Press (2016)
  • [5] Combemale, B., Deantoni, J., Baudry, B., France, R.B., Jézéquel, J.M., Gray, J.: Globalizing Modeling Languages. Computer pp. 10–13 (Jun 2014)
  • [6] Di Ruscio, D., Franzago, M., Muccini, H., Malavolta, I.: Envisioning the future of collaborative model-driven software engineering. In: Proc. of the 39th Int. Conf. on Software Engineering Companion (2017)
  • [7] Düllmann, T.F., van Hoorn, A.: Model-driven generation of microservice architectures for benchmarking performance and resilience engineering approaches. In: Proc. of the 8th ACM/SPEC on Int. Conf. on Performance Engineering Companion. pp. 171–172. ICPE ’17 Companion (2017)
  • [8] France, R., Rumpe, B.: Model-driven development of complex software: A research roadmap. In: 2007 Future of Software Engineering (2007)
  • [9] Francesco, P., Lago, P., Malavolta, I.: Research on Architecting Microservices: Trends, Focus, and Potential for Industrial Adoption. In: 2017 IEEE Int. Conf. on Software Architecture (2017)
  • [10] Franzago, M., Ruscio, D.D., Malavolta, I., Muccini, H.: Collaborative model-driven software engineering: a classification framework and a research map. IEEE Transactions on Software Engineering (2017)
  • [11] Kang, H., Le, M., Tao, S.: Container and microservice driven design for cloud infrastructure devops. In: 2016 IEEE International Conference on Cloud Engineering (IC2E). pp. 202–211 (April 2016)
  • [12] Kniberg, H., Ivarsson, A.: Scaling Agile @ Spotify. Spotify, Inc. (2012)
  • [13] Mistrík, I., Grundy, J., van der Hoek, A., Whitehead, J.: Collaborative Software Engineering: Challenges and Prospects, pp. 389–403. Springer Berlin Heidelberg, Berlin, Heidelberg (2010)
  • [14] Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M.: Microservice Architecture: Aligning Principles, Practices, and Culture. O’Reilly Media, Inc., 1st edn. (2016)
  • [15] Newman, S.: Building Microservices. O’Reilly Media, Inc., 1st edn. (2015)
  • [16] Rademacher, F., Sachweh, S., Zündorf, A.: Differences between model-driven development of service-oriented and microservice architecture. In: 2017 IEEE Int. Conf. on Software Architecture Workshops (ICSAW). pp. 38–45 (2017)
  • [17] Rademacher, F., Sorgalla, J., Sachweh, S.: Challenges of domain-driven microservice design: A model-driven perspective. IEEE Software (May–June 2018), in press
  • [18] Rademacher, F., Sorgalla, J., Sachweh, S., Zündorf, A.: Microservice architecture and model-driven development: Yet singles, soon married (?). In: Proceedings of the Second International Workshop on Microservices: Agile and DevOps Experience (MADE) (2018), in press
  • [19] Rademacher, F., Sorgalla, J., Sachweh, S., Zündorf, A.: Towards a viewpoint-specific metamodel for model-driven development of microservice architecture. arXiv:1804.09948 (2018),, preprint
  • [20] Schmidt, D.: Guest editor’s introduction: Model-driven engineering. Computer 39(2), 25–31 (feb 2006)
  • [21] Sorgalla, J.: Ajil: A graphical modeling language for the development of microservice architectures. In: Extended Abstracts of the Microservices 2017 Conf. (2017),
  • [22] Sorgalla, J., Rademacher, F., Sachweh, S., Zündorf, A.: Collaborative model-driven software engineering and microservice architecture: A perfect match? In: XP’18 Workshops (2018), accepted
  • [23] Wiedemann, A.: A new form of collaboration in it teams - exploring the devops phenomenon. In: PACIS 2017 Proceedings (2017)
  • [24] Wizenty, P., Sorgalla, J., Rademacher, F., Sachweh, S.: Magma: Build management-based generation of microservice infrastructures. In: Proc. of ECSA 2017 (2017)