Rogério de Lemos MSA 2019 – February 2019 – 1

Microservices Architectures and Technical Debt:

A Self-adaptation View

Ananya Chhonker and Rogério de Lemos

University of Kent, UK

Rogério de Lemos MSA 2019 – February 2019 – 2

Outline

u Motivation

u MSA and technical debt

u MSA and self-adaptation

u MSA and self-protection (security)

u Conclusions

Rogério de Lemos MSA 2019 – February 2019 – 3

Motivation

u MSA and self-adaptation

u Self-healing, autonomic controller for deployment, regression testing, resilience, controller failure

u Distributed nature of MSA

u Insight taken: emergent and fuzzy

u centralised vs decentralised

u MSA and technical debt

u There are no primary or secondary studies analysing the principles of MSA in light of TD

u No guidelines for evaluating the debt capacity

Rogério de Lemos MSA 2019 – February 2019 – 4

Motivation: State-of-the-art

u Not much significant has been published on MSA and self-adaptation

u Relative new field, not yet stable in terms of what is the key foci of change

u Some misguided proposals

u (Surprisingly!!) Both are about change

u Possible explanation: in software engineering, in particular, software architectures the basis has bee MAPE-K loop

u Essentially, a centralized entity

u Architecture vs deployment

u Tools for handling change at deployment

u Eg, Kubernetes

Rogério de Lemos MSA 2019 – February 2019 – 5

u 3 physical servers

u 10 VMs

u 22 micro-services

u 3 OSS packages

u 120+ Open API REST services

u ~300,000 lines of code (Java)

All deployed by a Continuous Delivery engine

Rogério de Lemos MSA 2019 – February 2019 – 6

MSA and Technical Debt

u Technical debt

u design decisions that consciously or unconsciously compromise system-wide quality attributes

u Assumptions or methods can negatively affect an MSA-based software system during its lifetime

u Awareness of TD and its implications

u Developers can be more cautious while making decisions

u To reduce TD

u Quality of attributes of an MSA-based system should be analysed at architecture level

u Testing, security and reliability

Rogério de Lemos MSA 2019 – February 2019 – 7

MSA and Technical Debt

u Testing

u Large systems with many connections between services makes integration testing more challenging

u Security

u Attack area increases since there are more points of entry, lack of global view since containers deployed in the cloud, individual microservices may not be trustworthy, system complexity, etc

u Reliability

u Complex deployments with many services and connections tend to reduce the reliability of services, nothing to handle failures in connections

Rogério de Lemos MSA 2019 – February 2019 – 8

MSA and Self-adaptation

u Self-adaptation

u A system is able to modify its behaviour and/or structure in response to changes

u Feedback control loop, and software engineering techniques

Monitor Execute

Analyse(Problem Domain)

Analyse(Solution Domain)

Plan(Decision Maker)

Plan(Plan

Synthesis)

Knowedge(Models)

System

Target System

Environment

Controller

u Testing

u Generate automatically new integration test plans when changes in the architecture

u Security

u Identify malicious components and protect the MSA-based system

u Reliability

u Known as self-healing

Rogério de Lemos MSA 2019 – February 2019 – 9

Type of Control

u From centralised to decentralisedu Single component or distributed amongst several components

u Self-adaptationu Feedback control loop, relies on system models from different

perspectives

u Self-organizationu Multi-agents, ant colony optimisation, swarms

u There is no single unique solution for self-adaptive MSAu Orchestration vs choreography

u Several factors involved in controlling functional and non-functional attributes

u Specialisation vs generalization of controllers

Rogério de Lemos MSA 2019 – February 2019 – 10

Patterns for Decentralized Control in Self-Adaptive Systems [Weyns 2013]

Rogério de Lemos MSA 2019 – February 2019 – 11

MSA and Self-protection

u Security services should rely on orchestration

u Information sharing, each node cannot maintain a model of system, compromised nodes lack self-awareness, etc

u Detection and protection against malicious containers

u Containers may have the right to access other services, but they abuse

u Their malicious behaviour should be detected

u Containers should be isolated from the system

u Impact on reliability or availability is another analysis

Rogério de Lemos MSA 2019 – February 2019 – 12

ContainerContainerContainer

7a. Adapt access criteria

Self-protection againstMalicious Microservices

AuthorisationServicesIdentity Services

5. Send accessdecision

3. Request access decision1. Authenticate

& get credentials

2. Request services using credentials

4. Validate credentials Criteria for accessContainer access

rights

Criteria for credential release

Autonomic Controller

6b. Monitor Resource

usage

7b. Adapt containers access

6a. Monitor Access

6a. Containers rights

Rogério de Lemos MSA 2019 – February 2019 – 13

Conclusions

u Design decisions lead to trade offsu MSA has benefits, but also has some drawbacks

u Lack of discussion regarding technical debt

u What about lessons learned from similar SE initiatives?

u Self-adaptation offers an opportunity for handling changeu A single MAPE-K loop is not the solution

u Resilience of MSA-based microservices comes with a cost related to complexity

u The notion of ‘autonomy’ is misplacedu Functional and non-functional

u How to protect MSA-based solutions against malicious microservices

Rogério de Lemos MSA 2019 – February 2019 – 14

Dortmund. February 2019.

Thank you!