diff --git a/docs/00b-basics/02-curriculum-structure-and-chronological-breakdown.adoc b/docs/00b-basics/02-curriculum-structure-and-chronological-breakdown.adoc index e963980..b5fa4a3 100644 --- a/docs/00b-basics/02-curriculum-structure-and-chronological-breakdown.adoc +++ b/docs/00b-basics/02-curriculum-structure-and-chronological-breakdown.adoc @@ -53,7 +53,7 @@ Die Ausgestaltung der Beispiele und Übungen sind in diesem Lehrplan nicht vorge // tag::EN[] === Curriculum Structure and Recommended Durations -[cols="<,>", options="header"] +[cols="<,>,>", options="header"] |=== | Content | Recommended duration (minutes) diff --git a/docs/00b-basics/04-prerequisites-for-this-training.adoc b/docs/00b-basics/04-prerequisites-for-this-training.adoc index 89e44cf..6b7eba8 100644 --- a/docs/00b-basics/04-prerequisites-for-this-training.adoc +++ b/docs/00b-basics/04-prerequisites-for-this-training.adoc @@ -23,18 +23,26 @@ Herausforderungen. // tag::EN[] === Prerequisites -TODO -Participants **should** have the following prerequisite knowledge: - -- Prerequisite 1 -- Prerequisite 2, etc. - -Knowledge in the following areas may be **helpful** for understanding some concepts: - -- Area 1: - * Knowledge 1 - * Experience 2 - * Knowledge 3 - * Experience 4 - * Understanding 5 +Participants **should** have the following knowledge and / or +experience: + +- Fundamentals of the description of architectures using various + views, comprehen- sive concepts, design decisions, boundary conditions + etc., as taught in the CPSA-F (Foundation Level). +- Experience with implementation and architecture in agile projects. +- Experiences from the development and architecture of classical systems with the + typical challenges. + +**Useful** for understanding some concepts are also: + +- Distributed systems + * Problems and challenges in the implementation of distributed + systems + * Typical distributed algorithms + * Internet protocols + +- Knowledge about modularisations + * Functional modularisation + * Technical implementations like packages or libraries +- Classical operation and deployment processes // end::EN[] diff --git a/docs/01-motivation/01-duration-terms.adoc b/docs/01-motivation/01-duration-terms.adoc index 49f25fe..1d4abf5 100644 --- a/docs/01-motivation/01-duration-terms.adoc +++ b/docs/01-motivation/01-duration-terms.adoc @@ -13,5 +13,5 @@ Verfügbarkeit, Zuverlässigkeit, Time-to-Market, Flexibilität, Vorhersagbarkei |=== === Terms and Principles -Availability, resilience, time-to-market, flexibility, predictability, reproducibility, homogenization of stages, internet/web scale, distributed systems, parallelizing feature development, evolution of architecture (build for replacement), heterogenity, automation +Availability, resilience, time-to-market, flexibility, predictability, reproducibility, homogenization of stages, internet/web scale, distributed systems, parallelizing feature development, evolution of architecture (build for replacement), heterogenity, automation. // end::EN[] diff --git a/docs/01-motivation/02-learning-goals.adoc b/docs/01-motivation/02-learning-goals.adoc index 14a61cf..185f943 100644 --- a/docs/01-motivation/02-learning-goals.adoc +++ b/docs/01-motivation/02-learning-goals.adoc @@ -27,7 +27,7 @@ Sie haben die Kompromisse der vorgestellten Architektur-Typen (mindestens Micros [[LZ-1-4]] ==== LZ 1-4: Verständnis für Rahmenbedingungen von verteilten Systemen -.Teilnehmer sollen Rahmenbedingungen von verteilten Systemen verstehen, wie z.B. folgende: +.Teilnehmer sollen Rahmenbedingungen von verteilten Systemen verstehen, wie z. B. folgende: * Auf die Fähigkeit, neue Features schnell in Produktion bringen zu können, hat die Architektur entscheidenden Einfluss. * Abhängigkeiten zwischen Komponenten, die von unterschiedlichen Entwicklungsteams verantwortet werden, beeinflussen die Dauer, bis Software in Produktion gebracht werden kann, weil sie die Kommunikationsaufwände erhöhen und sich Verzögerungen fortpflanzen. * Die Automatisierung von Aktivitäten (wie z. B. Test- und Deployment-Prozesse) erhöht die Reproduzierbarkeit, Vorhersagbarkeit und Ergebnisqualität dieser Prozesse. Das kann zu einer Verbesserung des gesamten Entwicklungsprozesses führen. @@ -52,8 +52,81 @@ Sie haben die Kompromisse der vorgestellten Architektur-Typen (mindestens Micros // tag::EN[] [[LG-1-1]] -==== LG 1-1: This is the first learning goal, in category xy -tbd. +==== LG 1-1: Quality goals of flexible architectures + +Architectures can be optimised to meet different quality goals. + +In this module participants learn how to develop architectures that +allow fast deployment and fast feedback from using the system. Such +architectures support developers in achieving functional suitability +efficiently and improve usability. They also foster modularity and +can serve to achieve high reliability und replace individual +components in isolation, which serves flexibility. + +[[LG-1-2]] +==== LG 1-2: Interaction of architecture types and organisation +They have understood the drivers for the architecture types taught in +this curriculum module, the implications of these drivers for the +architectures, and the interaction of the architectures with the +organisation, processes, and technologies. + +[[LG-1-3]] +==== LG 1-3: Communicating and adapting compromises of the presented architecture types + +They have understood the trade-offs of the architecture types +presented (at least Microservices, Self-Contained Systems and +Deployment Monoliths) and are able to communicate them as well as +apply them in the context of concrete projects / system developments +in order to make appropriate architectural decisions. + +[[LG-1-4]] +==== LG 1-4: Understanding the constraints of distributed systems + +.Participants understand the constraints of distributed systems, such as the following: + + * The architecture has crucial influence on the ability to quickly + bring new features into production. + * Dependencies between components of different development teams + influence the duration until software can be put into production + because they increase the communication costs and delays are + propagated. + * Automation of activities (such as test and deployment processes) + increases the reproducibility, predictability, and quality of + results of these processes. This can lead to an improvement of the + overall development process. + * Unification of the different environments (e.g., development, + test, QA, production) reduces the risk of lately detected and (in + other environments) non-reproducible errors due to different + configurations. + * Unification and automation are essential aspects of continuous + delivery. + * Continuous integration is a prerequisite for continuous + delivery. + * A suitable architecture is the prerequisite for the + parallelization of the development as well as the independent + commissioning of independent modules. This can, but do not have to + be "services". + * Some change scenarios are easier to implement in monolithic + architectures. Other change scenarios are easier to implement in + distributed service architectures. Both approaches can be + combined. + * There are different types of isolation with different + advantages. A failure, for example, can be limited to a single + component or changes can be limited to a single component. + * Certain types of isolation are much easier to implement between + processes with remote communication. + * Remote communication, however, has disadvantages - for example + many new sources of errors. + +[[LG-1-5]] +==== LG 1-5: Contextualizing topics and buzzwords + + * Conway’s law + * Partitionability as a quality feature + * Round trip times with the IT supply chain as a competitive factor + * Building a continuous delivery pipeline + * The different test phases of a continuous delivery pipeline + // end::EN[] diff --git a/docs/02-modularization/01-duration-terms.adoc b/docs/02-modularization/01-duration-terms.adoc index 127a3a7..0553e6d 100644 --- a/docs/02-modularization/01-duration-terms.adoc +++ b/docs/02-modularization/01-duration-terms.adoc @@ -19,6 +19,13 @@ |=== === Terms and Principles -Term 1, Term 2, Term 3 + +- Motivation for decompositioning into smaller systems +- Different kinds of modularisation, coupling +- System limits as a way of isolation +- Hierarchical structure +- Application, Self-Contained System, Microservice +- Domain-Driven Design Concepts and "Strategic Design", Bounded Contexts + // end::EN[] diff --git a/docs/02-modularization/02-learning-goals.adoc b/docs/02-modularization/02-learning-goals.adoc index 318c72a..59fee90 100644 --- a/docs/02-modularization/02-learning-goals.adoc +++ b/docs/02-modularization/02-learning-goals.adoc @@ -32,7 +32,7 @@ * Die Teilnehmer können ein Konzept erarbeiten, um ein System aus Services aufzubauen. .Was sollen die Teilnehmer verstehen? -* Modularisierung hilft Ziele wie Parallelisierung der Entwicklung, unabhängiges Deployment/Austauschbarkeit zur Laufzeit, Rebuild/Reuse von Modulen und leichtere Verständlich- keit des Gesamtsystems zu erreichen. +* Modularisierung hilft Ziele wie Parallelisierung der Entwicklung, unabhängiges Deployment/Austauschbarkeit zur Laufzeit, Rebuild/Reuse von Modulen und leichtere Verständlichkeit des Gesamtsystems zu erreichen. * Daher ist beispielsweise Continuous Delivery und die Automatisierung von Test und Deployment ein wichtiger Einfluss auf die Modularisierung. * Modularisierung bezeichnet Dekomposition eines Systems in kleinere Teile. Diese Teile nach der Dekomposition wieder zu integrieren, verursacht organisatorische und technische Auf- wände. Diese Aufwände müssen durch die Vorteile, die durch die Modularisierung erreicht werden, mehr als ausgeglichen werden. * Je nach gewählter Modularisierungstechnologie besteht Kopplung auf unterschiedlichen Ebenen: @@ -77,12 +77,167 @@ // tag::EN[] [[LG-2-1]] -==== LG 2-1: TBD -tbd. +==== LG 2-1: Decomposing into building blocks + +.What shall participants be capable of? + +* Participants can design a decomposition into individual blocks for a + given problem. +* The participants should consider the organisation's communication + structure when setting the module boundaries (Conway's law). +* The participants can draw up a plan to divide a deployment monolith + into small services. + +.What should participants understand? + +* Participants understand that each type of building blocks requires a handy label, as well as a description, +** what makes up this kind of building block +** how such a building block is integrated at runtime +** how such a building block is built (in the sense of the build system) +** how such a building block is deployed +** how such a building block is tested +** how such a building block is scaled +* Different levels of specifications can be useful for the development + of a module. Some specifications should better be superior valid for + the integration with other building blocks of this type, in + general. The overarching decisions that affect all systems can + form a macro architecture, including, for example, communications + protocols or operating standards. Micro architecture can be the + architecture of a single system. It is largely independent of other + systems. Excessive limitations at the macro architecture level will + lead to an overall architecture that can be applied to fewer + problems + +.What should participants know? + +* The participants should know Conway’s law. [[LG-2-2]] -==== LG 2-2: TBD -tbd. +==== LG 2-2: Modularisation concepts + +.What shall participants be capable of? + +* The participants should be able to evaluate and select technical + modularisation concepts in a project-specific manner. +* The participants should be able to illustrate and analyse the + relationships between modules as well as between modules and + subdomains (context mapping). +* Participants can develop a concept to build a system of services. + +.What should participants understand? + +* Modularisation helps to achieve goals such as parallelization of + development, independent deployment / interchangeability at runtime, + rebuild / reuse of modules and easier understanding of the overall + system. +* Therefore, techniques like continuous delivery and the automation of + test and deployment are important influences on the modularisation. +* Modularisation means the decomposition of a system into smaller + parts. Re-integrating these parts after the decomposition causes + organisational and technical efforts. These efforts have to be + exceeded by the advantages achieved by the modularisation. +* Depending on the chosen modularisation technology, there is coupling + on different levels: +** Sourcecode (modularisation with files, classes, packages, + namespaces etc.) +** Built target (modularisation with JARs, libraries, DLLs, etc.) +** Runtime environment (operating system, virtual machine or + container) +** Network protocol (distribution to different processes) +* A coupling at the source code level requires very close cooperation + as well as common SCM. A coupling at the level of the built target + means that the building blocks must usually be deployed + together. Only a distribution to different applications / processes + is feasible with regard to independent deployment. +* Participants understand that a complete isolation between building + blocks can only be ensured by a separation in all phases + (development, deployment and runtime). If this is not the case, + undesirable dependencies cannot be excluded. At the same time, the + participants also understand that it can be useful to forego + complete isolation for reasons such as efficient resource usage or + complexity reduction. +* Participants understand that, when distributing to different + processes, some dependencies no longer exist in the implementation, + but rather arise at runtime. This increases the requirements for + monitoring these interfaces. +* Microservices are independent deployment units and therefore + independent processes that expose their functions through + lightweight protocols, but may also have a UI. Different technology + decisions can be made for the implementation of each individual + microservice. +* A Self-Contained System (SCS) is a functionally independent + system. It usually includes UI and persistence. It may consist of + several Microservices. Usually a SCS covers a functional bounded + context. + +.What should participants know? +* The participants should know various technical modularisation + options: e.g., source code files, libraries, frameworks, plugins, + applications, processes, Microservices, SCS. +* The participants should know various technical modularisation + options: e.g., source files, libraries, frameworks, plugins, + applications, processes, microservices, self-contained systems +* The participants should know "The Twelve-Factor App". + +[[LG-2-3]] +==== LG 2-3: Modularisation strategies + +.What shall participants be capable of? + +* Participants can evaluate the consequences of different + modularisation strategies and compare the efforts of the + modularisation with the expected benefits. +* Participants can assess the impact of the modularisation strategy + on the autonomy of building blocks at development time and at run + time. +* The participants can choose a suitable modularisation as well as a + suitable granularity of the modularisation - depending on the + organisation and the quality goals. + +.What should participants understand? + +* Participants understand that an integration strategy decides whether + a dependency +** emerges at runtime +** emerges during development time, or +** emerges at the deployment. +* The module division can be done along functional or technical + boundaries. In most cases, a functional division is recommended, + because in this case functional requirements can be assigned more + clearly to a concrete module, and therefore it is not necessary to + adapt several modules for the implementation of a single functional + requirement. Thereby, each module can have its own domain model in + the sense of a bounded context and thus different views on a + business object with its own data. +* Participants understand that in order to achieve higher autonomy of + the development teams, it is better to divide a component along + functional boundaries rather than along technical boundaries. +* Transactional consistency through + process boundaries can only be achieved via additional + mechanisms. So, if a system is divided into several processes, the + module boundary often also represents the limit for transactional + consistency. Therefore, a DDD aggregate must be managed in one + module. +* Participants understand which modularisation concepts can be used + not only for transactional but also for batch- and + data-flow-oriented systems. + +.What should participants know? + +* The participants should know the following terms from the + domain-driven design: Aggregate Root, Context Mapping, Bounded + Contexts and relationships between them (e.g., Anti-Corruption + Layer). + + // end::EN[] + + + +· + + + + diff --git a/docs/03-integration/01-duration-terms.adoc b/docs/03-integration/01-duration-terms.adoc index 4c2a1f3..1e240ab 100644 --- a/docs/03-integration/01-duration-terms.adoc +++ b/docs/03-integration/01-duration-terms.adoc @@ -14,6 +14,8 @@ Frontend Integration, Legacy Systeme, Authentifizierung, Autorisierung, (lose) K |=== === Terms and Principles -Term 1, Term 2, Term 3 +Frontend integration, legacy systems, authentication, authorisation, +(loose) coupling, scalability, messaging patterns, domain events, +decentralised data management. // end::EN[] diff --git a/docs/03-integration/02-learning-goals.adoc b/docs/03-integration/02-learning-goals.adoc index 5830ac9..7a7e75b 100644 --- a/docs/03-integration/02-learning-goals.adoc +++ b/docs/03-integration/02-learning-goals.adoc @@ -51,12 +51,122 @@ // tag::EN[] [[LG-3-1]] -==== LG 3-1: TBD -tbd. +==== LG 3-1: Strategic Design + +1. Participants should have a basic understanding of the + implementation of integrations using Strategic Design from Domain + Driven Design and know fundamental patterns. + +2. For the integration of legacy systems, it has to be defined how to + handle old data models. For this purpose, the approach of strategic + design can be used with essential patterns such as anti-corruption + layers. + [[LG-3-2]] -==== LG 3-2: TBD -tbd. +==== LG 3-2: Choosing a technical integration strategy + +. The participants should know the benefits and drawbacks of different + integration mechanisms. These include front-end integration with + Mash Ups, Middle Tier integration, and integration through databases + or database replication. + +. The participants can propose a suitable integration depending on the + quality goals and the knowledge of the team. + +. The participants should choose an integration strategy that best + suits the particular problem. This can be, for example, front-end + integration, integration via RPC mechanisms, message-oriented + middleware, REST, or replication of data. + +. Participants should understand the implications and limitations that + arise from the integration of systems across different technologies + and integration patterns, relating to, for example, security, + response time, or latency. + +. RPC means mechanisms for synchronously calling functionality in + another process over computer boundaries. This results in coupling + in many respects (time, data format, API). This coupling has a + negative effect on the availability and response times of the + system. REST makes guidelines that can reduce this coupling + (Hypermedia, standardised API). However, basically, the temporal + coupling remains. + +. With integrating through messaging, systems communicate through the + asynchronous exchange of messages. The systems are thus decoupled in + time. Technically, this is achieved by means of indirection via a + middleware. Messages can optionally be persisted, filtered, + transformed, etc. There are different messaging patterns like + Request / Reply, Publish / Subscribe or Broadcast. + +. An integration via data enables high autonomy, nevertheless it is + bought by the necessity for redundant data storage and the necessary + synchronisation. It must not be assumed that other systems use the + same schemes, because this prevents an independent development of + the schemata. Therefore, an adequate transformation has to be + provided for the integration. + +. The participants should be able to name different approaches for + front-end integration as well as their benefits and drawbacks and + applicability according to context criteria. + +. The participants should know technologies for the integration of + services: REST, RPC, message-oriented middleware. + +. The participants should know database replication mechanisms using + ETL tools or other approaches + +. The participants should know messaging Patterns (Request / Reply, + Publish / Subscribe, etc.) + +. The participants should know messaging systems (RabbitMQ, Kafka + etc.), protocols (AMQP, MQTT, STOMP etc.) and APIs (JMS). + +[[LG-3-3]] +==== LG 3-3: Explain macro architecture und formulate criteria + +. Based on these approaches, participants should be able to design a + macro architecture that covers at least communication and security. + +. The participants can name clear criteria developers can use + independently to determine if an (architecture) decision is a + decision about micro architecture or macro architecture, if they can + make that decision on their own or if they need to involve external + stakeholders in the decision process. + +[[LG-3-4]] +==== LG 3-4: Domain events instead of RPC for integrating bounded contexts + +. In an event-driven architecture (EDA), RPC is avoided or reduced by + publishing domain events. Domain events describe state + changes. Interested systems can process these messages (Publish / + Subscribe). This procedure affects how the state is stored. While, + in an RPC-based integration the server has to store the data, with + EDA this is the responsibility of the subscriber. Thus, replicas + arise (decentralised data storage). Thereby, the subscribers act as + a cache for the publisher. Additional subscribers can be added + without affecting the publisher (except by polling). Monitoring of + the event flows is important. + +. Domain events can be published via messaging. The publisher pushes + the messages into a messaging system. Alternatively, the messages + can be polled from the publisher (e.g., Atom / RSS). When using a + messaging system, subscribers can receive the messages by push or + pull. This has implications for dealing with backpressure. + + +. The participants should know challenges of the usage of shared data. + +[[LG-3-5]] +==== LG 3-5: Security + +. Participants should be able to design a suitable approach for + implementing security (authorisation / authentication) in a + distributed system. + +. The participants should know typical distributed security mechanisms + such as OAuth or Kerberos + // end::EN[] diff --git a/docs/04-rollout/01-duration-terms.adoc b/docs/04-rollout/01-duration-terms.adoc index 5d93697..15b6f17 100644 --- a/docs/04-rollout/01-duration-terms.adoc +++ b/docs/04-rollout/01-duration-terms.adoc @@ -15,7 +15,7 @@ Moderner Betrieb, DevOps, Infrastructure as Code, Configuration Management. |=== === Terms and Principles -Term 1, Term 2, Term 3 +Modern operations, DevOps, Infrastructure as Code, Configuration Management. // end::EN[] diff --git a/docs/04-rollout/02-learning-goals.adoc b/docs/04-rollout/02-learning-goals.adoc index 60d95d5..b963a12 100644 --- a/docs/04-rollout/02-learning-goals.adoc +++ b/docs/04-rollout/02-learning-goals.adoc @@ -32,18 +32,67 @@ * Konzept von Deployments mit Package-Managern oder Linux Containern * Verschiedene PaaS-Plattformen und ihre Konzepte - - // end::DE[] // tag::EN[] [[LG-4-1]] -==== LG 4-1: TBD -tbd. +==== LG 4-1: Aspects of rollout and continuous delivery + +.What shall participants be capable of? +* The participants should be able to roughly sketch a concept and + understand how to automatically deploy a system as simple as + possible. They should be able to weigh between the different + technological approaches. +* Participants should be able to design and evaluate deployment + automation. For example, they have to be able to assess the quality + and testing of these approaches. They have to be able to select an + appropriate approach for a project scenario. +* The participants should be able to sketch a team structure based on + the DevOps organisation model. + +.What should participants understand? +* The foundation for automating deployment is virtualization or the + cloud with Infrastructure as a Service (IaaS). A lightweight + alternative are Linux containers as implemented by Docker. + +* Deployment of a large number of servers and services is virtually + impossible without a deployment automation. +* Modern deployment tools allow to automatically install software on + computers. In addition to the application itself, the complete + infrastructure can also be created automatically. In this case + installations are idempotent, which means that they always lead to + the same result regardless of the initial state of the system. +* Immutable servers are never changed. If a new version of the + software has to be taken into operation, the server is rebuilt from + scratch. This can be simpler and more reliable than to rely on + idempotent tools. +* PaaS (Platform as a Service) provides a complete platform where + applications can be deployed in. Since in this case the + infrastructure is not built up by oneself, the approach is simpler, + but also less flexible. +* Concepts such as tests or code reviews are also indispensable for + deployment automation. Infrastructure becomes code that must meet + the same requirements as productive code (Infrastructure as Code). +* To support the deployment, the result of a build process can be + packages for an operating system or even images for virtual + machines. +* The environments of a developer should ideally match the production + environments. With modern tools, it is possible to create and + maintain such an environment at the push of a button. +* The complexity of the deployment becomes a further quality feature + of the system and affects architecture tools. +* With DevOps, development and operations are integrated in a single + team. Consequently, operations must be considered already during + development. This affects provisioning but also continuous + delivery (see chapter "Continuous Delivery"). + +.What should participants know? +* Basic concept of modern infrastructure such as IaaS, PaaS and + virtualization concepts of deployment tools like Chef, Puppet, + Ansible or Salt Organisation forms for DevOps +* Concepts of deployments with package managers or Linux containers + Various PaaS platforms and their concepts -[[LG-4-2]] -==== LG 4-2: TBD -tbd. // end::EN[] diff --git a/docs/05-operations/01-duration-terms.adoc b/docs/05-operations/01-duration-terms.adoc index f154eed..a5f29d2 100644 --- a/docs/05-operations/01-duration-terms.adoc +++ b/docs/05-operations/01-duration-terms.adoc @@ -14,7 +14,7 @@ Monitoring, Operations, Logging, Tracing, Metrics, Alerting. |=== === Terms and Principles -Term 1, Term 2, Term 3 +Monitoring, Operations, Logging, Tracing, Metrics, Alerting. // end::EN[] diff --git a/docs/05-operations/02-learning-goals.adoc b/docs/05-operations/02-learning-goals.adoc index 5898be2..308ed86 100644 --- a/docs/05-operations/02-learning-goals.adoc +++ b/docs/05-operations/02-learning-goals.adoc @@ -6,7 +6,7 @@ ==== LZ 5-1: Fehleranalyse in verteilten Systemen .Was sollen die Teilnehmer können? - * Die Teilnehmer sollen ein Konzept grob skizzieren und verstehen können, auf dessen Basis ein System überwacht werden kann, d.h. den aktuellen Status zu beurteilen, Fehler und Abweichungen vom normalen Betrieb möglichst zu vermeiden oder zumindest so früh wie möglich zu erkennen zu behandeln. + * Die Teilnehmer sollen ein Konzept grob skizzieren und verstehen können, auf dessen Basis ein System überwacht werden kann, d.h. den aktuellen Status zu beurteilen, Fehler und Abweichungen vom normalen Betrieb möglichst zu vermeiden oder zumindest so früh wie möglich zu erkennen und zu behandeln. .Was sollen die Teilnehmer verstehen? * Die richtige Auswahl von Daten ist zentral für ein zuverlässiges und sinnvolles Monitoring und Logging. @@ -37,19 +37,73 @@ .Was sollen die Teilnehmer verstehen? * Die Teilnehmer sollen verstehen, wie eine typische zentralistische Logdaten-Verwaltung aufgebaut ist und welche Auswirkungen sie auf die Architektur hat. - * Die Teilnehmer sollen verstehen, wie eine typische zentralistische Metriken-Pipeline aufgebaut ist (Erfassen, Sammeln & Samplen, Persistieren, Abfragen, Visualisieren) und welche Auswirkungen sie auf die Architektur hat (Performance-Overhead, Speicherverbrauch,...). - * Die Teilnehmer sollen die unterschiedlichen Möglichkeiten von Logging, Monitoring und einer Operations DB (siehe M. Nygard, Release IT!) verstehen, was man wofür einsetzt und wie man diese Werkzeuge sinnvoll kombiniert. + * Die Teilnehmer sollen verstehen, wie eine typische zentralistische Metriken-Pipeline aufgebaut ist (Erfassen, Sammeln & Samplen, Persistieren, Abfragen, Visualisieren) und welche Auswirkungen sie auf die Architektur hat (Performance-Overhead, Speicherverbrauch, ...). + * Die Teilnehmer sollen die unterschiedlichen Möglichkeiten von Logging, Monitoring und einer Operations DB (siehe <>) verstehen, was man wofür einsetzt und wie man diese Werkzeuge sinnvoll kombiniert. // end::DE[] // tag::EN[] [[LG-5-1]] -==== LG 5-1: TBD -tbd. +==== LG 5-1: Fault analysis in distributed systems + +.What shall participants be capable of? +* The participants should be able to roughly sketch and understand a + concept that allows to monitor a system, that means assess the + status, avoid errors and deviations from the regular operation as + far as possible or at least detect and handle them as early as + possible. + +.What should participants understand? +* The appropriate selection of data is essential for reliable and + meaningful monitoring and logging. +* In order to achieve systems that are ready to operate, in particular + those composed of many individual subsystems, the support of + operations has to be an integral part of the architecture concepts. +* In order to achieve the highest possible transparency, a great deal + of data has to be collected, but also be pre-aggregated and made + evaluable. +* The participants should understand which information can be obtained + from log data and which may (better) be obtained by instrumentation + of the code with metric probes. [[LG-5-2]] -==== LG 5-2: TBD -tbd. -// end::EN[] +==== LG 5-2: Difference between metrics, logs, and traces + +.What should participants understand? +* Logging and monitoring can include both functional and + technical data. +* Logs are events, a metric is a state at a specific time +.What should participants know? +* Tools for centralised log data management +* Tools for centralised metrics processing +* Difference between business, application and system metrics +* The meaning of important, system-independent application and system + metrics +[[LG-5-3]] +==== LG 5-3: Different models of operations + +.What shall participants be capable of? +* According to context - such as organisation und skill set - decide + on centralised or decentralised operation. +* In the concept, they may focus on logging, monitoring and the data + that is required for that purpose, depending on the specific project + scenario +* Participants should be able to meet architecture requirements in a + way that supports the usage of appropriate tools, while reasonably + dealing with system resources. + +.What should participants understand? +* The participants should understand how a typical centralised log + data administration is built and what impact it has on the + architecture. +* The participants should understand how a typical centralised metrics + pipeline is built (capture, collect & sample, persist, query, + visualise) and the impact it has on the architecture (performance + overhead, memory consumption, ...). +* The participants should understand the various options of logging, + monitoring and an Operations DB (see <>), which + to use wherefore and how to meaningfully combine these tools. + +// end::EN[] diff --git a/docs/07-outlook/01-duration-terms.adoc b/docs/07-outlook/01-duration-terms.adoc index 96e15b5..f1fbad2 100644 --- a/docs/07-outlook/01-duration-terms.adoc +++ b/docs/07-outlook/01-duration-terms.adoc @@ -17,6 +17,12 @@ Der Ausblick stellt fortgeschrittene Themen dar, in die sich Teilnehmer vertiefe | Duration: 120 min | Practice time: 0 min |=== +The lookout presents advanced topics that participants may dive +into. So, they gain a deeper understanding of the challenges of +implementing flexible systems. In addition, they learn other factors +influencing the choice of technologies. + + === Terms and Principles - Consistency models: ACID, BASE, Partitioning, CAP diff --git a/docs/07-outlook/02-learning-goals.adoc b/docs/07-outlook/02-learning-goals.adoc index bc604e0..d511f02 100644 --- a/docs/07-outlook/02-learning-goals.adoc +++ b/docs/07-outlook/02-learning-goals.adoc @@ -37,9 +37,52 @@ // tag::EN[] [[LG-7-1]] ==== LG 7-1: Consistency Models -tbd. +.What shall participants be capable of? +* The participants should know various consistency models. They should + basically know the trade-offs of the different consistency models. +* Depending on the requirements and general conditions, they should be + able to decide whether traditional stability approaches are adequate + or resilient software design is required. + +.What should participants understand? +* The need for ACID transactions is much lower than is often assumed. +* Different scaling, distribution, and availability requirements require different + consistency models. +* The CAP theorem describes a spectrum in which, depending on the given + requirements, a suitable consistency model can be selected very fine-grained. +* BASE transactions guarantee consistency, however, they may not be + atomic and isolated as ACID transactions, which may lead to + temporary inconsistencies becoming visible. + +.What should participants know? +* Characteristics of and differences between ACID and BASE transactions +* Some product examples from different categories (e. g., NoSQL, + configuration tools, service discovery) +* CAP for describing and explaining consistency models [[LG-7-2]] ==== LG 7-2: Resilience Patterns -tbd. +.What shall participants be capable of? +* They should be able to decide, depending on requirements and + constraints, if traditional resilience approaches are sufficient or + if resilient software design is required. + +.What shall participants understand? +* Traditional stability approaches (error avoidance strategies) on + infrastructure levels are generally no longer sufficient for today's + distributed, highly networked system landscapes. +* There is no Silver Bullet for Resilient Software Design, i. e., the + relevant measures and applied patterns and principles depend on the + requirements, the general conditions and the persons involved. + +.What shall participants know? +* The formula for availability and the different approaches to + maximise availability (maximising MTTF, minimising MTTR) +* Isolation and latency monitoring as useful starting principles of + Resilient Software Design +* Basic Resilience patterns such as bulkhead, circuit breaker, + redundancy, failover + // end::EN[] + + diff --git a/docs/99-references/00-references.adoc b/docs/99-references/00-references.adoc index d7589c1..027b404 100644 --- a/docs/99-references/00-references.adoc +++ b/docs/99-references/00-references.adoc @@ -33,7 +33,7 @@ This section contains references that are cited in the curriculum. **N** -- [[[newman,Sam Newman 2015]]] Sam Newmann: Building Microservices: Designung Fine-Grained Systems, O'Reilly Media, 2015 +- [[[newman,Sam Newman 2021]]] Sam Newman: Building Microservices: Designing Fine-Grained Systems, O'Reilly Media, 2nd ed. edition, 2021, ISBN 978-1-49203-402-5 - [[[nygard,Nygard 2018]]] Michael T. Nygard, Release It!, 2. Auflage, Pragmatic Bookshelf, 2018 **O** @@ -43,7 +43,7 @@ This section contains references that are cited in the curriculum. **T** - [[[takada,Takada 2013]]] Mikito Takada, Distributed Systems for Fun and Profit, http://book.mixu.net/distsys/ (Guter Einstieg und Überblick) -- [[[tanenbaum,Tanenbaum, van Steen 2006]]] Andrew Tanenbaum, Marten van Steen, Distributed Systems – Principles and Paradigms, Pren- tice Hall, 2nd Edition, 2006 +- [[[tanenbaum,Tanenbaum, van Steen 2006]]] Andrew Tanenbaum, Marten van Steen, Distributed Systems – Principles and Paradigms, Prentice Hall, 2nd Edition, 2006 **V** @@ -51,8 +51,8 @@ This section contains references that are cited in the curriculum. **W** -- [[[wolffcd,Wolff 2016]]] Eberhard Wolff: Continuous Delivery: Continuous Delivery: Der pragmatische Einstieg, 2. Auflage, dpunkt, 2016, ISBN 978-3-86490-371-7 -- [[[wolffms,Wolff 2015]]] Eberhard Wolff: Microservices - Grundlagen flexibler Software Architekturen, 2. Auflage, dpunkt, 2018, ISBN 978-3-86490-555-1 +- [[[wolffcd,Wolff 2016]]] Eberhard Wolff: Continuous Delivery: Der pragmatische Einstieg, 2. Auflage, dpunkt, 2016, ISBN 978-3-86490-371-7 +- [[[wolffms,Wolff 2018]]] Eberhard Wolff: Microservices - Grundlagen flexibler Software Architekturen, 2. Auflage, dpunkt, 2018, ISBN 978-3-86490-555-1 - [[[wolfpaas, Wolff, Müller, Löwenstein 2013]]] Eberhard Wolff, Stephan Müller, Bernhard Löwenstein: PaaS - Die wichtigsten Java Clouds auf einen Blick, entwickler.press, 2013 **1** diff --git a/html-theme b/html-theme index 80e28b2..7533fc8 160000 --- a/html-theme +++ b/html-theme @@ -1 +1 @@ -Subproject commit 80e28b237838ff1254edf4b8e8d94ff399ef7ad2 +Subproject commit 7533fc8b4c357d15ccd791ecdf0f8fa56af33fd0 diff --git a/pdf-theme b/pdf-theme index ae6b394..50badc7 160000 --- a/pdf-theme +++ b/pdf-theme @@ -1 +1 @@ -Subproject commit ae6b39457c8f5cad9be5cdcede26211ec511924d +Subproject commit 50badc7dc2dd3760eb66821916e7ee76ba421567