A Formal Approach to Microservice Architecture Deployment

Abstract

Following previous work on the automated deployment of componentbased applications, we present a formal model specifically tailored for reasoning on the deployment of microservice architectures. The first result that we present is a formal proof of decidability of the problem of synthesizing optimal deployment plans for microservice architectures, a problem which was proved to be undecidable for generic component-based applications. Then, given that such proof translates the deployment problem into a constraint satisfaction problem, we present the implementation of a tool that, by exploiting state-of-the-art constraint solvers, can be used to actually synthesize optimal deployment plans. We evaluate the applicability of our tool on a realistic microservice architecture taken from the literature.

Microservice Dynamic Architecture-Level Deployment Orchestration

“…4 Wrapping up the novel contributions of this paper (e.g. compared to our previous work in [13,14]) are: (i) a novel integrated timed architectural modeling/execution language based on a timed extension of SmartDeployer that, differently from the previous version, exploits timed instructions of ABS to automatically generate timed deployment orchestrations, (ii) an architecture-level run-time adaptation algorithm that reaches any target system MCL, (iii) mathematical calculation of service MCL and MCL-based scaling configurations and (iv) ABS code implementing system service execution/scaling mechanism for the Email Pipeline Processing System [23].…”

“…In this section we present the microservice model, as formalized in [13,14], the ABS language [4] and the SmartDeployer tool [13,14].…”

“…The work in [13,14] formalizes component-based software systems (where components are deployed on VMs) and the automated deployment problem: synthesis of deployment orchestrations that reach a given target system configuration. In particular, the deployment life-cycle of each component type is formalized by means of a finite-state automaton, whose states denote a deployment stage.…”

“…Each state is associated with a set of provided ports (operations exposed by the component that can be used by other components) and a set of required ports (operations of other components needed for the component to work in that deployment stage). More specifically, [13,14] consider the case of microservices: components whose deployment life cycle consists of just two phases: (i) creation, which entails mandatorily establishing initial connections, via so-called strongly required ports, with already available microservices, and (ii) subsequent optional binding/unbinding, via so-called weakly required ports, with other microservices. The two phases make it possible to manage circular dependencies among microservices.…”

“…with the Erlang backend). In particular, we realize a timed extension of SmartDeployer [13,14], whose ABS code annotations make it possible to express: architectural properties of the modeled distributed system (global architectural invariants and allowed reconfigurations), of its VMs (their characteristics and the resource they provide) and of its software components/services (their resource/functional requirements). Such annotations are read by SmartDeployer that, at compile-time, checks them for satisfiability (accounting for requirements and architectural invariants) and synthesizes deployment orchestrations that build the system architecture and each of its specified reconfigurations.…”