Merge branch 'main' into issue/03_user_role_management

isaqb-org · Apr 4, 2024 · ac0ef1a · ac0ef1a
2 parents 9f64926 + d1c2ff2
commit ac0ef1a
Show file tree

Hide file tree

Showing 7 changed files with 70 additions and 31 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -8,12 +8,15 @@
 - DevOps, DevSecOps, and SRE
 - Abstraction Layers of Container Managers
 - Permissions Management
+- Secrets Management
 
-## Added/Changed wording
+## Naming concepts more explicitly
 
 - Chaos engineering
 - Eventual consistency
 - Platform quality requirements
+- Serverless
+- Functions as a Service (FaaS)
 
 ## Removed
 - Mentioning of tool names for automation and operation (Ansible, Chef, Terraform, Rancher, Tectonic, Kops, Kubeadm, OpenShift)

diff --git a/docs/01-Fundamentals-of-Modern-Infrastructures/01-duration-terms.adoc b/docs/01-Fundamentals-of-Modern-Infrastructures/01-duration-terms.adoc
@@ -4,7 +4,7 @@
 |===
 
 === Begriffe und Konzepte
-Cloud, Cloud-Arten, Cloud-Anbieter, On Premise, Bare Metal, Cloud Service Modelle (*aaS), Vendor Lock-in, Managed Services, Cloud Native Services, Cloud-Muster, Cloud-Migrationsmuster, Multi/Hybrid Cloud, Organisatorische Aspekte der Cloud Migration, Rechtliche Rahmenbedingungen, Time-to-Market, Verfügbarkeit, Skalierung, Geo Redundanz und Skalierung, Performance, IOPS, Decoupling Operations, Networking.
+Cloud, Cloud-Arten, Cloud-Anbieter, On Premise, Bare Metal, Cloud Service Modelle (*aaS), Vendor Lock-in, Managed Services, Serverless Computing, Cloud Native Services, Cloud-Muster, Cloud-Migrationsmuster, Multi/Hybrid Cloud, Organisatorische Aspekte der Cloud Migration, Rechtliche Rahmenbedingungen, Time-to-Market, Verfügbarkeit, Skalierung, Geo Redundanz und Skalierung, Performance, IOPS, Decoupling Operations, Networking.
 
 // end::DE[]
 
@@ -14,7 +14,7 @@ Cloud, Cloud-Arten, Cloud-Anbieter, On Premise, Bare Metal, Cloud Service Modell
 |===
 
 === Terms and Principles
-Cloud, cloud types, cloud provider, on premise, bare metal, cloud service models (*aaS), vendor lock-in, managed services, cloud native services, cloud patterns, cloud migration patterns, multi/hybrid cloud, organizational aspects of cloud migration, legal conditions, time-to-market, availability, geo redundancy and scalability, performance, IOPS, decoupling operations, networking.
+Cloud, cloud types, cloud provider, on premise, bare metal, cloud service models (*aaS), vendor lock-in, managed services, serverless computing, cloud native services, cloud patterns, cloud migration patterns, multi/hybrid cloud, organizational aspects of cloud migration, legal conditions, time-to-market, availability, geo redundancy and scalability, performance, IOPS, decoupling operations, networking.
 // end::EN[]
 
 

diff --git a/docs/01-Fundamentals-of-Modern-Infrastructures/02-learning-goals.adoc b/docs/01-Fundamentals-of-Modern-Infrastructures/02-learning-goals.adoc
@@ -15,7 +15,9 @@ Sie verstehen den Unterschied zwischen Cloud- und On-Premise-Betrieb sowie die A
 
 Softwarearchitekt:innen kennen unterschiedliche Cloud Service Modelle (*aaS) und können Services anhand dieser Modelle klassifizieren.
 
-Sie verstehen das Shared-Responsibility-Modell und dessen Relevanz für Kosten- und Risikobewertungen bei der Nutzung von managed Cloud Services.
+Sie verstehen darüber hinaus das Serverless Computing Konzept und können es den Cloud Service Modellen zuordnen.
+
+Softwarearchitekt:innen verstehen das Shared-Responsibility-Modell und dessen Relevanz für Kosten- und Risikobewertungen bei der Nutzung von managed Cloud Services.
 
 Sie kennen das Konzept des Vendor Lock-in und seine Relevanz für die Entscheidungsfindung zwischen managed und self-managed Services.
 
@@ -56,7 +58,9 @@ They understand the difference between cloud and on-premise operations, as well
 
 Software architects know different cloud service models (*aaS) and can classify services based on these models.
 
-They understand the shared responsibility model and its relevance for cost and risk assessments when using managed cloud services. 
+They also understand the serverless computing concept and can assign it to the cloud service models.
+
+Software architects understand the shared responsibility model and its relevance for cost and risk assessments when using managed cloud services.
 
 They know the concept of vendor lock-in and its relevance for decision-making between managed and self-managed services.
 

diff --git a/docs/04-Patterns/01-duration-terms.adoc b/docs/04-Patterns/01-duration-terms.adoc
@@ -4,7 +4,7 @@
 |===
 
 === Begriffe und Konzepte
-Resilienz Muster, Container Application Design, Cloud Native Architekturen, Container Pattern, Service Mesh
+Resilienz Muster, Container Application Design, Cloud Native Architekturen, Container Pattern, Functions as a Service (FaaS), Service Mesh
 
 // end::DE[]
 
@@ -14,7 +14,7 @@ Resilienz Muster, Container Application Design, Cloud Native Architekturen, Cont
 |===
 
 === Terms and Principles
-Resilience Patterns, Container Application Design, Cloud Native Architectures, Container Patterns, Service Mesh
+Resilience Patterns, Container Application Design, Cloud Native Architectures, Container Patterns, Functions as a Service (FaaS), Service Mesh
 
 // end::EN[]
 

diff --git a/docs/04-Patterns/02-learning-goals.adoc b/docs/04-Patterns/02-learning-goals.adoc
@@ -19,7 +19,20 @@ Softwarearchitekt:innen kennen Methoden, um technische von fachlichen Aufgaben d
 * Container Management durch Operator bzw. Controller
 
 [[LZ-4-2]]
-==== LZ 4-2: Passende Resilienzmuster zur Erhöhung von Fehlertoleranz auswählen
+==== LZ 4-2: Passende Technologien für den Betrieb von Modulen auswählen
+
+Softwarearchitekt:innen können geeignete Technologien zum Betrieb von Modulen eines verteilten Systems auswählen, z.B. mit Functions as a Service (FaaS) und Container Orchestrierung.
+
+Darüber hinaus können Sie die Anwendung dieser Technologien Anforderungsgetrieben anwenden. Dabei gibt es verschiedene Aspekte zu beachten wie:
+
+* Skalierungsanforderungen
+* Start- und Ausführungszeit
+* Komplexität des Betriebs und fachlichen Schnitts
+* Zugriff auf Persistenz
+* Limitierungen für Observability und Debugging
+
+[[LZ-4-3]]
+==== LZ 4-3: Passende Resilienzmuster zur Erhöhung von Fehlertoleranz auswählen
 
 Softwarearchitekt:innen verstehen, wie bei einer verteilten Anwendung die Kommunikation zwischen den Services fehlertolerant realisiert werden kann.
 
@@ -54,7 +67,20 @@ Software architects are familiar with methods for separating technical and busin
 * Container management through operators or controllers
 
 [[LG-4-2]]
-==== LG 4-2: Ability to Select Appropriate Resilience Patterns to Increase Fault Tolerance
+==== LG 4-2: Ability to Select Suitable Technologies for Operating Modules
+
+Software architects can select suitable technologies for operating modules of a distributed system, e.g. with Functions as a Service (FaaS) and container orchestration.
+
+They select these technologies in a requirements-driven manner. Various aspects must be taken into account, such as
+
+* Scaling requirements
+* Start and runtime duration
+* Complexity of operation and domain boundaries
+* Access to persistence
+* Limitations on observability and debugging
+
+[[LG-4-3]]
+==== LG 4-3: Ability to Select Appropriate Resilience Patterns to Increase Fault Tolerance
 
 Software architects understand how communication between services in a distributed application can be made fault-tolerant.
 

diff --git a/docs/05-Development-and-CICD/01-duration-terms.adoc b/docs/05-Development-and-CICD/01-duration-terms.adoc
@@ -4,7 +4,7 @@
 |===
 
 === Begriffe und Konzepte
-Development Environment, CI/CD Environment, Mean Time To Recovery (MTTR), Application Lifecycle Management, Formen von Deployments wie Rolling-, Canary- und Blue/Green Deployment, Cluster Design, Logging, Monitoring, Metriken, Distributed Tracing, Time Series Queries, Alerting
+Development Environment, CI/CD Environment, Mean Time To Recovery (MTTR), Application Lifecycle Management, Formen von Deployments wie Rolling-, Canary- und Blue/Green Deployment, Cluster Design, Secrets Management
 // end::DE[]
 
 // tag::EN[]
@@ -13,7 +13,7 @@ Development Environment, CI/CD Environment, Mean Time To Recovery (MTTR), Applic
 |===
 
 === Terms and Principles
-Development environment, CI/CD environment, Mean Time To Recovery (MTTR), application lifecycle management, forms of deployments like Rolling-, Canary- and Blue/Green deployment, cluster design, logging, monitoring, metrics, distributed tracing, time series queries, alerting
+Development environment, CI/CD environment, Mean Time To Recovery (MTTR), application lifecycle management, forms of deployments like Rolling-, Canary- and Blue/Green deployment, cluster design, secrets management
 // end::EN[]
 
 

diff --git a/docs/05-Development-and-CICD/02-learning-goals.adoc b/docs/05-Development-and-CICD/02-learning-goals.adoc
@@ -7,12 +7,15 @@
 
 Softwarearchitekt:innen wissen, dass es bei der Arbeit in Cloud-Umgebungen neue Anforderungen an den Softwareentwicklungsprozess gibt.
 
-Sie kennen verschiedene Vorgehensweisen, um Projekte in Cloud-Umgebungen durchzuführen. Zum Beispiel:
+Sie kennen verschiedene Vorgehensweisen und Technologien, um Projekte in Cloud-Umgebungen durchzuführen. Zum Beispiel:
 
 * Organisatorische Good Practices
 * Development- und CI/CD-Umgebungen
 
-Sie kennen Möglichkeiten, um in einer Cloud-Umgebung Deployments und ein Application Lifecycle Management zu realisieren, insbesondere:
+[[LZ-5-2]]
+==== LZ 5-2: Application Lifecycle Management in Cloud-Umgebungen umsetzen
+
+Softwarearchitekt:innen kennen Möglichkeiten, um in einer Cloud-Umgebung Deployments und ein Application Lifecycle Management zu realisieren, insbesondere:
 
 * Versionierung von Containern und Deployment-Spezifikationen etc.
 * Etablierte Formen der Bereitstellung von Anwendungen, wie z. B.:
@@ -25,18 +28,17 @@ Sie kennen Komponenten und Vorgehensmodelle, um einen schnellen Test- und Deploy
 * Verantwortlichkeiten und Zugriffskontrolle
 * Good Practices zur Komponentengruppierung
 
-[[LZ-5-2]]
-==== LZ 5-2: Wege der Beobachtbarkeit von verteilten Applikationen kennen
+[[LZ-5-3]]
+==== LZ 5-3: Secrets Management Optionen kennen
 
-Softwarearchitekt:innen wissen, dass es durch die verteilte Ausführung von Prozessen neue Herausforderungen an die Beobachtbarkeit verteilter Applikationen gibt.
+Softwarearchitekt:innen verstehen die kritische Rolle und Techniken zur Verwaltung von Geheimnissen (Secrets) in der Cloud, darunter:
 
-Sie kennen die besonderen Rahmenbedingungen verteilter Anwendung und den Einfluss auf die Beobachtbarkeit mittels:
+* Integration von Cloud-Diensten zur Secrets-Verwaltung
+* Secrets Operator Konzept
+* Automatisierte Secret Rotation
 
-* Logging
-* Monitoring/Metriken und Alerting
-* Distributed Tracing
+Darüber hinaus können sie die Vor- und Nachteile zum eigenen Betrieb eines Secrets Managers benennen.
 
-Sie kennen Wege und Verantwortlichkeiten zur Erstellung möglichst fehlervorhersagenden Time Series Queries für Alerts.
 // end::DE[]
 
 // tag::EN[]
@@ -45,12 +47,16 @@ Sie kennen Wege und Verantwortlichkeiten zur Erstellung möglichst fehlervorhers
 
 Software architects are aware that working in cloud environments brings new requirements to the software development process.
 
-They are familiar with different approaches to implementing projects in cloud environments, such as:
+They are familiar with different approaches and technologies to implementing projects in cloud environments, such as:
 
 * Organizational good practices
 * Development and CI/CD environments
 
-They understand the possibilities of implementing deployments and application lifecycle management in a cloud environment, particularly:
+
+[[LG-5-2]]
+==== LG 5-2: Implementing Application Lifecycle Management in Cloud Environments
+
+Software architects understand the possibilities of implementing deployments and application lifecycle management in a cloud environment, particularly:
 
 * Versioning of containers and deployment specifications, etc.
 * Established forms of application deployment, such as:
@@ -63,16 +69,16 @@ They are familiar with components and models for achieving a fast testing and de
 * Responsibilities and access control
 * Good practices for component grouping
 
-[[LG-5-2]]
-==== LG 5-2: Understanding approaches for observability of distributed applications
 
-Software architects know that the distributed execution of processes presents new challenges for observability of distributed applications.
+[[LG-5-3]]
+==== LG 5-3: Know Secrets Management Options
+
+Software architects understand the critical role and techniques for managing secrets in the cloud, including:
 
-They understand the unique conditions of distributed applications and their impact on observability through:
+* Integration of cloud services for secrets management
+* Secrets operator concept
+* Automated secret rotation
 
-* Logging
-* Monitoring/metrics and alerting
-* Distributed tracing
+In addition, they can name the advantages and disadvantages of operating a Secrets Manager themselves.
 
-They are familiar with approaches and responsibilities for creating predictive time series queries for alerts.
 // end::EN[]