OPERATIONS should be less about technologies but rather about evolution and relation to Quality Goals

[aheusingfeld]

The OPERATIONS section should rather focus on traits that support the evolution - no matter whether Build-for-replacement or Build-and-evolve - of a business services. The curriculum should explain the impact of knowing and not knowing the operational Quality Goals (non functional requirements/expectations for production use) during the design of the service and relation to technical debt (don't elaborate too much but referr to IMPROVE)

[svenjohann]

I agree, but would formulate it a bit different. Actually I kind of made a proposal for the whole section of the learning goals.

• Attendees understand the challenges between monolithic systems observability and microservices observability
• Attendees know the building blocks of observing a system: logs, metrics, traces
• They know how to connect the health of their business (e.g. major use cases) to the health of individual services. They understand that it is hard to operate a microservices system by reacting to all kinds of occurring failures. Things fail all the time in a distributed system. Therefore it is more important to understand if your business has a problem by carefully observing and alerting on major use cases only (e.g. by using specific SLOs and SLIs). In short, understanding “is it broken?”
• They understand that SLOs are just another term for operational qualities of a microservices architecture such as performance, availability, freshness of data, etc. Those qualities do not only need proper observability, but also relate to the question how to achieve those qualities within your architecture. There is a strong relation between observability and architecture.
• When you get an alert that your business has a problem due to an unhealthy service, it is important to understand the change(s) that led to the alert by looking at all the information logs, metrics and traces give you. In short, understanding “what’s broken?”
• Attendees know the current landscape of O11Y technologies including a few screenshots (or demo) how they work
• Attendees understand that a certain amount of problems is actually normal and acceptable (error budget), but that it is important to observe trends on increasing and decreasing operational quality

Currently we reserve 90 min + 30 min exercise. I am just wondering if we would be able to shrink it to 90 min (Slides, discussion, demo)

[aheusingfeld]

I really like your suggestion, Sven. Would you mind creating a pull-request, so we can revise the phrasing of the learning goals together?

BTW: We decided in the advance group to change the structure of learning goals a while ago. the previous structure was not easily understandable nor checkable by attendees of trainings. An example of the new format/structure is in https://github.com/isaqb-org/curriculum-ddd/blob/main/docs/03-module-block-3/02-learning-goals.adoc - each Learning Goal has a dedicated section including heading, anchor and description. The anchors are needed because the template processes the asciidoc code and automatically collects all learning goals in order to create an index.

[svenjohann]

Ok, thanks :-)

I created a branch, but it's far from ready: https://github.com/svenjohann/curriculum-flex/tree/operations.