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!