Merge branch 'main' into issue/05_multi_hybrid_cloud_challanges

isaqb-org · Apr 4, 2024 · 39ca6e1 · 39ca6e1
2 parents 6494835 + 512a823
commit 39ca6e1
Show file tree

Hide file tree

Showing 5 changed files with 39 additions and 8 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -8,11 +8,13 @@
 - DevOps, DevSecOps, and SRE
 - Abstraction Layers of Container Managers
 
-## 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
@@ -5,7 +5,6 @@
 
 === 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, Hybrid/Multi Cloud, Organisatorische Aspekte der Cloud Migration, Rechtliche Rahmenbedingungen, Time-to-Market, Verfügbarkeit, Skalierung, Geo Redundanz, Performance, IOPS, Decoupling Operations, Networking.
-
 // end::DE[]
 
 // tag::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
@@ -20,7 +20,9 @@ Sie verstehen den Unterschied zwischen Public Cloud- und On-Premise-Betrieb sowi
 
 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.
 
@@ -66,7 +68,9 @@ Software architects understand the difference between public cloud and on-premis
 
 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.