This repository contains the deployment of a microservice application with a focus on the reliability aspects for cloud-native applications defined by Lichtenthäler and Wirtz (Paper, Model, Tool with modeling approach). Based on these investigated deployment options, the software architecture modeling approach accompanying the quality model has been extended and refined. The architectural models can be opened in the corresponding tool: https://clounaq.de.
The product factors of the quality aspect Reliability from the cloud-native quality model by Lichtenthäler and Wirtz were implemented using the microservice reference application Teastore.
The baseline architecture of the cloud-native application deployment was implemented using AWS EKS.
In addition, the implementation options for each product factor were added in a modular manner to complement the baseline architecture.
The repository is structured as follows: Each directory of a product factor contains the options and solutions that contribute to the implementation of the reliability aspect. Corresponding implementation instructions are provided, as well as corresponding changes to the workload definition of the TeaStore.
Furthermore, models representing the different architectural options are added as examples.
The following table shows a summary of implemented concepts:
| Product Factor | Implementation Options | ||||
|---|---|---|---|---|---|
| Built-In Autoscaling | AWS Auto Scaling Groups & Policies | Cluster Autoscaler | Karpenter | Horizontal Pod Autoscaler | Vertical Pod Autoscaler |
| Physical Data / Service Distribution | StatefulSets and Persistent Volumes | AWS Relational Database Service | Node / Pod (Anti-) Affinity Rules | Pod Topology Spread Constraints | |
| Guarded Ingress | AWS Web Application Firewall | Ingress Controller | (ModSecurity) | ||
| Health and Readiness Checks | Liveness and Readiness Probes | AWS Load Balancer Health Checks | |||
| Seamless Upgrades | K8s Rolling Update Strategy | Blue-Green Update Strategy |
Horizontal up- and down-scaling of components is automated and built into the infrastructure on which components run. Horizontal scaling means that component instances are replicated when the load increases and components instances are removed when load decreases. This autoscaling is based on rules which can be configured according to system needs.
Storage Backing Service instances where Data aggregates are persisted are distributed across physical locations (e.g. availability zones of a cloud vendor) so that even in the case of a failure of one physical location, another physical location is still useable.
Components are distributed through replication across physical locations (e.g. availability zones of a cloud vendor) so that even in the case of a failure of one physical location, another physical location is still useable.
Ingress communication, that means communication coming from outside of a system, needs to be guarded. It should be ensured that access to external endpoints is controlled by components offering these external endpoints. Control means for example that only authorized access is possible, maliciously large load is blocked, or secure communication protocols are ensured.
All components in a system offer health and readiness checks so that unhealthy components can be identified and communication can be restricted to happen only between healthy and ready components. Health and readiness checks can for example be dedicated endpoints of components which can be called regularly to check a component. That way, also an up-to-date holistic overview of the health of a system is enabled.
Upgrades of services do not interfere with availability. There are different strategies, like rolling upgrades, to achieve this which should be provided as a capability by the infrastructure.
Based on the investigation of the mentioned different deployment options, the modeling approach corresponding to the proposed quality model for cloud-native software architectures has been extended in order to cover the different characteristics of the deployment options. More specifically, the following extensions have been introduced and can be found in the corresponding exemplary models:
These extensions mainly cover basic deployment options, without a specific focus on reliability. Exemplary implementations and models for the TeaStore application can be found in DeploymentOptions.
These extensions are more specific to the implemented options and exemplary models can be found within each folder containing an implementation.
Note: Endpoints are defined as Nodes although there are already capability type definitions for endpoints within the TOSCA Standard. The reason why an additional Node type for endpoints is used is the following: Based on the current TOSCA 2.0 standard, Capabilities can only be defined (see 5.3.5.2 Capability Definition) within Node Type definitions (see 5.3.1 Node Type) while in Node Templates (see 5.3.2 Node Template) it is only possible to use Capability Assignments (see 5.3.5.3 Capability Assignment) referring to capability types previously defined in the Node Type Definition. Endpoints modeled with the inherent Endpoint Capability in Node Templates therefore do not have a unique key, but all have the symbolic name of a Capability definition as defined in the Node Type definition. Specifying a relationship from one Service to a specific Endpoint of another Service is therefore not possible, because Endpoints cannot be uniquely identified. A definition of Endpoints as new Capabilities would only be possible through additional Node Type definitions which would increase the complexity since a new Node Type would need to be added for each modeled component. Since a specification of communication links between components and endpoints of components is necessary for the quality model in question, a workaround has been chosen which is based on modeling Endpoints as Node templates (with a corresponding node type for endpoints)